{ "schema_version": 1, "revision": "7.08", "date": "2026-10-26", "language": "en", "scope": "Documented capabilities and explicitly qualified scale evidence; not implementation certification", "columns": [ { "id": "PN", "title": "PRP L3", "profile": "PRP wire-v4, protected adjacency and E2E 0x0202; local bootstrap, known identities; privacy mechanisms enabled; C08: interior transit between intermediaries, no endpoint rendezvous/deeper-session termination or optional traffic-history logging F29–F31 architectural witnesses (round465): content-representing ALIAS for supplier discovery; digest-bound ALIAS with independently trusted expected reference for object verification; author-confirmed negotiated content custody serving additional consumers, including multicast announcement with custody. Content convention and consumer verification are explicit; no new core wire field, registered content namespace or completed custody-wire implementation is implied. Custody clarification (round467): E2E and multicast channel custody only, subject to negotiated responsibility and channel authorization; no public CDN-style object repository. F31 reuse is confined to authorized multicast consumers/branches. ALIAS possession does not grant access, and E2E retention for one recipient alone does not qualify as cross-requester reuse. C06 criterion-specific architectural witness: author-approved TPA successor fast paths (TPA candidate section 7; observer/bootstrap proposal section 10), established protected channels, distinct adjacency/final-channel identities and hop-local realization selectors. This replaces retained wire-v4 onion framing only for C06; no implementation or bootstrap admission is claimed. Other criterion profiles are unchanged. F32 architectural witness: author-confirmed local trajectory planning from future availability and usable capacity negotiated by each client with aggregators up to the rendezvous; each side negotiates its own half, including QoS/bandwidth reservation. Documentary architectural credit, not a completed wire/planner or global delivery guarantee.", "website": "https://prp-protocol.org/", "logo": "prp.svg" }, { "id": "PI", "title": "PRP over IP", "profile": "IPv4 / UDP / PRP wire-v4, protected adjacency and E2E 0x0202; numeric peers, known identities; privacy mechanisms enabled; independent deployment uses private IPv4; C08: interior transit between intermediaries, no endpoint rendezvous/deeper-session termination or optional traffic-history logging G01 global deployment: conventional globally routed IPv4/UDP over the BGP Internet, matching IP/MQ and round119 BP/LP/I2/GN. Private IPv4 deployments remain separate S03 capabilities; adjacent-only IP meshes are not this global witness. This does not change native PRP L3. F29–F31 architectural witnesses (round465): content-representing ALIAS for supplier discovery; digest-bound ALIAS with independently trusted expected reference for object verification; author-confirmed negotiated content custody serving additional consumers, including multicast announcement with custody. Content convention and consumer verification are explicit; no new core wire field, registered content namespace or completed custody-wire implementation is implied. Custody clarification (round467): E2E and multicast channel custody only, subject to negotiated responsibility and channel authorization; no public CDN-style object repository. F31 reuse is confined to authorized multicast consumers/branches. ALIAS possession does not grant access, and E2E retention for one recipient alone does not qualify as cross-requester reuse. C06 criterion-specific architectural witness: author-approved TPA successor fast paths (TPA candidate section 7; observer/bootstrap proposal section 10), established protected channels, distinct adjacency/final-channel identities and hop-local realization selectors. This replaces retained wire-v4 onion framing only for C06; no implementation or bootstrap admission is claimed. Other criterion profiles are unchanged. F32 architectural witness: author-confirmed local trajectory planning from future availability and usable capacity negotiated by each client with aggregators up to the rendezvous; each side negotiates its own half, including QoS/bandwidth reservation. Documentary architectural credit, not a completed wire/planner or global delivery guarantee.", "website": "https://prp-protocol.org/", "logo": "prp.svg" }, { "id": "IP", "title": "IP (IPv4/IPv6)", "profile": "IPv4 or IPv6 datagram service / ICMP; numeric destinations; no application TCP/UDP/TLS/QUIC or IPsec, NAT or stateful firewall; optional transit traffic-history/export disabled. Global unicast control: TCP / BGP-4 + MP-BGP. F12: IGMP/MLD + PIM-SM. Independent deployment: RFC 1918 private IPv4 or locally generated IPv6 ULA, locally provisioned routes. Global Internet allocation remains a separate requirement. F09: optional per-packet unicast next-hop rotation over provisioned multiple routes (RFC 2991), not merely flow-hashed ECMP; G04: multiple BGP reflector clusters and group-scoped PIM RPs.; C06: separate IPv6 client contexts with distinct randomized temporary sources under a shared multi-host prefix, no stable source/DNS identity or host-identifying flow-label policy reused; no continuity or on-link anonymity claim F37 witness: optional router-local AQM with congestion-dependent packet dropping (RFC 7567), without requiring application TCP or ECN feedback. F38 witness: IP-layer DiffServ domains with participant-operated classifiers, policing/shaping and priority service under local provisioning and inter-domain traffic agreements (RFC 2475). These explicitly selected router policies do not imply default Internet deployment or add RSVP/IntServ application reservations, stateful firewalling or a new transport layer.", "website": "https://www.rfc-editor.org/rfc/rfc8200.html", "logo": null }, { "id": "BP", "title": "Secure DTN", "profile": "IPv4 / TCP / TLS 1.3 / TCPCLv4 / BPv7 + BPSec; independent private IPv4 and RFC 9758 private-use ipn domain; known EIDs, aggregate gateway exits, locally agreed dtn collective names, numeric peers; participant-operated CAs, local trust and BPSec keys, NODE-ID validation, no online OCSP or SNI; optional TLS padding, concurrent proactive forwarding and static collective fanout credited architecturally; independent logical-node EIDs/certificates/BPSec keys per context, no cross-context TLS resumption; discard completed bundles, no retained report archive or transit traffic history G01 global deployment: conventional BGP-routed IPv4 Internet underlay, matching the IP/MQ global case; private deployments remain separate S03 capabilities. F21: ION native BPSec receive-API witness at 154a4cc7354b26661169f8d8b75a4002cd509a9f; exact source-EID/key bindings, distinct pairwise HMAC keys held only by each original sender and receiver, BIBs over primary and payload, primary-inclusive payload integrity scope; application treats bundleSourceEid as authenticated only when both native verification indicators are true. No application authentication exchange, group key or relay-held origin key; no F16 admission/revocation guarantee inferred. F16 alternative witness: ION 154a4cc with optional BSL 468db9b enabled and mandatory APPOUT wildcard-source BIB verification over primary and payload. One authorized remote sender at a time; a fresh secret key is held only by that sender and the final receiver, never transit. Native policy uses a locally fixed key-registry identifier. Revocation uses completed shutdown of receiver and consumers, a fresh empty bundle/fragment/delivery store and a fresh key provisioned only to the newly authorized sender. No hot revocation, simultaneous independent-key allowlist, or claimed source-EID authentication is inferred from this witness; F21 retains its separate exact-source policy. F37/F38: optional router-local AQM and independent DiffServ domain enforcement selected in the existing IPv4/TCP transport beneath TLS/TCPCLv4. Policies apply to visible transport aggregates, without inspecting bundles or BPSec payloads. This does not resolve BPv7/SABR priority mapping, application reservation, DTN storage congestion or complete executable integration; no corresponding IP layer is added to the separate LTP/AOS column.", "website": "https://datatracker.ietf.org/wg/dtn/about/", "logo": "dtn.png" }, { "id": "CG", "title": "DTN / CGR–SABR", "profile": "IPv4 / TCP / TLS 1.3 / TCPCLv4 / BPv7 + BPSec, with CGR routing procedures from SABR CCSDS 734.3-B-1 (2019). Documentary composition; executable integration not yet qualified. Locally provisioned numeric peers, private IPv4, private-use ipn identifiers (RFC 9758), singleton destinations, supplied contact/range plans and local clocks. Participant-operated certificate trust with NODE-ID validation, no online OCSP, DNS or SNI dependency. Final-pair BCB-AES-GCM payload protection and BIB-HMAC-SHA2 verification with locally provisioned pairwise keys; no relay-held final keys. No application authentication wrapper, anonymity overlay, multicast extension or shared-reference directory. BPv7 mapping of SABR priority/critical metadata and custody-dependent behavior remains an explicit integration question, not silently credited. BPv7 source witness: ION 154a4cc7354b26661169f8d8b75a4002cd509a9f for native final-source delivery and origin-side critical-bundle replication. Exact-origin pairwise keys, primary and payload integrity coverage, and application checks of both verification flags are required. This pins these BP-layer mechanisms only; complete TCPCL/TLS or LTP/Encapsulation/AOS integration, critical metadata propagation at later hops, custody mapping and simultaneous on-wire path use remain unqualified. F16 bounded configuration: F16 alternative witness: ION 154a4cc with optional BSL 468db9b enabled and mandatory APPOUT wildcard-source BIB verification over primary and payload. One authorized remote sender at a time; a fresh secret key is held only by that sender and the final receiver, never transit. Native policy uses a locally fixed key-registry identifier. Revocation uses completed shutdown of receiver and consumers, a fresh empty bundle/fragment/delivery store and a fresh key provisioned only to the newly authorized sender. No hot revocation, simultaneous independent-key allowlist, or claimed source-EID authentication is inferred from this witness; F21 retains its separate exact-source policy. This final BP delivery gate is independent of the chosen CGR route and TCPCL ingress. C06 capability witness uses separate logical contexts with independently provisioned private-domain EIDs, certificates, BPSec keys and stores; no cross-context TLS resumption or common certificate subject/serial is required. F37/F38: optional router-local AQM and independent DiffServ domain enforcement selected in the existing IPv4/TCP transport beneath TLS/TCPCLv4. Policies apply to visible transport aggregates, without inspecting bundles or BPSec payloads. This does not resolve BPv7/SABR priority mapping, application reservation, DTN storage congestion or complete executable integration; no corresponding IP layer is added to the separate LTP/AOS column.", "website": "https://ccsds.org/publications/allpubs/entry/3167/", "logo": "cgr-sabr.svg" }, { "id": "LT", "title": "DTN / LTP", "profile": "BPv7 + BPSec / LTP RFC 5326 / Encapsulation Packet Protocol 133.1-B-3 / AOS virtual-channel packet service 732.0-B-4 (2021 documentary baseline, not latest edition); CGR/SABR 734.3-B-1 routing. LTP segment binding follows 734.1-B-1 Annex B. No UDP, IP, TCPCL or TLS. Bidirectional adjacent links, locally supplied contact/range plans, peer/engine mapping, clocks and keys; singleton BP endpoints. All-red block transfer selected; optional green-part service is not credited. Final-pair BCB-AES-GCM and BIB-HMAC-SHA2 protect payload and authenticate a configured remote security source; no relay-held final keys. No link encryption/SDLS, anonymity overlay, application authentication wrapper or independent-participant discovery directory. Executable bindings, BPv7/SABR metadata mapping and allocation rules remain unqualified. CCSDS mission conformance and unrestricted local engine/channel assignment are not asserted. BPv7 source witness: ION 154a4cc7354b26661169f8d8b75a4002cd509a9f for native final-source delivery and origin-side critical-bundle replication. Exact-origin pairwise keys, primary and payload integrity coverage, and application checks of both verification flags are required. This pins these BP-layer mechanisms only; complete TCPCL/TLS or LTP/Encapsulation/AOS integration, critical metadata propagation at later hops, custody mapping and simultaneous on-wire path use remain unqualified. Identity witness for independent deployment: private-use ipn EIDs confined to one administrative domain, with locally generated pairwise BPSec keys and exact-EID receiver policies. EID uniqueness and key distribution are configured by the participants; no public-key self-certification, automatic trust or global uniqueness is claimed. This does not settle AOS SCID allocation in S03. F16 bounded configuration: F16 alternative witness: ION 154a4cc with optional BSL 468db9b enabled and mandatory APPOUT wildcard-source BIB verification over primary and payload. One authorized remote sender at a time; a fresh secret key is held only by that sender and the final receiver, never transit. Native policy uses a locally fixed key-registry identifier. Revocation uses completed shutdown of receiver and consumers, a fresh empty bundle/fragment/delivery store and a fresh key provisioned only to the newly authorized sender. No hot revocation, simultaneous independent-key allowlist, or claimed source-EID authentication is inferred from this witness; F21 retains its separate exact-source policy. This final BP delivery gate is independent of the chosen CGR route and LTP ingress. It does not qualify the complete LTP/Encapsulation/AOS executable binding.", "website": "https://www.rfc-editor.org/rfc/rfc5326.html", "logo": "ltp.svg" }, { "id": "LP", "title": "libp2p", "profile": "IPv4 / UDP / QUIC (TLS 1.3) / libp2p; known numeric peers and Peer IDs, migration enabled; independent deployment uses private IPv4; separate logical peer keys/stores per context, no resumption, NAT or transit flow logging; no pubsub F16: final Peer ID allowlist through ConnectionGater plus coordinated closure of all revoked-peer connections. G01 global deployment: conventional BGP-routed IPv4 Internet underlay, matching the IP/MQ global case; private deployments remain separate S03 capabilities. K01 configuration witness: both endpoints use go-libp2p v0.50.0 with Go 1.26.5 and quic-go v0.62.0, TLS 1.3 without resumption; the selected successful handshake negotiates X25519MLKEM768 (4588). Defaults also permit classical peers: this is not a universal no-downgrade policy. Other per-cell witnesses retain their stated configurations. F37/F38: optional router-local AQM and independently administered DiffServ policies explicitly selected in the existing IP transport carrying QUIC/UDP. Classification/conditioning of visible transport aggregates, without decrypting streams; no RSVP/IntServ or application QoS reservation. Private/global deployment distinctions remain unchanged.", "website": "https://libp2p.io/", "logo": "libp2p.png" }, { "id": "TO", "title": "Tor onion service", "profile": "IPv4 / TCP / TLS / Tor + onion service v3; public Tor directory system; persistent filesystem client authorization enabled; transit traffic-history logging disabled; optional Conflux proposal-329 onion-service linking/resumption credited as design, not verified deployment; F21: client identity delivered to the receiving onion service; reverse service authentication is distinct F16: authorization-file removal plus Tor restart; retain authorization for permitted clients or stop the service when none remain. F37: optional IPv4 router-local AQM with congestion-dependent dropping explicitly selected. F38: mainline Tor local read/write and relayed-traffic token buckets with native traffic-class priorities; no IP DiffServ or application reservation added for these verdicts.", "website": "https://www.torproject.org/", "logo": "tor.png" }, { "id": "I2", "title": "I2P", "profile": "IPv4 / TCP / NTCP2 / I2P destinations and tunnels; locally supplied fresh RouterInfo bundle, numeric NTCP2 contacts and known destination keys; multiple active outbound tunnels with at least two remote hops, tunneled destination lookups; correct local clock; no online reseed or external naming service; isolated router/destination key contexts without shared family declarations; independent private IPv4 with i2np.allowLocal and local bootstrap/network configuration; concurrent-tunnel policy is architectural, ordinary Java per-pair selection is sticky; transit-only C08 role with optional identity-bearing traffic/debug history disabled G01 global deployment: conventional BGP-routed IPv4 Internet underlay, matching the IP/MQ global case; private deployments remain separate S03 capabilities. K01 witness: i2pd 2.58.0 with OpenSSL 3.5 or newer, OPENSSL_PQ enabled, both destinations supporting type 6 (ML-KEM-768/X25519), and the selected session actually using type 6. The Yes covers hybrid-established traffic, not the initial New Session payload or classical-type sessions; no universal fail-closed policy is inferred. F37/F38: optional router-local AQM and independently administered DiffServ enforcement selected in the existing IPv4 transport. Policies classify visible IP transport aggregates, without inspecting protected tunnel contents or requiring inner-to-outer DSCP copying. No application reservation extension is added; existing private/global and cryptographic qualifications remain unchanged. F39-only witness: Java I2P 2.6.0, commit 63326dc48b954fcaceae544daa57d9dd9a0c6f4d, with distinct application processes using separate I2CP client connections and Destination identities on the same local router; i2cp.disableLoopback=false. The same Destination-based API reaches remote peers through tunnels. This shared-router witness is separate from the isolated-context privacy composition and the i2pd hybrid-cryptography K01 witness; it does not combine their security properties.", "website": "https://geti2p.net/", "logo": "i2p.svg" }, { "id": "YG", "title": "Yggdrasil", "profile": "IPv4 / TCP / TLS 1.3 / Yggdrasil / IPv6 / application UDP; optional TLS padding credited architecturally; numeric peers, pinned keys, numeric application destinations; independent deployment uses private IPv4; independent logical-node keys and TLS contexts, no cross-context resumption; transit traffic-history logging/export disabled; ordinary TCP only, no MPTCP or custom scheduler; Ironwood pinned to d50055b11f5ec5b56ee4e56ba9a75261461821dc; G01: connected mesh of adjacent-only private-IP peerings, no Internet transit or remote public peers; F21: applications on native node addresses, not devices behind routed subnets; trusted local receive interface F37/F38: optional local AQM and DiffServ classification/conditioning explicitly selected on existing private-IP peering egress interfaces, including host-side network queues. Independent owners control their own link resources; no new Internet transit, global underlay, application reservation or inner-packet inspection is added.", "website": "https://yggdrasil-network.github.io/", "logo": "yggdrasil.svg" }, { "id": "CJ", "title": "cjdns", "profile": "IPv4 / UDP / cjdns / IPv6 / application UDP; ordinary application path without custom route-label overrides; outer point-to-point CryptoAuth enabled; numeric peers, known keys/local credentials, numeric application destinations; independent deployment uses private IPv4; independent logical-node keys and non-identifying peer credentials per context; transit traffic-history logging/export disabled; C02 includes documented DHT lookup role; no selected cover-traffic policy; private peering credentials, no public beacon advertisement; replicated route-server design with TCP/HTTP/WebSocket announcement exchange, independent servers and numeric contacts; C08 covers transit forwarding, not route-server query caches; F21: applications on native cryptographic node addresses, no imported IP tunnels; trusted local receive interface F37/F38: optional local AQM and DiffServ classification/conditioning explicitly selected on existing private-IP peering egress interfaces, including host-side network queues. Independent owners control their own link resources; no new Internet transit, global underlay, application reservation or inner-packet inspection is added.", "website": "https://github.com/cjdelisle/cjdns", "logo": "cjdns.svg" }, { "id": "MQ", "title": "Multipath QUIC", "profile": "IPv4 or IPv6 / UDP / QUIC (TLS 1.3) + multipath-21, optional proactive same-offset STREAM copies on two validated paths; numeric peers, locally generated certificates explicitly trusted by counterparts, mutual handshake authentication, no SNI requirement or online certificate service; independent private IPv4 deployment; separate trusted context keys, no cross-context tickets/token reuse, NAT or transit flow logging F16: local final-key allowlist, all-connection close on revocation, resumption and 0-RTT disabled.; G01 global deployment: conventional IPv6 Internet underlay with BGP/MP-BGP prefix routing; private deployment remains a separate S03 capability Global plausibility uses IPv6; retained private deployments and historical runtime/budget witnesses use IPv4. K01 configuration: picoquic c124cbe975f71b150ea929d325804335d2bdaa34, Picotls f06553b877ada93c860dd1db9002eabf7365292d, OpenSSL 3.5.0 default provider, with the initiating TLS context restricted to X25519MLKEM768 (4588). Classical fallback under default preferences does not inherit this Yes. The local witness tests key establishment and STREAM traffic in the native simulator, not multipath operation. F37/F38: optional router-local AQM and independently administered DiffServ policies explicitly selected in the existing IP transport carrying QUIC/UDP. Classification/conditioning of visible transport aggregates, without decrypting streams; no RSVP/IntServ or application QoS reservation. Private/global deployment distinctions remain unchanged.", "website": "https://quicwg.org/", "logo": "quic.png" }, { "id": "SC", "title": "SCION", "profile": "IPv4 / UDP underlay / SCION / application UDP; numeric topology, daemon, control/discovery and endpoint addresses, locally provisioned trust and correct local clock; no end-to-end TLS; independent UDP end-host address/flow contexts within an AS; transit traffic-history logging/export disabled F37/F38: optional router-local AQM and independently administered DiffServ enforcement selected in the existing IPv4 transport. Policies classify visible IP transport aggregates, without inspecting protected tunnel contents or requiring inner-to-outer DSCP copying. F37/F38 do not depend on an application reservation extension; existing private/global and cryptographic qualifications remain unchanged. F36: optional COLIBRI architecture (CoNEXT 2021, sections 3.2-3.4 and 4.3) explicitly selected for application-requested bandwidth: extended SCION daemon, reservation services, gateway policing and participating on-path ASes with segment capacity, destination acceptance, synchronized clocks and reservation renewal. Documentary capability only, not default SCION deployment or validation of current implementation interoperability. Existing endpoint-security evaluations are not promoted by reservation authenticators.", "website": "https://www.scion.org/", "logo": "scion.png" }, { "id": "RT", "title": "Reticulum", "profile": "Reticulum 1.5.5 / Link over serial interfaces; secret IFAC enabled, credentials not publicly advertised; no local TCP sharing or IP interfaces; no LXMF; regional transport-node distribution; no application cover-traffic policy; F21: native Link.identify enabled; identity-dependent actions wait for verified identification; G01: connected serial mesh with recursive_prs enabled on transport interfaces C08: Reticulum 1.5.5 standalone serial transport with the entire --config directory on private verified noswap tmpfs; no host swap/hibernation/dumps, snapshots, durable logs or exporters. Seed only clean static config/local identity/IFAC credentials; do not restore learned paths, announces or participant activity. Cold starts relearn routes. This supersedes the earlier C08 stock-disk profile; RAM activity remains observable. F39 capability witness: native shared-instance mode over Unix-domain sockets (share_instance=Yes, named instance on a supporting Unix host), retaining serial remote interfaces and IFAC. No local TCP or remote IP interface is added. Local client destinations use the ordinary destination/Link API. This criterion-specific configuration does not replace the standalone instance required by the separate C08 witness or requalify its storage/privacy findings.", "website": "https://reticulum.network/", "logo": "reticulum.png" }, { "id": "NS", "title": "Basic Nostr", "profile": "IPv4 / TCP / TLS 1.3 / HTTP Upgrade / WebSocket / NIP-01; optional TLS padding credited architecturally; WSS relay hostnames resolved through DNS; regular events proactively published concurrently over two independent relay paths; separate author contexts; no NIP-17/44/42 or secret-gated camouflage; F21: verified event author to reader, not live publishing connection or relay identity; G01 global deployment: WSS relays over conventional BGP-routed IPv4 Internet C08: operator-controlled nostr-rs-relay at b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4, SQLite in_memory=true, bundled URI-enabled SQLite and memory temporary storage; no file logging, persistent WSS-proxy logs, diagnostics export, swap, dumps, hibernation or snapshots. Apply to both selected relays. Regular events remain in RAM until discarded/restart; other readers/relays can retain copies. F37/F38: explicitly selected optional IPv4 router AQM with congestion-dependent dropping and independently administered DiffServ domains; transport-aggregate classification/conditioning, not NIP-01 functionality or universal relay deployment. No RSVP/IntServ application reservation. F39 witness: host one of the already selected native WSS relays, including its TLS endpoint, on the same Linux host as two distinct application processes. Use a stable relay hostname resolving to its assigned host address, separate WebSocket connections, and a subscription to the publishing process author key. Local IP delivery keeps this relay leg on-host; the same author filter and EVENT/REQ interface deliver to a remote subscriber connection. The second independent relay path is retained and may also carry copies. No new broker, NIP or direct-message protocol is added.", "website": "https://github.com/nostr-protocol/nips", "logo": "nostr.png" }, { "id": "MT", "title": "Meshtastic", "profile": "Meshtastic firmware v2.8.1.8e6a88d Alpha (commit 8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c); standalone LoRa mesh, radio/region preset agreed locally, ordinary CLIENT relaying; no MQTT, Wi-Fi/Ethernet network or Internet bridge; trusted local serial client. PKI-capable build, direct messages with independently confirmed endpoint public keys; private channel key, STRICT signature policy, no licensed plaintext mode. Store-and-forward module disabled. No claim that this Alpha is a production recommendation; radio nodes are the cryptographic endpoints. C04 witness fixes ordinary CLIENT rebroadcast_mode=ALL; private-channel key and STRICT signature policy retained. Unknown-channel opaque forwarding is included, not CLIENT_MUTE/NONE. F16 administrative witness: headless CLIENT, KNOWN_ONLY plus STRICT, locally provisioned authorized User records/full keys only, no remote administrative authority for ordinary peers; store-forward off, persisted ignore policy and completed restart for revocation. Separate from C04 CLIENT/ALL probe witness. C06 witness: native meshtasticd/Portduino with real LoRa radio, separately provisioned full contexts, explicit distinct General.MACAddress values, independent keys/names/preferences and no shared identifier-bearing telemetry. No automatic embedded-device rotation claim or UDP radio transport. C08: native Linux meshtasticd with real SPI/USB LoRa, ordinary CLIENT/ALL relaying, full writable virtual filesystem on verified private tmpfs with noswap; host swap/hibernation/dumps and persistent log/export/backup paths disabled. Restore only clean static identity/radio/trust provisioning at cold start, never learned NodeDB/history. No flash-device default or live-memory secrecy claim. F39-only witness: native Linux meshtasticd at the selected firmware commit, with a real SPI/USB LoRa radio and a distinct local client process using the native TCP Client API on loopback (port 4403). This explicitly replaces the serial attachment for this witness only; it adds no remote IP transport, MQTT or Internet bridge. Address a daemon-hosted module service by node number and application port, using the same ToRadio/MeshPacket interface for the local node and a remote LoRa node. NodeInfo is an existing request/response service; allow its normal response policy and throttling. Other criterion-specific serial and security configurations remain unchanged.", "website": "https://meshtastic.org/", "logo": "meshtastic.svg" }, { "id": "GN", "title": "GNUnet / CADET", "profile": "IPv4 / UDP TRANSPORT plugin / CORE / CADET; R5N discovery. GNUnet v0.20.x handbook is the explicit documentary baseline, not a claim about the latest release. Numeric private-IP neighbors, locally supplied HELLO contacts and known peer public keys; no online hostlist, DNS, NAT helper, GNS, file-sharing or Messenger service. Runtime version and discovery/bootstrap configuration remain to be qualified. G01 global deployment: conventional BGP-routed IPv4 Internet underlay, matching the IP/MQ global case; private deployments remain separate S03 capabilities. C08 witness: GNUnet 0.20.0 legacy UDP, proportional ATS, heap dhtcache with DISABLE_BF_RC=YES, peerinfo NO_IO=YES, logging NONE without forced overrides; fresh service state, no optional traffic archive/TNG, bootstrap contacts supplied again after restart. F16 witness: dedicated CADET endpoint with no local listening ports; locally initiated bidirectional channels only to an administratively selected set of peer public keys. Revocation uses a completed cold restart of the local CADET service and its consuming clients, discarding old channel/IPC delivery state before recreating channels only to the updated set. No application payload validator, external firewall or incoming-channel acceptance callback is credited. This is a controlled receiver/subscriber configuration, not an incoming server allowlist or uninterrupted hot revocation.", "website": "https://www.gnunet.org/", "logo": "gnunet.svg" }, { "id": "ND", "title": "NDN / NFD", "profile": "NDN packet format v0.3 / NFD 24.07 with direct Ethernet faces and local Unix-socket applications; no IP face, DNS discovery or public testbed enrollment. Known content/key names, local FIB configuration and local trust anchors; ECDSA P-256 Data signatures validated by the consumer. No content-encryption extension, mandatory signed consumer Interests, application sync/group protocol or DTN extension. Data-producer authentication is distinct from live peer authentication. F18 witness: positive-capacity CS with admission/serving enabled, solicited staged cache transfers, bounded contacts before eviction/freshness expiry; no custody or restart durability claim. G01 witness: connected tree of direct Ethernet adjacencies; native multicast v5 strategy at /, root-prefix next hops to every neighbor, and local producer registrations only. Known globally scoped names, no forwarding hints, NLSR, global directory or IP underlay. Interest lifetime/hop budget covers the tree diameter; provision resources for the offered load. This flooding construction establishes reachability, not G05 capacity or efficient routing. D01 binding: NFD 24.07 at a1480a7c947dc6a48ee12c6c0637fc488c0c73a1 on Linux, direct Ethernet faces through libpcap, started with root authority and configured to reduce its effective user/group IDs. The documented privilege reduction is reversible; local Unix-socket applications remain distinct from their forwarder. This source-based finding is not an execution result or a verdict on alternative NDN implementations. F39 bounded request/reply witness: one producer process owns the chosen globally scoped name prefix; use previously unrequested names with no matching cached response and configure the prefix toward that producer. The same name-based exchange reaches a local producer attachment or a remote producer through the selected network. No RPC framework, process migration, exactly-once execution, arbitrary duplex stream or new authentication layer is added.", "website": "https://named-data.net/", "logo": "ndn.png" }, { "id": "AX", "title": "AX.25 / NET/ROM", "profile": "AX.25 v2 / classic NET/ROM network and transport circuits over direct radio/serial links; known callsigns/SSIDs, locally configured routing ports and NET/ROM announcements. Historical protocol description plus Linux AX.25 port configuration; no IP encapsulation, TCP/IP payload service, BBS mailbox or added cryptography. Executable version not yet qualified. S01/S03/C06 credit the private direct-serial role with locally provisioned labels; no claim about radio licensing or public callsign acceptance. D01 implementation binding: Linux v6.12 kernel NET/ROM and AX.25, ax25-tools 0.0.10-rc5+git20230513+d3e6d4f, direct KISS serial attachment, and active netromd announcement reception/transmission and route aging. Application UID/callsign mapping is provisioned administratively. This is a source-qualified privilege finding, not a newly executed serial deployment; it does not qualify unrelated implementations or other evidence criteria.", "website": "https://www.ax25.net/", "logo": "ax25-netrom.svg" }, { "id": "BA", "title": "batman-adv", "profile": "Linux 6.12 batman-adv / native Ethernet frame service, direct Ethernet-style links; no IP application, VPN underlay, WPA/MACsec or end-to-end security layer. Locally administered MAC addresses, local interface attachment and trusted local client; This is an L2 service boundary, not an IP application stack. Round118 witnesses: BATMAN_IV, native bonding enabled for F09, gateway mode off, network coding not credited; shared-code IV/V findings identified per cell.", "website": "https://www.open-mesh.org/projects/batman-adv/wiki", "logo": "batman-adv.png" }, { "id": "BL", "title": "IP / Babel", "profile": "IPv6 datagram service / ICMPv6; control plane IPv6 / UDP / Babel RFC 8966. Independent locally assigned ULA prefixes, provisioned interfaces, numeric destinations; no DNS, TCP/QUIC, IPsec, NAT, external firewall, Babel DTLS/MAC extension or added application authentication. Babel is the selected routing control plane; no BGP/global Internet composition silently added. G01 constructive witness: administratively provisioned binary IPv6 hierarchy inside a locally assigned ULA /48, with direct routed adjacencies. Each router originates only its own aggregate backed by a local discard route; upward advertisements contain that aggregate, downward advertisements only the root /48. Exact-prefix/interface input and output filters suppress remote specifics. Connected leaf LANs override their local aggregate. No BGP, directory, automatic aggregation controller or global leaf-prefix catalog is introduced. Fixed hierarchy and address assignment are required; this is not arbitrary Internet topology or G05 capacity. F37/F38: optional local AQM and DiffServ classification/conditioning explicitly selected on existing IPv6 forwarding interfaces. Local queue/resource policy only; the declared ULA hierarchy, filters and topology remain unchanged. No BGP, public underlay or application reservation added.", "website": "https://datatracker.ietf.org/wg/babel/about/", "logo": "babel.svg" }, { "id": "RI", "title": "IPv6 IoT / RPL", "profile": "6LoWPAN (RFC 4944/6282) / IPv6 / RPL (RFC 6550, non-storing downward routing with RFC 6554, OF0 RFC 6552) / UDP / DTLS 1.3 (RFC 9147). IEEE 802.15.4 link binding; endpoint leaf role, participant-operated RPL root and routers. Locally provisioned ULA prefix, numeric peer addresses, 6LoWPAN neighbor discovery RFC 6775. RPL unsecured mode on an access-controlled link; DTLS does not protect routing control. End-to-end DTLS with distinct locally provisioned pairwise external PSKs, psk_ke and TLS_AES_128_GCM_SHA256; no 0-RTT, tickets or application authentication overlay. Fresh PSK handshakes allowed; no forward-secrecy claim for this PSK-only choice. No DNS, public CA, cloud broker, CoAP or MQTT dependency. No DTLS-terminating gateway: the final peers hold the traffic keys. Documentary composition; complete executable integration and sleep/overhead behavior remain unqualified. C03 configuration: enable IEEE 802.15.4 AES-128-CCM link security at level 7 (ENC-MIC128) for all established data frames carrying 6LoWPAN, including RPL unicast and multicast control, on every observed adjacency. Provision link keys locally, including a key usable for multicast delivery, and maintain non-repeating frame counters. This credits a passive radio observer without link keys; MAC headers remain visible and authorized routers decrypt RPL controls. RPL remains in unsecured mode; final-pair DTLS keys stay separate.", "website": "https://www.rfc-editor.org/rfc/rfc6550.html", "logo": "iot-rpl.svg" }, { "id": "HP", "title": "HIPv2 / ESP", "profile": "IPv4 or IPv6 / HIPv2 control (RFC 7401) and ESP-protected user traffic (RFC 7402), with host mobility RFC 8046. Independent deployment uses private IPv4, known numeric initial locators and pinned peer Host Identities/HITs; locally generated ECDSA P-256 identities, ECDH P-256, HIP ECDSA/SHA-384 HIT suite 2 and ESP AES-128-CBC with HMAC-SHA-256 (transform 8). Ordinary application UDP is carried inside the protected host-to-host data path, not as a HIP underlay tunnel. No DNS, rendezvous service, external CA, NAT-traversal extension or application authentication wrapper is selected. One moving endpoint with a reachable known peer; no simultaneous-mobility guarantee. Documentary composition; exact executable integration remains unqualified. G01 global deployment: conventional IPv6 Internet underlay with BGP/MP-BGP prefix routing, matching IP, PRP-over-IP and Multipath QUIC. Independent private deployment remains the separate S03/S04 capability; adjacent-only private IP meshes are not this global case. Global plausibility uses IPv6; retained private deployments and historical runtime/budget witnesses use IPv4. F37/F38: optional router-local AQM and independently administered DiffServ domains explicitly selected in the IP forwarding layer carrying HIP/ESP. Classification may use visible IP transport aggregates without decrypting ESP; no extra tunnel or application QoS reservation. F39 application-binding witness: use HIT-valued socket endpoints under the RFC 5338 application model, with the service bound to its chosen local HIT and UDP port. RFC 5338 explicitly describes connections to a local HIT. Apply that identifier/socket model to the selected HIPv2 identities; no legacy HIP wire version, old HIT hash suite, new resolver dependency or different remote ESP suite is imported.", "website": "https://www.rfc-editor.org/rfc/rfc7401.html", "logo": "hipv2.svg" }, { "id": "CX", "title": "CCNx 1.0", "profile": "IPv4 / UDP / CCNx 1.0 semantics RFC 8569 and TLV encoding RFC 8609. Independent deployment uses private IPv4, numeric adjacent forwarders, locally configured name-prefix FIB entries and known content names. Producer Content Objects use ECDSA-SHA256 signatures with locally generated keys explicitly trusted by consumers; no externally mandated name registry or certificate authority selected. Interests use CRC32C integrity checks, not authenticated consumer identities. In-network matching, pending Interests and caching follow CCNx semantics. No TLS, encrypted-session extension, application authentication wrapper or NDN/NLSR extension is added. Dynamic routing and automatic global name discovery are not silently supplied by static FIB configuration. Documentary composition; executable integration remains unqualified. G01 global deployment: conventional BGP-routed IPv4 Internet underlay, matching IP, PRP-over-IP and Multipath QUIC. Independent private deployment remains the separate S03/S04 capability; adjacent-only private IP meshes are not this global case. F37/F38: optional native RFC 8569 Interest Return behavior explicitly selected: locally congested forwarders discard Interests and report Congestion; preceding forwarders handle returns under section 10.3, including alternative next-hop selection when available. Per-forwarder name/interface ACLs and Prohibited handling selected under 10.3.6. Documentary capability, not measured congestion performance or executable integration. F39 bounded request/reply witness: one producer process owns the chosen globally scoped name prefix; use previously unrequested names with no matching cached response and configure the prefix toward that producer. The same name-based exchange reaches a local producer attachment or a remote producer through the selected network. No RPC framework, process migration, exactly-once execution, arbitrary duplex stream or new authentication layer is added.", "website": "https://www.rfc-editor.org/rfc/rfc8569.html", "logo": "ccnx.jpg" }, { "id": "LI", "title": "LISP", "profile": "IPv4 / UDP / LISP (RFC 9300 data plane and RFC 9301 control plane) / inner IPv4 / application UDP; configured EID prefixes and RLOCs; numeric peer and mapping-service addresses; participant-operated Map-Resolver and Map-Server with locally provisioned registration keys. No LISP-SEC, endpoint TLS/IPsec, or application identity layer selected. F09 architectural witness: two reachable best-priority RLOCs with zero weights, both delivering to the same destination EID; the ITR alternates successive useful packets of one UDP communication between them. Keep the outer UDP source port stable for the inner flow. Distinct provisioned underlay routes are required; no modified wire format or claimed implementation default. F37/F38: optional router-local AQM and independently administered DiffServ domains explicitly selected in the outer IPv4 transport. Outer packet conditioning/classification; RFC 9300 DSCP handling retained. No RSVP/IntServ or application reservation added.", "website": "https://www.rfc-editor.org/rfc/rfc9300.html", "logo": null }, { "id": "IL", "title": "ILNPv6", "profile": "ILNPv6 / TCP with ILNP identifier-only transport binding (RFC 6740 and RFC 6741); IPv6-compatible packet format with distinct 64-bit Identifier and Locator semantics, not an outer IPv6 tunnel; RFC 6743 Locator Updates and RFC 6744 Nonce Destination Option; locally generated NIDs, Router Advertisements and neighbour discovery; DNS NID/L64 discovery per RFC 6742. Host mobility between authorized attachments with overlap, a stationary reachable correspondent, and unchanged NIDs during the TCP connection. No IPsec, TLS, CGA identity binding or multipath TCP selected. Experimental specification; executable composition not qualified. F37/F38: optional local AQM and independently administered DiffServ policies explicitly selected in the IPv6-compatible forwarding plane; Traffic Class retained, no extra outer IP tunnel. No RSVP/IntServ or application reservation added. F39 application witness: a well-behaved socket application retains a participant name and TCP service port; ILNP-aware resolution supplies the current Identifier-Locator vector. A local service listens on its assigned vector or wildcard. Host-local routing delivers to the co-resident service; remote delivery uses the same naming/socket model and identifier-bound transport. No application switch to localhost or AF_UNIX is required. The pinned public Linux ILNP prototype corroborates local-path plausibility; its static-hosts resolver setup is not claimed as a runtime validation of the selected DNS NID/L64 composition.", "website": "https://www.rfc-editor.org/rfc/rfc6740.html", "logo": null }, { "id": "TS", "title": "Tailscale", "profile": "Tailscale Linux clients using WireGuard over UDP/IP on the routed Internet; Tailscale-managed coordination and an external identity provider for user enrollment. Tailnet Lock enabled with participant-controlled signing nodes; explicit restrictive network grants. Direct node-to-node payload paths with DERP/TLS relay fallback, ending at the two Tailscale nodes. Standard TUN client, not tsnet or userspace proxy mode. No Headscale, subnet/exit-node endpoint substitution, application TLS, content protocol or additional preshared post-quantum secret selected. Documentary profile, not a pinned runtime certification. F37/F38: explicitly selected optional router-local AQM and independently administered DiffServ domains on outer IP transport, classifying tunnel/DERP connection aggregates without inspecting encrypted inner traffic. No application QoS reservation or requirement to copy inner DSCP; not universal public-network deployment.", "website": "https://tailscale.com/", "logo": "tailscale-label.svg" }, { "id": "RA", "title": "RINA", "profile": "RINA application flows over recursively composed normal DIFs, with an Ethernet shim at the bottom; participant-operated enrollment and management, locally configured application names and DIF membership. Select QoS-aware flow allocation and per-DIF congestion-control policies acting on aggregate lower-layer flows. IRATI/Linux is the implementation reference for subsequent qualification, not a claim that a pinned executable configuration has been validated. No IP shim, external naming authority or application security wrapper is supplied; selected native modes are stated explicitly below. Current positive entries establish documented architectural mechanisms; implementation coverage, security and operational adoption require separate evidence. Mobility witness: additionally select the native Wi-Fi shim and local mobman two-provider make-before-break policy documented in IRATI Tutorial 10, with two interfaces and preconfigured DIF membership. This is a bounded mobility mode, not an IP overlay or a validated combined deployment; no security suite is imported from the demonstrator. Redundant-path mode: additionally select native static routing with two entries for the same destination/QoS and distinct next hops, default PDUFT generation and default PFF/RMT, over provisioned loop-free paths converging on one receiving IPCP. Source inspection establishes proactive copying; this is an explicit optional mode, not the default Dijkstra or the per-flow multipath plugin. Use a DTCP-enabled flow when duplicate handling is required; complete duplicate/reordering behavior and the combined deployment remain untested. Authentication mode: select native PSOC_authentication-ssh2 version 1 for IPCP enrollment, locally generated RSA keys of at least 2048 bits and locally provisioned peer-name/public-key bindings, with EDH, AES256, SHA256 and deflate under default SDU protection. The pinned code implements finite-field ephemeral DH, despite the README elliptic-curve wording. This custom SSH2-inspired mechanism is not asserted to be SSH interoperability or an audited modern security construction. Authentication scope is the enrolled IPCP; final application identity exposure remains a separate qualification; end-host content protection requires the upper-DIF placement specified below. No post-quantum KEM is selected. End-host confidentiality mode: place an additional normal DIF with only the two endpoint-host IPCPs above the routed transit DIFs; select the declared SSH2-inspired authentication and AES256 SDU protection between these two members. Applications register to this upper DIF. Transit nodes participate only in lower DIFs and do not hold the upper-DIF keys. This native recursive composition is an architectural/source-supported option, not a validated combined deployment. The endpoint OS/IPCP is trusted; protection between mutually untrusted applications sharing that OS is not claimed. For passive established-traffic assessment, enable the selected SDU encryption on every normal-DIF adjacency, including the lowest normal DIF above Ethernet/Wi-Fi; no plaintext normal-DIF adjacency exception is selected. Link framing and bootstrap remain outside the encrypted normal-DIF PDU.", "website": "https://pouzinsociety.org/", "logo": "rina-label.svg" } ], "criteria": [ { "id": "F01", "title": "Operates without IPv4/IPv6 throughout the stack", "definition": "No mandatory IP layer, including operational support.", "method": "Specification and test", "research_action": "Fix non-IP binding, bootstrap and support dependencies; run without IP." }, { "id": "F02", "title": "Needs no participant IP address configuration", "definition": "Participant-facing addressing uses a self-generated address or a non-IP participant namespace; no assigned participant IP address is needed at that layer. Underlay and relay transport IP configuration are excluded uniformly and remain assessed by F01/F03. This is not zero-configuration deployment: other identifiers, peers, trust and permissions may need provisioning.", "method": "Specification and test", "research_action": "Trace endpoint creation and bootstrap; distinguish application and underlay configuration." }, { "id": "F03", "title": "Routed operation needs no topology-dependent address configuration", "definition": "No network-prefix, subnet or locator assignment tied to attachment in the selected stack, including its underlay. DHCP/SLAAC automate such configuration rather than remove it. Locally generated identities and session-local forwarding labels do not count. Excludes route policy, trust, permissions and physical/link setup.", "method": "Specification", "research_action": "Trace address assignment across the selected stack; distinguish topology-dependent locators from self-generated identities and local forwarding labels. F02 concerns participant provisioning; F03 concerns the routed network as a whole." }, { "id": "F04", "title": "Cryptographic reference independent of location", "definition": "Participant or service reference verifiable independently of its locator; not necessarily self-certifying.", "method": "Specification", "research_action": "Trace reference creation and key binding; distinguish identity, certificate and locator." }, { "id": "F05", "title": "Peer continuity and authorization across sessions", "definition": "A peer continuity and authorization context survives the end of a session and a change of carrier. No particular object name, data structure or protocol-specific lifecycle is required. A stable identity key alone does not establish retained authorization context.", "method": "Specification", "research_action": "Establish what peer continuity and authorization state survives session termination and carrier changes, and how it is reused for a later session. Evaluate documented behavior regardless of implementation terminology; a stable key alone is insufficient." }, { "id": "F06", "title": "Encrypts content between communicating endpoints", "definition": "Protection between the compared endpoints, not merely a transit link.", "method": "Specification", "research_action": "Fix the end-to-end profile and key custody; identify every encryption termination point." }, { "id": "F07", "title": "Cryptographically authenticates a remote participant", "definition": "Remote identity or signed authorship proof; does not imply civil identity, mutual authentication or current presence.", "method": "Specification", "research_action": "Specify whose identity is proved, to whom, and whether proof covers a live session or stored message." }, { "id": "F08", "title": "Preserves a transport connection across path changes", "definition": "The same connection survives; reconnecting with the same contact does not qualify. UDP alone has no connection.", "method": "Specification and test", "research_action": "Define address/path change and connection lifetime; test continuity, replay and reordering." }, { "id": "F09", "title": "Uses simultaneous paths for one communication", "definition": "Concurrent useful data paths, rather than sequential failover or probes.", "method": "Specification", "research_action": "Fix scheduler, path policy and extension; distinguish multiple sessions from one communication." }, { "id": "F10", "title": "Proactively duplicates data across distinct paths", "definition": "Intentional redundancy before loss, rather than retransmission after loss.", "method": "Specification and test", "research_action": "Find replication and deduplication rules; test physically diverse paths and resource costs." }, { "id": "F11", "title": "Retains messages for delivery after disconnection", "definition": "Deferred delivery storage, not transient transport buffers.", "method": "Specification and test", "research_action": "Check persistence, expiry, capacity and recovery without a contemporaneous path." }, { "id": "F12", "title": "Multicast replication at network forwarders", "definition": "One-to-many network forwarding; application-relay fanout does not qualify. BP selects static collective fanout with implementation qualification pending.", "method": "Specification", "research_action": "Fix multicast routing and replication; distinguish broadcast, flooding and application pubsub." }, { "id": "F13", "title": "Group with multiple authorized senders and continuity across sessions", "definition": "Multiple authorized participants can send to a group. Membership and group authority are distributed, and group continuity is independent of individual session lifetimes. Matching terminology or a particular implementation is not required.", "method": "Specification", "research_action": "Identify sender authorization, membership and distributed authority rules; trace group continuity across session termination and subsequent participation. Apply the same behavioral requirements to every selected stack." }, { "id": "F14", "title": "Explicit goal of concealing endpoint location", "definition": "Location-hiding mechanism; not immunity to global correlation.", "method": "Specification", "research_action": "Define observer and profile; inventory visible identity, adjacency and location metadata." }, { "id": "F15", "title": "Architectural protection of processing and state against unauthorized traffic", "definition": "The selected composition provides a documented admission or early-rejection mechanism together with bounded state or computational work at an identified protected boundary. Identify pre-admission CPU, memory, queue and state costs, the work deferred until admission, and the required local policy. Native configurable mechanisms may qualify within selected layers. Encryption, finite hardware or an anti-amplification byte cap alone does not qualify. Yes credits scoped architectural protection, not a measured service floor or protection from every admitted attacker. Link-capacity protection is assessed separately in F26.", "method": "Primary specification and source analysis; experiments are complementary", "research_action": "Identify CPU/state admission ordering and bounds; evaluate downstream link authorization separately in F26." }, { "id": "F16", "title": "Controls final-peer access without external firewall", "definition": "Final-peer network payload admission: allow locally authorized cryptographic peers, deny others before application payload delivery, and revoke old authority at a completed local cutover, including active paths and pending delivery. Native policy hooks and administrative teardown/restart are allowed; authorized service must remain available after cutover. Already delivered data, application-operation permissions, handshake/probe traffic, unrelated host services and DoS isolation are outside scope. Added application authentication or payload filtering is not credited.", "method": "Specification and test", "research_action": "Trace native final-peer admission and revocation at completed local cutover; see round063.html#policy." }, { "id": "F17", "title": "Operates without DNS", "definition": "No DNS from bootstrap through authorized traffic; names absent from packets alone are insufficient.", "method": "Specification and test", "research_action": "Fix peers, discovery, certificates and dependencies; initialize without DNS queries." }, { "id": "F18", "title": "DTN forwarding across discontinuous contacts", "definition": "Network intermediaries retain and later forward an admitted item across non-overlapping contacts, without a contemporaneous complete end-to-end path. A mailbox at a common server, transport buffering or reconnection alone does not qualify. Previously established trust and bounded expiry are allowed.", "method": "Specification and qualification", "research_action": "Trace A-to-B followed by B-to-C with no overlapping contacts, intermediate storage, expiry, cryptographic viability and duplicate handling; distinguish architecture from executable activation." }, { "id": "F20", "title": "Transit forwarding without per-end-to-end-flow state", "definition": "Transit can forward without a mandatory entry for each end-to-end flow or circuit. Routes, neighbor sessions and aggregate multicast state are allowed. Endpoint transport state is outside this transit-only test. Include selected overlay relays, not only the IP underlay.", "method": "Specification / state inventory", "research_action": "Inventory every selected transit role and its state keys/lifetimes. Distinguish aggregate routes and neighbor sessions from endpoint-flow/circuit entries and optional caches." }, { "id": "F21", "title": "Identify the communicating peer without extra application authentication", "definition": "The selected stack authenticates the final communicating peer and exposes that identity to the receiving application bound to the communication, without an added application authentication exchange. Neighbor identity, unauthenticated addresses or an unbound claim are insufficient. This does not supply civil identity, account roles, permissions or transit anonymity.", "method": "Specification and API provenance audit", "research_action": "Trace proof validation, application-visible identity and binding to the received channel/item. Separate final peer from relays, object authors and security sources; inspect close/rekey and stale-reference behavior." }, { "id": "F22", "title": "Shared-reference discovery of independent participants", "definition": "One shared reference can discover multiple independently identified participants, without an exclusive controller of that reference or a shared private identity. A bounded candidate set is sufficient; exhaustive enumeration and simultaneous delivery are not required. Only mechanisms in the declared stack count. Self-declaration does not establish membership legitimacy, service authorization or current availability.", "method": "Specification and bounded discovery qualification", "research_action": "Trace reference formation, independent declarations, multi-candidate lookup and candidate identity binding. Separate routing fanout, anycast and content retrieval from participant discovery; do not silently add a discovery application or module." }, { "id": "F23", "title": "Endpoint mobility without infrastructure routing control", "definition": "Supports an endpoint changing attachment or access network while preserving its peer identity and ongoing logical communication, without requiring the application to establish a new peer relationship or reconstruct communication. The endpoint must not need administrative control of infrastructure routes, prefix origination or an AS; moving an administratively controlled network with the endpoint does not qualify. Normal participant attachment, path authentication and automatic protocol signaling are allowed, including signaling intrinsic to a mesh or overlay; merely running routing code does not disqualify a participant. Ordinary network access permission is not authority to originate infrastructure routes. Evaluate a supported endpoint role and state its limits; client-only support can qualify. Mere route repair with stationary endpoints, or retaining an identifier while restarting communication, is insufficient. Lossless handover, simultaneous mobility of both endpoints and indefinite disconnection are not required. Only mechanisms in the declared stack count.", "method": "Specification and endpoint-movement qualification", "research_action": "Move an ordinary participant between attachments with no new infrastructure route/prefix/AS privileges. Trace retained identity and communication state, automatic locator/path updates and application-visible behavior. List access permissions separately from routing authority. Exclude administrator-driven prefix/AS relocation. Record role, interruption, loss and timeout; test existing runtime qualifications separately." }, { "id": "F24", "title": "Reception coordinated with endpoint sleep periods", "definition": "An endpoint may suspend transmission and reception during planned periods and wake at known opportunities to receive data. The sender or an intermediary responsible for delivery coordinates attempts with those opportunities, retaining data when necessary. The mechanism lets the receiver determine when to listen without remaining continuously active. Reconnecting on wake, receiver-initiated periodic polling, or retransmissions unaware of receiver availability do not suffice. Custody alone does not suffice without coordinated delivery. F27 separately evaluates negotiation of communication windows.", "method": "Reassessment required under owner-approved definition; historical verdict not carried forward", "research_action": "Identify how the receiver learns wake/listen opportunities, who coordinates delivery, which traffic follows the schedule, and retention/expiry behavior. Specify clock or relative timing, tolerance and schedule changes. Do not inherit old F24 reenrollment evidence or F25 byte budgets; no measured energy saving is implied." }, { "id": "F26", "title": "Prevents unauthorized traffic from consuming downstream link capacity", "definition": "The selected composition provides a native transit admission or authorization check before transmission on an identified onward link. Traffic lacking the required local forwarding authority is rejected or constrained there, protecting subsequent links from that traffic. Identify the enforcement point, onward links protected, required policy and costs already incurred upstream. Local adjacency or forwarding authority may suffice; intermediaries need not know final endpoint identity. Endpoint-only filtering, encryption, receiver flow control and congestion control alone do not qualify. Yes does not imply protection of the ingress medium already traversed, RF-jamming resistance, guaranteed bandwidth or containment of every authorized attacker. Missing boundary evidence remains Pending; No applies only to the selected composition.", "method": "Primary architectural and forwarding-policy analysis; no bandwidth benchmark required", "research_action": "Locate the transit authorization check before onward transmission; identify protected downstream links and the remaining ingress exposure." }, { "id": "F27", "title": "Negotiated communication windows", "definition": "The selected composition explicitly provides for participants to agree on temporal availability windows for transmission and periods of inactivity between them. The transmitter follows the agreed receiver availability rather than relying only on retries after disappearance. Identify the negotiating roles, protocol layer and carrier dependency. A scoped architectural requirement can qualify; unspecified procedures, timing parameters or wire formats must remain explicit qualifications. Local sleep timers, congestion windows, generic buffering and reconnection alone do not qualify. This does not by itself establish uninterrupted cryptographic-session retention or measured energy savings.", "method": "Primary architectural or protocol evidence; distinguish specified capability from executable realization", "research_action": "Identify the availability-window agreement, acceptance and direction; document duration/spacing, clock basis, changes, expiry, pending-data handling and which data/control/cover traffic obeys it. Distinguish retained relationships, logical connections and cryptographic sessions. No result is inherited from F18, F24 or F25." }, { "id": "F28", "title": "Explicit endpoint path selection", "definition": "The sending endpoint can select a forwarding path or constrain the intermediaries used for its communication, beyond choosing only the destination or local access interface. Identify the exposed granularity, such as nodes, domains or path segments, and how the selected path is enforced. Selection among paths offered by infrastructure may qualify; independent path discovery is not required. Automatic multipath scheduling without endpoint path control does not qualify. This does not establish knowledge of hidden underlay hops or freedom from all routing authorities.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify the endpoint interface for selecting or excluding intermediaries, available path information, enforcement and failure behavior. State path granularity and remaining infrastructure dependencies. Distinguish F09 concurrent paths and F23 mobility." }, { "id": "F29", "title": "Named-content retrieval without prior server selection", "definition": "A requester can use a content reference to discover or reach a suitable supplier, replica or cache without selecting the serving endpoint beforehand. Direct named-data forwarding and reference-based supplier discovery can both qualify. The selected profile must bind the reference to the requested content; generic participant discovery alone is insufficient. Subsequent application transfer is allowed and must be disclosed. Host-name resolution alone does not qualify. Content authenticity and cross-requester caching are assessed separately.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify the content-reference binding, supplier discovery or forwarding mechanism, and who chooses the serving source. Disclose any profile convention and application transfer. Do not require one information-centric wire design; distinguish F22 generic participant discovery, F30 verification and F31 caching." }, { "id": "F30", "title": "Verify content authenticity independently of its delivery connection", "definition": "The selected composition supplies object-level cryptographic evidence that lets a recipient verify an object against an authorized origin or trusted reference after delivery through an intermediary or a different connection. Evidence must remain bound to the object rather than solely to the live transport. A signature, suitable MAC or digest bound to an independently trusted reference may qualify within its stated trust model. A bare checksum or a hash received only from the untrusted supplier does not establish authenticity. Public verification by arbitrary recipients is not required.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify the protected object and metadata, verification evidence, trust/reference acquisition and verifier roles. Check verification after forwarding or storage. Distinguish origin authentication, reference integrity and freshness; do not infer replay protection or civil identity." }, { "id": "F31", "title": "Serve other requesters from an intermediate copy", "definition": "An intermediary in the selected composition can retain a reusable content object and satisfy a later request by another requester from that copy, avoiding a new transfer from the original source. Describe cache admission, lookup, serving and validity rules. Storage dedicated to forwarding one queued message to its original recipient, retransmission buffers and caching supplied only by an unselected application do not qualify. Persistence across restarts and guaranteed cache hits are not required.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify a cross-requester cache-serving path, object matching, authorization and freshness or expiry rules. Distinguish F11 deferred messages, F18 discontinuous contacts and F29 named retrieval. Document source-transfer savings without inventing a hit rate." }, { "id": "F32", "title": "Route planning using future contacts and capacity", "definition": "The selected composition can compute or select a route using known or predicted future contact opportunities and their usable transfer capacities, so that forwarding decisions account for when a link will exist and whether it can carry the item. Externally supplied plans may qualify; participants need not negotiate the contacts. Merely waiting for connectivity, using current link costs, or accepting a local transmission timetable without route planning does not qualify.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify contact times, rates or volumes, route computation and capacity feasibility. Document plan provenance, clock assumptions, stale-plan handling and capacity accounting. Distinguish F18 store-and-forward and F27 negotiated windows; do not infer guaranteed delivery." }, { "id": "F33", "title": "Reliable transfer adapted to prolonged delay and interruption", "definition": "The selected composition provides retransmission-based reliable transfer with documented timer or recovery behavior adapted to prolonged propagation delays and interruptions of the transfer opportunity. Explicit suspension/resumption of recovery timers or another specified mechanism can qualify. Ordinary short-outage retries, arbitrary enlargement of a timeout, or storage without reliable-transfer recovery are insufficient. Identify the supported delay/interruption conditions and state retained; no unlimited outage tolerance is implied.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify acknowledgment/checkpoint and retransmission behavior, delay estimation, contact-loss signals, timer suspension or equivalent adaptation, resumption and expiry limits. Distinguish F18 routing/storage, F24 endpoint reenrollment and F27 negotiated availability. Assess protocol capability separately from performance measurements." }, { "id": "F34", "title": "Connect existing endpoints through a transparent bridge", "definition": "Integration with existing networks: the selected composition bridges layer-2 frames across multiple forwarding hops while preserving the link service presented to attached endpoints without requiring changes to those endpoints. Identify the supported frame/link type; the existing evaluated service is Ethernet, including unicast, broadcast/multicast, forwarding or learning and MTU constraints. Using Ethernet as a carrier or routing IPv6 ULA packets does not itself provide this service. A hypothetical bridge adapter or unselected tunnel is insufficient. No unlimited broadcast-domain scale is required.", "method": "Primary architectural or protocol evidence for the selected composition; distinguish capability from execution", "research_action": "Identify endpoint attachment and the multi-hop Ethernet data path, upper-layer transparency, forwarding/loop controls and frame-size limitations. Distinguish F01 non-IP operation and F35 incremental deployment." }, { "id": "F36", "title": "Application-requested communication quality", "definition": "An application can request communication properties such as capacity, delay or reliability, and the network uses those requirements in flow admission and resource allocation. Identify how requests map to offered service and how unsupported requests are handled. Packet priority marking alone does not qualify. No unconditional performance guarantee is implied.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "research_action": "Identify the application request interface, admission/allocation decision and service mapping. Distinguish capability from measured guarantees and F32 future-contact route planning." }, { "id": "F37", "title": "Congestion control targeted at the affected path segment", "definition": "The selected composition can identify a congested intermediate link or bounded network region and adjust traffic at or toward that affected segment. Control may be local or coordinated by the endpoint responsible for the trajectory. Identify the congestion indication, its scope, the controlling participant and the traffic adjustment. A protocol-level capability to report localized saturation and renegotiate traffic at that segment may qualify architecturally. Generic end-to-end loss or delay without localization, static priority alone, and telemetry without an associated control capability do not suffice. No specific wire command, aggregate-flow controller, RINA layer, measured response time or lossless guarantee is required.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "research_action": "Identify the localized congestion signal or local observation, affected link/region, controller and available traffic adjustment. Endpoint-directed control and intermediate autonomous control are both admissible. Separate capacity negotiation from a response to saturation; distinguish architectural evidence from execution." }, { "id": "F38", "title": "Let each operator enforce local access and resource priorities", "definition": "Each transport scope can administer its resources and establish and enforce local access and priority conditions, respecting agreements with participants, without requiring one uniform policy throughout the network. Identify the scope, policy owner, controlled resources and enforcement point. Scopes may be adjacent or nested; recursive layers and hidden internal topology are not required. Configurable local preferences alone do not suffice without control of the relevant resources. F36 separately assesses participant-requested service quality, and F37 response to congestion. Local autonomy does not imply unlimited resources, arbitrary violation of agreements or absence of higher-level constraints.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "research_action": "Identify independently administered transport scopes, local access/priority policy and resource enforcement. Explain how different local conditions can coexist along a communication. Do not require nesting, topology abstraction or RINA-style layers. Distinguish local policy authority from the ability merely to request QoS." }, { "id": "F39", "title": "Communicate with local or remote participants through the same interface", "definition": "Applications communicate with processes on the same host or another host through the same communication abstraction and logical participant references. The stack selects local delivery or a network path without requiring the application to switch IPC APIs or encode the peer physical location. Local zero-copy is an optional optimization, not a requirement. This criterion concerns communication, not process migration or distributed execution.", "method": "Architectural mechanism and primary-source review; author declarations explicitly attributed", "research_action": "Identify the application interface, logical peer reference, local-delivery mechanism and remote path selection. A shared socket API alone is insufficient if the application must explicitly select localhost versus a remote host address." }, { "id": "C01", "title": "Same destination address reachable through an alternative path", "definition": "When a path becomes unavailable, the architecture permits reaching the same destination address over another available and authorized path, including through a different destination attachment. The sender need not substitute the address, obtain an alternative address from an external service, or rely on application redirection. Route discovery and fresh session establishment are allowed. A merely physical alternative counts only if the selected protocol can use it. Recovery of transit to an unchanged advertised prefix alone does not establish independence from the destination attachment.", "method": "Reassessment required under owner-approved definition; historical verdict not carried forward", "research_action": "Identify the stable destination address, failed attachment/path, usable alternative attachment, discovery and forwarding mechanisms. Distinguish transit failure from loss of the attachment associated with an address. State required routing authority/configuration and failure boundaries; no uninterrupted-session requirement." }, { "id": "C02", "title": "Conceals the final destination from the first intermediary", "definition": "A non-colluding intermediary sees its decrypted state and traffic. Excludes direct endpoint communication.", "method": "Specification and capture", "research_action": "Inventory keys, fields, control queries and forwarding tables; check final identity and location exposure." }, { "id": "C03", "title": "Conceals protocol control fields in established traffic", "definition": "Passive observation of established protected traffic, excluding bootstrap. Assess exposed control fields and protocol markers; timing/volume inference is separate. This is not a claim of complete protocol indistinguishability.", "method": "Specification", "research_action": "Map cleartext and encrypted established-packet fields, including outer framing; do not use initial bootstrap exposure as a negative." }, { "id": "C04", "title": "Includes a defense against active-probe identification", "definition": "An uncredentialed adversary probes an endpoint and observes replies and timing; no endpoint compromise.", "method": "Specification and test", "research_action": "Define valid, invalid and replay probes; inspect disclosures before authorization against a control service." }, { "id": "C05", "title": "Bootstraps while external DNS is unavailable", "definition": "Initial state as specified in the column, with no DNS cache. Does not cover blocking all peers or directories.", "method": "Specification and test", "research_action": "Disable DNS before process startup; inventory discovery and trust. F17 is the corresponding functional capability." }, { "id": "C06", "title": "Conceals the final-peer association in forwarding identifiers", "definition": "A transit observer cannot identify the pair of final interlocutors solely from addresses and flow identifiers visible in established packets. Identifiers on an adjacency may reveal the participants of that segment, but must not directly reveal the final pair or provide a common end-to-end identifier linking that association across observed segments. Evaluate equivalents of the IP five-tuple, circuit labels and connection IDs. Payload encryption with the final pair exposed, or changing identities only between sessions, is insufficient. Timing/volume correlation is assessed separately in C07.", "method": "Reassessment required under owner-approved definition; historical verdict not carried forward", "research_action": "Inventory visible fields at each selected observation point, including tunnel terminators and participating relays. State observer keys/access and where protection ends; do not infer whole-path protection from one encrypted segment. Trace identifier translation across adjacencies and distinguish local segment identities from final-peer association." }, { "id": "C07", "title": "Includes a defense against entry/exit correlation", "definition": "Includes a mechanism that reduces observable timing/volume information for cooperating observers. Optional padding or cover traffic can qualify; effectiveness and deployment defaults are separate, and complete correlation prevention is not required.", "method": "Specification; effectiveness by experiment", "research_action": "Identify padding, batching, mix or cover mechanisms and their scope; separately measure correlation reduction and cost under a fixed observer model." }, { "id": "S01", "title": "Communication without a mandatory separate authority", "definition": "Willing peers can communicate from local information without a separate mandatory naming, routing, identity, governance or ledger authority. Network directory authorities and domain certification roles count; counterpart admission policies do not. Underlay allocation is assessed separately.", "method": "Specification", "research_action": "Identify any indispensable third-party approval, registry, consensus signer or trust anchor in the selected network. Test direct operation without that external service." }, { "id": "S02", "title": "Participant identity requires no external issuer", "definition": "Participants generate a usable cryptographic identity locally; counterparties decide whether to trust or authorize it. Does not imply civil identity.", "method": "Specification", "research_action": "Trace key creation, reference registration and acceptance; determine whether an issuer must authorize creation." }, { "id": "S03", "title": "Selected stack needs no external address/name allocation", "definition": "Independent deployment needs no public address allocation, DNS delegation or externally assigned domain identifier. Private/local addressing may qualify; Internet reachability is a separate requirement.", "method": "Specification and test", "research_action": "Fix deployment boundary, private/public underlay and name resolution; inventory allocator and delegation dependencies." }, { "id": "S04", "title": "Independent operation under participant-controlled administration", "definition": "Participants can deploy and maintain an operational domain with all mandatory control, trust and coordination components under their own administration, without authorization or an indispensable operational service from a specific external vendor or operator. Locally operated authorities are allowed, as is direct peer operation without such authorities. Choosing among external service providers alone does not qualify. This does not guarantee global reachability, freedom from external address allocation, seamless migration or immunity from a local administrator.", "method": "Complete-stack administrative dependency review", "research_action": "Inventory bootstrap, enrollment, trust renewal, naming, routing, discovery and coordination dependencies in the selected composition. Establish whether participants can operate all mandatory services and trust roles themselves. Distinguish optional outsourced services from fixed vendor activation, mandatory public directories or external approval. Keep address/name allocation in S03, issuer-free identities in S02 and absence of any separate mandatory authority in S01. Preserve the selected deployment: do not substitute a private clone of a declared public network." }, { "id": "G01", "title": "Global reachability without complete global reachability tables", "definition": "The complete selected stack permits global reachability without requiring a complete global reachability table at transit nodes or control services. Include prefix, identity and other identifier reachability, and required underlay routing. Moving that table upstream or into a directory does not qualify. Partitioned state is allowed; this is not zero state or a quantitative capacity guarantee.", "method": "End-to-end architecture and state inventory", "research_action": "Inventory every transit and control role, including discovery, upper aggregators and the underlay. Establish how arbitrary reachable destinations are located without a mandatory complete global table. A local default route, local labels or a small private deployment alone are insufficient." }, { "id": "G02", "title": "Scope-limited updates after participant attachment changes", "definition": "A participant attachment change can be accommodated without disseminating its individual identity or location throughout the network. Updates remain within the affected region and participants maintaining relevant communication state, while reachability from elsewhere is preserved. Evaluate a destination that changes attachment, not only an initiating client reconnecting. An example where nothing relevant changes for external routing is insufficient. This evaluates update scope, separately from C01 address reachability and F23 logical communication continuity.", "method": "Reassessment required under owner-approved definition; historical verdict not carried forward", "research_action": "Trace destination attachment change, affected state, update recipients and reachability from outside the affected region. Include required underlay and control services. Explain what prevents global per-participant dissemination and disclose wider-update cases; do not infer a quantitative convergence or global-capacity guarantee." }, { "id": "G03", "title": "Discovery and forwarding without a complete identity catalog at every node", "definition": "A transit node can support discovery and forwarding without being required to maintain a complete catalog of final identities in the network. Neighbor records, local relationships, partial caches, aggregates and distributed queries are allowed. A mandatory global hosts.txt-equivalent at each node does not qualify. This consolidates the owner-clarified identity-catalog concern previously discussed as C08; the former C08 traffic-history-retention criterion is retired. G01 separately examines required complete global reachability state anywhere in the selected stack, including control services and underlay.", "method": "Reassessment required under owner-approved definition; historical verdict not carried forward", "research_action": "Inventory identity state needed for cold discovery and forwarding at each node role; distinguish local/partial records from obligatory complete catalogs. Trace cache misses and distributed lookup. Neither absence of traffic logging nor a low query cost follows automatically; G01/G05 retain their separate scope." }, { "id": "G04", "title": "Scale-out without a fixed-capacity coordination point", "definition": "Added infrastructure can distribute routing/discovery work without an obligatory single fixed-capacity coordinator. Decentralization alone is insufficient.", "method": "Architecture and bottleneck analysis", "research_action": "Map complete-stack coordination dependencies, partitioning, replication and failure recovery." }, { "id": "G05", "title": "Plausibility of global operation", "definition": "A credible architectural route to a connected network of at least 10 billion devices using contemporary equipment and realistic regional interconnection. Assess namespace, routing/discovery state placement, aggregation, control traffic, search work and update behavior in the selected complete stack. Distributed state and growing aggregate resources are allowed. Documentary mechanisms, resource models, proportional simulations and operational experience can support Yes; world-scale deployment or a full-scale simulation is not required. No requires an evidenced architectural or resource obstruction in the selected composition under the common setting; insufficient evidence remains Pending. Prior targets (1 s discovery, 1 h admission, 99.9% coverage, 5% of domestic 1 Gbit/s per direction, 64 GB per transit equipment and 1000 destinations/device/day) remain sizing references, not jointly certified pass/fail thresholds. Keep identities owned separate from destinations accessed. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending.", "method": "Architectural plausibility assessment using documented evidence", "research_action": "Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending. Documentary or bounded analytical evidence can suffice; no global simulation is required." }, { "id": "E01", "title": "Public interoperability between independent implementations", "definition": "At least two independently developed implementations exchanged traffic for the selected profile in a publicly documented test. Shared standardization work does not negate implementation independence; two wrappers around the same core do not qualify. Credit only tested functions.", "method": "Documentary evidence with explicit scope", "research_action": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E02", "title": "Published independent security analysis", "definition": "A third party has published a security audit or formal analysis of security-critical mechanisms of the selected profile. Identify analysis type, scope, assumptions, version and conflicts of interest. Paid independent review can qualify; publication does not imply a clean result or complete security.", "method": "Documentary evidence with explicit scope", "research_action": "Find the actual report and authorship; distinguish implementation audit, protocol analysis and formal verification. Confirm coverage of the selected composition rather than only an underlying primitive." }, { "id": "E03", "title": "Public open-source implementation of the selected profile", "definition": "At least one publicly obtainable implementation covers the selected profile with its necessary implementation components available under OSI-approved licenses. Official reference status is not required. Public specifications or partial demonstration code alone do not qualify.", "method": "Documentary evidence with explicit scope", "research_action": "Locate public code, exact version, license texts, dependencies and supported profile scope. A private checkout or absent implementation files in a specification mirror does not decide public availability." }, { "id": "E04", "title": "Published independent quantitative measurements", "definition": "An independent party has published at least one quantitative measurement of an implementation of the protocol, describing the scenario, method and results. The measured configuration must be identifiable and relevant to the functionality assessed. Explicitly state differences from the selected profile and the measured mechanism. Exact versions of every executable, raw data, scripts and reproduction instructions strengthen evidence but are not mandatory. Another implementation or configuration is admissible when it preserves the relevant measured mechanism. Promotional numbers without a method, exclusively theoretical results and measurements only by the evaluated implementation developers do not qualify. A Yes establishes the existence of bounded external measurements, not their favorable outcome or validation of all capabilities.", "method": "Independent publication and measured-mechanism applicability", "research_action": "Find an independent quantitative publication with an identifiable scenario, method and results; name the measured mechanism and explain applicability and configuration differences. Exact binary pins and replay artifacts are supporting evidence, not prerequisites." }, { "id": "E05", "title": "Real-world use by independent operators", "definition": "Public, attributable evidence that a person, community or organization independent of the protocol authors uses the protocol to meet a real need, beyond tests or demonstrations. Personal and community use count. There is no minimum duration or requirement to reproduce every option of the selected column. Record the actual deployment scope, version, transport and duration where known. This measures adoption, not validation of all technical properties in the column.", "method": "Attributable operator evidence; adoption-level scope", "research_action": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending." }, { "id": "D01", "title": "Unprivileged routine endpoint operation", "definition": "A supported ordinary endpoint can perform the selected communication on an identified general-purpose OS without root/admin or equivalent elevated networking capabilities during routine operation. Disclose any privileged installation, provisioning or helper; those are not silently counted as unprivileged runtime.", "method": "Documentary evidence with explicit scope", "research_action": "Pin OS/version, endpoint role, executable, capabilities and helpers. Separate install/configure privileges from sustained operation. An untested adapter or UDP binding alone does not decide this criterion." }, { "id": "D02", "title": "Operation without an additional kernel module", "definition": "A supported endpoint operates on an identified general-purpose OS without installing an additional kernel module or rebuilding its kernel. Stock networking modules and drivers are allowed; disclose required OS features and configuration.", "method": "Documentary evidence with explicit scope", "research_action": "Verify implementation installation/runtime dependencies and stock-OS support. Distinguish userspace architecture from a tested deployment and kernel configuration from an additional module." }, { "id": "D03", "title": "Operation without specialized hardware", "definition": "A supported endpoint can execute the selected profile on commodity computing/network hardware, without a mandatory specialized radio, accelerator or secure element. Ordinary NICs are allowed; identify carrier constraints and do not replace the selected stack.", "method": "Documentary evidence with explicit scope", "research_action": "Document hardware requirements and a supported endpoint configuration. Optional accelerators do not negate the capability; mandatory physical-link hardware must remain in scope." }, { "id": "D04", "title": "Create additional communication identities without network administration", "definition": "Over an already authorized and provisioned transport, an ordinary user can create and use additional independently controlled communication identities without network-administration privileges or modifying shared interface addresses, prefixes or routes. Identity creation must not require per-identity host-network reconfiguration or administrator provisioning. Peer acceptance and transport-access permissions remain separate. This does not promise unlimited resources, anonymity, or isolation from all resource contention.", "method": "Specification and implementation-boundary review", "research_action": "Trace identity generation, custody and protocol use for a second ordinary user. Identify any per-identity privileged operation, shared address/interface mutation or administrator allocation. Credit only identity mechanisms in the selected stack; an extra application authentication layer is not implicit. Separate this architectural capability from D01 full endpoint runtime privileges, F03 topology-dependent addressing and S02 external identity issuance." }, { "id": "K01", "title": "Post-quantum end-to-end key establishment", "definition": "The selected end-to-end key-establishment construction provides documented post-quantum confidentiality against recorded-traffic decryption, using a suitable post-quantum KEM or justified hybrid construction. Identify algorithms, combiner, negotiation and downgrade conditions. This alone does not establish post-quantum authentication against active attackers.", "method": "Documentary evidence with explicit scope", "research_action": "Inspect the actual selected key-establishment suite, not identity-signature options. Verify hybrid composition and negotiation; distinguish passive confidentiality from authentication and overall protocol security." }, { "id": "L01", "title": "Unrestricted use and implementation of the specification", "definition": "The publicly available specification permits use and implementation for any purpose, including commercial use, without field-of-use restrictions or individual permission. Attribution and redistribution obligations must be disclosed. Modification does not imply compatibility, conformance or endorsement. This does not require permission to republish altered normative prose as an official standard, and does not assess patent rights (L02) or implementation-code licensing (E03). Cover the required layers of the selected profile.", "method": "Documentary evidence with explicit scope", "research_action": "Verify authoritative use/implementation permissions across the selected specification layers; distinguish notices and compatibility claims from restrictions on use. Assess patent grants separately in L02." }, { "id": "L02", "title": "Declared royalty-free patent commitment", "definition": "An attributable holder declaration or published commitment explicitly offers royalty-free implementation of the selected profile for applicable claims under the declaring holder's control. A recorded direct holder declaration is admissible for every project; publication or registry entry is reported separately, not required for Yes. State attribution, scope, conditions and publication status. This assesses the declared policy, not execution or enforceability of a patent license, third-party patent clearance, or copyright permission. An express patent grant attached to the selected implementation is admissible within its stated Work or contributor-version scope; it is not a promise covering every independent reimplementation. The same holder-bounded rule applies to direct declarations and public grants.", "method": "Documentary evidence with explicit scope", "research_action": "Obtain a dated attributable holder declaration or applicable public grant; identify scope, conditions and publication status. Do not infer a commitment solely from open development, copyright licensing or IETF participation." } ], "cells": [ { "id": "F01-PN", "feature": "F01", "stack": "PN", "status": "Y", "reason": "Architecture 5.7 permits native non-IP operation; wire-v4 sections 4 and 9 use scoped selectors and cryptographic identities rather than participant IP addresses. This credits the documented native composition, not a tested adapter. Selecting and validating a physical/link binding remains an implementation task, not evidence of a mandatory IP layer.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F01-PI", "feature": "F01", "stack": "PI", "status": "N", "reason": "This column explicitly selects IPv4/UDP as the PRP transport substrate. PRP's carrier-independent architecture does not remove IPv4 from this particular composition; the native PRP column is evaluated separately. The negative concerns the selected stack, not a mandatory IP dependency of PRP itself.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [], "editorial_references": [ "index.html#round072" ], "qualification": "" }, { "id": "F01-IP", "feature": "F01", "stack": "IP", "status": "N", "reason": "This column is the IP network layer itself: IPv4 or IPv6.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-BP", "feature": "F01", "stack": "BP", "status": "N", "reason": "The selected composition uses TCPCLv4 over TLS/TCP/IPv4. RFC 9174 section 1 and Figure 1 place that convergence layer above TCP and IP. BP permits other convergence layers, but replacing this one would change the compared profile.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-1" ], "editorial_references": [], "qualification": "" }, { "id": "F01-CG", "feature": "F01", "stack": "CG", "status": "N", "reason": "The declared TCPCL transport uses IPv4. CGR does not remove that selected dependency; other convergence layers would be separate profiles.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9174, TCPCLv4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-LT", "feature": "F01", "stack": "LT", "status": "Y", "reason": "The selected Encapsulation/AOS binding carries LTP segments directly; no IP transport or online IP-based support service is selected.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "LTP for CCSDS, 734.1-B-1", "sources": [ "https://ccsds.org/Pubs/734x1b1.pdf" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F01-LP", "feature": "F01", "stack": "LP", "status": "N", "reason": "The selected libp2p transport is QUIC over UDP/IPv4. QUIC's UDP transport and the declared IPv4 substrate remain necessary in this composition even though Peer IDs are independent of addresses. Other libp2p transports are not credited implicitly.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-12" ], "editorial_references": [], "qualification": "" }, { "id": "F01-TO", "feature": "F01", "stack": "TO", "status": "N", "reason": "This column selects public Tor with TCP/TLS relay connections over IPv4. Onion-service addressing does not replace the IP substrate carrying those relay connections. The conclusion follows from the complete selected composition, not from how an application names the destination.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://research.torproject.org/techreports/datagram-comparison-2011-11-07.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F01-I2", "feature": "F01", "stack": "I2", "status": "N", "reason": "NTCP2 carries router-to-router I2NP messages over TCP in the selected IPv4 deployment. Destination keys and tunnels are overlay mechanisms; they do not remove the selected router transport's IP layer. This is not a claim about every conceivable I2P transport.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "" }, { "id": "F01-YG", "feature": "F01", "stack": "YG", "status": "N", "reason": "The selected Yggdrasil profile includes both TCP/TLS over IPv4 between peers and IPv6 application traffic inside the overlay. Its automatic key-derived addressing does not mean operation without IP throughout the stack. The official configuration describes TCP/TLS peering and the overlay IPv6 addresses.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://yggdrasil-network.github.io/configuration.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-CJ", "feature": "F01", "stack": "CJ", "status": "N", "reason": "The selected cjdns profile uses UDP/IPv4 peering and carries IPv6 application traffic. Cryptographically derived IPv6 addresses remain IP addresses. Even support for other peering mechanisms would not establish an entirely IP-free version of this selected application stack.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/README.md" ], "editorial_references": [], "qualification": "" }, { "id": "F01-MQ", "feature": "F01", "stack": "MQ", "status": "N", "reason": "The selected multipath QUIC composition retains UDP/IPv4/IPv6 beneath QUIC. Adding paths or copying STREAM data across validated paths changes transport operation, not the presence of IP. No non-IP QUIC binding is selected.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-12", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-SC", "feature": "F01", "stack": "SC", "status": "N", "reason": "The selected SCION deployment explicitly uses an IPv4/UDP underlay. The official deployment tutorial configures IP/UDP addresses for routers and services. This is a profile-specific negative: SCION packet-carried paths do not make the chosen underlay disappear, and alternate link realizations are not silently added.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://docs.scion.org/en/latest/tutorials/deploy.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-RT", "feature": "F01", "stack": "RT", "status": "Y", "reason": "SerialInterface carries Reticulum directly; IP interfaces and local TCP sharing are excluded from the selected profile.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/interfaces.html#serial-interface" ], "editorial_references": [], "qualification": "" }, { "id": "F01-NS", "feature": "F01", "stack": "NS", "status": "N", "reason": "This composition uses IPv4; Nostr does not replace its transport addressing.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F01-MT", "feature": "F01", "stack": "MT", "status": "Y", "reason": "The selected standalone radio deployment forwards Meshtastic packets without an IPv4/IPv6 network. Local serial access adds no IP dependency; Internet bridges are excluded explicitly.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/introduction/" ], "editorial_references": [], "qualification": "" }, { "id": "F01-GN", "feature": "F01", "stack": "GN", "status": "N", "reason": "The selected UDP transport requires IPv4; transport modularity does not remove this declared underlay.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet TRANSPORT handbook, v0.20.x; current introductory sections only", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-ND", "feature": "F01", "stack": "ND", "status": "Y", "reason": "Direct Ethernet faces and local Unix sockets provide the selected path without an IP transport.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 face management", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "Validate the full Ethernet/Unix-only deployment and management path without IP interfaces." }, { "id": "F01-AX", "feature": "F01", "stack": "AX", "status": "Y", "reason": "NET/ROM network and transport headers ride directly over AX.25; no IP layer is selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F01-BA", "feature": "F01", "stack": "BA", "status": "Y", "reason": "The selected native Ethernet service runs without IP; the documentation's optional IP usage example is not mandatory.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "Exercise native frame forwarding with all IP addresses removed; no kernel namespace test performed." }, { "id": "F01-BL", "feature": "F01", "stack": "BL", "status": "N", "reason": "IPv6 is the selected data and control underlay. Babel does not replace IP.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-RI", "feature": "F01", "stack": "RI", "status": "N", "reason": "The selected 6LoWPAN/RPL/UDP/DTLS composition explicitly carries IPv6. Header compression does not eliminate that mandatory network layer.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "This is a property of the selected IPv6 stack, not a limitation on every protocol usable over IEEE 802.15.4." }, { "id": "F01-HP", "feature": "F01", "stack": "HP", "status": "N", "reason": "The selected HIP control and ESP data paths both use IPv4/IPv6. Identity/locator separation does not remove that layer.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "This No concerns the declared complete stack, not HIP identity generation." }, { "id": "F01-CX", "feature": "F01", "stack": "CX", "status": "N", "reason": "This column explicitly binds CCNx to IPv4/UDP. The possibility of native non-IP CCNx does not remove the selected binding.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "A native binding would require a separate profile; do not interpret this as a universal CCNx dependency." }, { "id": "F01-LI", "feature": "F01", "stack": "LI", "status": "N", "reason": "The selected data plane encapsulates inner IPv4 in outer IPv4/UDP; it requires IP.", "method": "Specification review", "source_label": "RFC 9300 (data plane) and RFC 9301 (control plane)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-IL", "feature": "F01", "stack": "IL", "status": "N", "reason": "The complete selected composition retains IP dependencies: it explicitly uses IPv6 Router Advertisements and neighbour discovery, plus conventional DNS transport. ILNPv6 reinterprets the IPv6-format identifier/locator fields rather than adding an outer IPv6 tunnel; that distinction does not remove these selected support dependencies.", "method": "Specification review; unchanged selected profile", "source_label": "rfc6740.html#section-4.1; rfc6740.html#section-4.3; rfc6742.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.1", "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.3", "https://www.rfc-editor.org/rfc/rfc6742.html" ], "editorial_references": [], "qualification": "" }, { "id": "F01-TS", "feature": "F01", "stack": "TS", "status": "N", "reason": "The selected data transport uses UDP/IP and managed control connectivity also needs IP. Overlay identity does not remove the underlay.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F01-RA", "feature": "F01", "stack": "RA", "status": "Y", "reason": "The IRATI tutorial instantiates a normal DIF over an Ethernet VLAN shim and exchanges application data through it. Management uses a local Unix socket. The shown active DIF chain needs no IP carrier; loading an unused TCP/UDP shim module does not make that shim a transport dependency.", "method": "Primary specification and implementation documentation review; no runtime experiment", "source_label": "RFC 1633, RFC 7567, RFC 2475 or IRATI Ethernet tutorial, as linked", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)" ], "editorial_references": [ "round650.html" ], "qualification": "Documentary non-IP witness for the selected Ethernet composition. Software installation/download infrastructure is not treated as a mandatory operational carrier. No full selected-policy execution or runtime reproduction claimed." }, { "id": "F02-PN", "feature": "F02", "stack": "PN", "status": "Y", "reason": "PRP participants use cryptographic identities and scoped selectors rather than an assigned participant IP address. F02 excludes transport-underlay addressing uniformly: the IP-carried profile still requires its IPv4/UDP substrate, while native PRP does not. Neither result promises automatic trust, discovery, route policy or carrier setup.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F02-PI", "feature": "F02", "stack": "PI", "status": "Y", "reason": "PRP participants use cryptographic identities and scoped selectors rather than an assigned participant IP address. F02 excludes transport-underlay addressing uniformly: the IP-carried profile still requires its IPv4/UDP substrate, while native PRP does not. Neither result promises automatic trust, discovery, route policy or carrier setup.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F02-IP", "feature": "F02", "stack": "IP", "status": "N", "reason": "The selected IP participant endpoint uses an assigned network-layer IP address. SLAAC or DHCP can automate provisioning but still supplies the network prefix/locator needed by that endpoint; there is no separate self-generated participant namespace replacing it in this standalone IP column.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc6724.html#section-5" ], "editorial_references": [], "qualification": "" }, { "id": "F02-BP", "feature": "F02", "stack": "BP", "status": "Y", "reason": "The participant-facing endpoint is an EID, such as the selected ipn identifier, rather than an IP address. EID allocation and configuration are still required; this is not zero configuration. TCPCLv4 transport locators remain necessary underneath and are assessed in F01/F03, not counted selectively against this F02 cell.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1" ], "editorial_references": [], "qualification": "" }, { "id": "F02-CG", "feature": "F02", "stack": "CG", "status": "Y", "reason": "Participant references are BP endpoint identifiers, distinct from convergence-layer IP addresses. Identifier and contact provisioning still remain.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "F02-LT", "feature": "F02", "stack": "LT", "status": "Y", "reason": "BP endpoint identifiers name participants; adjacent LTP engine and channel configuration is not participant IP assignment.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F02-LP", "feature": "F02", "stack": "LP", "status": "Y", "reason": "The participant is identified by a locally derived Peer ID, separate from its transport multiaddresses. IP listeners and reachable transport addresses still need setup in the selected QUIC stack. F02 credits only absence of assigned participant IP addressing, applying the same underlay exclusion as for Yggdrasil/cjdns.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://libp2p.io/docs/peers/" ], "editorial_references": [], "qualification": "" }, { "id": "F02-TO", "feature": "F02", "stack": "TO", "status": "Y", "reason": "The selected onion service is named by its key-derived v3 onion address, not a provisioned participant IP address. Relay IP connectivity and local service configuration remain necessary. This concerns onion-service naming, not public Internet destinations reached through exits.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://spec.torproject.org/rend-spec/encoding-onion-addresses.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-I2", "feature": "F02", "stack": "I2", "status": "Y", "reason": "An I2P application participant uses a Destination containing cryptographic key material. Router transport addresses and tunnel/contact information are separate. NTCP2/IP configuration remains in the selected substrate; it does not become participant IP assignment under this namespace-only row.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://www.i2p.net/en/docs/specs/common-structures/" ], "editorial_references": [], "qualification": "" }, { "id": "F02-YG", "feature": "F02", "stack": "YG", "status": "Y", "reason": "The participant-facing IPv6 address is derived from the node key rather than assigned from an attachment-dependent prefix. TCP/TLS peer connectivity still uses underlay IP configuration. This limited positive does not establish configuration-free routed operation of the complete stack.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://yggdrasil-network.github.io/configuration.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-CJ", "feature": "F02", "stack": "CJ", "status": "Y", "reason": "The participant-facing IPv6 address is derived from its public key. The selected UDP/IPv4 peer substrate still needs transport locators. F02 credits self-generated participant addressing; F03 separately counts the underlying routed-address configuration.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/README.md" ], "editorial_references": [], "qualification": "" }, { "id": "F02-MQ", "feature": "F02", "stack": "MQ", "status": "N", "reason": "The selected QUIC endpoint uses IP/UDP addresses to establish and validate transport paths. Connection IDs demultiplex connections and support migration; they do not create a participant-address namespace that removes endpoint IP provisioning. Locally configured certificates do not replace these transport addresses.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-8.2" ], "editorial_references": [], "qualification": "" }, { "id": "F02-SC", "feature": "F02", "stack": "SC", "status": "N", "reason": "The selected SCION endpoint is addressed by ISD-AS plus a host address, with IPv4/IPv6 host addressing in this profile. SCION paths and trust roots do not generate a replacement participant address. This negative concerns the selected host addressing, independently of the separate IP underlay dependency.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-RT", "feature": "F02", "stack": "RT", "status": "Y", "reason": "The selected Reticulum Link over serial interfaces needs no participant IP address. Native destination references and local key material remain; discovery, interface and permission configuration are not eliminated by this result.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://reticulum.network/manual/interfaces.html#serial-interface" ], "editorial_references": [], "qualification": "" }, { "id": "F02-NS", "feature": "F02", "stack": "NS", "status": "Y", "reason": "The NIP-01 participant is the event author identified by a public key, not an assigned participant IP address. Clients still configure relays and use WSS/IP; relay service locators are not removed. This row credits author-namespace provisioning only, not peer-to-peer routing, relay independence or a new application layer.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F02-MT", "feature": "F02", "stack": "MT", "status": "Y", "reason": "The node uses a non-IP node number derived from its public key. No participant IP address is assigned at this layer. Radio setup and key verification are separate provisioning tasks.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/configuration/radio/security/" ], "editorial_references": [], "qualification": "" }, { "id": "F02-GN", "feature": "F02", "stack": "GN", "status": "Y", "reason": "CADET addresses a peer by its public key and port, independently of the underlying IP address.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-ND", "feature": "F02", "stack": "ND", "status": "Y", "reason": "Applications request named data; this Ethernet-face profile assigns no participant IP address.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 face management", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-AX", "feature": "F02", "stack": "AX", "status": "Y", "reason": "Endpoints use callsigns/SSIDs and aliases, not participant IP addresses.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux AX.25 HOWTO: NET/ROM port configuration", "sources": [ "https://tldp.org/HOWTO/AX25-HOWTO/x1218.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-BA", "feature": "F02", "stack": "BA", "status": "Y", "reason": "This native frame profile addresses participants at Ethernet level, without assigned participant IP addresses.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-BL", "feature": "F02", "stack": "BL", "status": "N", "reason": "The selected participant-facing service uses configured IPv6 addresses.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-RI", "feature": "F02", "stack": "RI", "status": "N", "reason": "The selected endpoint communicates using IPv6/UDP addresses. Its PSK identity labels authenticate peers but do not replace participant-facing IPv6 addressing with a separate routable namespace.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "Local ULA assignment and automatic configuration remain address provisioning. Apply the same distinction used for the selected QUIC column." }, { "id": "F02-HP", "feature": "F02", "stack": "HP", "status": "Y", "reason": "HIP presents a self-generated Host Identity Tag to the upper layer, separately from the underlying routed IP locator. A participant does not need an assigned topology-dependent address at that identity layer.", "method": "Documentary capability and suite review; no runtime execution", "source_label": "Primary HIP/CCNx specifications and unchanged selected profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round254-sources.json", "round246.html" ], "qualification": "The 128-bit HIT uses an ORCHID prefix but is not a routed locator. Underlying IPv4 configuration remains required and separately assessed in F01/F03; this is not zero-configuration deployment." }, { "id": "F02-CX", "feature": "F02", "stack": "CX", "status": "Y", "reason": "CCNx Interests and Content Objects use content names rather than assigned participant IP addresses at the CCNx layer. The selected known-name composition therefore does not require participant-facing IP allocation.", "method": "Documentary capability and suite review; no runtime execution", "source_label": "Primary HIP/CCNx specifications and unchanged selected profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round254-sources.json", "round246.html" ], "qualification": "Numeric IPv4/UDP forwarder contacts still need configuration underneath CCNx. Name provisioning, FIB entries and trust are also required; these are not silently removed." }, { "id": "F02-LI", "feature": "F02", "stack": "LI", "status": "N", "reason": "End systems use assigned IPv4 EIDs. Separating EIDs from RLOCs does not remove participant IP address provisioning (RFC 9300 section 3).", "method": "Specification review", "source_label": "RFC 9300 (data plane) and RFC 9301 (control plane)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F02-IL", "feature": "F02", "stack": "IL", "status": "Y", "reason": "The participant-facing NID can be generated locally and is distinct from the topology-dependent Locator. RFC 6740 section 4.1 permits local identifier creation using IPv6 identifier-generation techniques. Locator acquisition remains required and is already assessed separately by F03; this is not zero-configuration deployment.", "method": "Specification review; unchanged selected profile", "source_label": "rfc6740.html#section-3.1; rfc6740.html#section-4.1", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.1" ], "editorial_references": [], "qualification": "" }, { "id": "F02-TS", "feature": "F02", "stack": "TS", "status": "N", "reason": "Tailscale assigns participant IP addresses to nodes. Automatic assignment is still assignment; the criterion requires a participant namespace that needs no assigned participant IP.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/tailscale-ip-addresses" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F02-RA", "feature": "F02", "stack": "RA", "status": "Y", "reason": "Applications register RINA names with the normal DIF rather than receiving participant IP addresses. The tutorial shows a directory entry mapping an application name to an IPC-process address; this is a non-IP namespace.", "method": "Primary specification and implementation documentation review; no runtime experiment", "source_label": "RFC 1633, RFC 7567, RFC 2475 or IRATI Ethernet tutorial, as linked", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)" ], "editorial_references": [ "round650.html" ], "qualification": "F02 excludes other configuration: DIF names, IPC-process addresses, membership and VLAN provisioning remain necessary. This does not establish F03 or zero-configuration routing." }, { "id": "F03-PN", "feature": "F03", "stack": "PN", "status": "Y", "reason": "Native PRP separates cryptographic identity from topology and uses session-scoped forwarding selectors (architecture 4.2, 4.8, 5.7; wire-v4 sections 4 and 9). It needs no topology-based address/prefix assignment. Local labels and forwarding state remain necessary. Architectural capability, not a demonstrated deployment or automatic-routing benchmark.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "F03-PI", "feature": "F03", "stack": "PI", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-IP", "feature": "F03", "stack": "IP", "status": "N", "reason": "IP forwarding uses configured network-layer addresses and routed prefixes. Automatic assignment does not remove topology-dependent addressing.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-BP", "feature": "F03", "stack": "BP", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-CG", "feature": "F03", "stack": "CG", "status": "N", "reason": "The chosen routed IPv4 underlay still requires topology-dependent addressing. Scheduled bundle routing does not eliminate it.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9174, TCPCLv4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-LT", "feature": "F03", "stack": "LT", "status": "Y", "reason": "Stable node/engine identifiers and adjacent channel mappings do not require attachment-dependent network prefixes. Contact-plan and identifier provisioning still remain.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "Encapsulation Packet Protocol, 133.1-B-3", "sources": [ "https://ccsds.org/Pubs/133x1b3e1.pdf" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F03-LP", "feature": "F03", "stack": "LP", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-TO", "feature": "F03", "stack": "TO", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-I2", "feature": "F03", "stack": "I2", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-YG", "feature": "F03", "stack": "YG", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-CJ", "feature": "F03", "stack": "CJ", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-MQ", "feature": "F03", "stack": "MQ", "status": "N", "reason": "This selected stack includes routed IPv4/IPv6 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-SC", "feature": "F03", "stack": "SC", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-RT", "feature": "F03", "stack": "RT", "status": "Y", "reason": "The selected non-IP composition uses coordination-less identities and self-configuring multi-hop transport, without subnet or attachment-dependent address assignment. Link settings remain outside this criterion.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/whatis.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-NS", "feature": "F03", "stack": "NS", "status": "N", "reason": "This selected stack includes routed IPv4 and therefore retains topology-dependent network-prefix and interface address configuration in its underlay. Automated provisioning does not eliminate that addressing model. An overlay may generate its own identity/address automatically; alternative non-IP compositions are not classified here. Scope inference from the declared stack and IP addressing model.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "F03-MT", "feature": "F03", "stack": "MT", "status": "Y", "reason": "Routing uses node numbers, a destination-specific next-hop hint and managed flooding, not prefixes or subnets tied to attachment. Radio frequency/region setup remains necessary but falls outside this address-configuration criterion.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp#L313" ], "editorial_references": [], "qualification": "" }, { "id": "F03-GN", "feature": "F03", "stack": "GN", "status": "N", "reason": "Numeric private-IPv4 contacts still require underlay address provisioning; peer keys do not replace that configuration.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet TRANSPORT handbook, v0.20.x; current introductory sections only", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-ND", "feature": "F03", "stack": "ND", "status": "Y", "reason": "No topology-dependent IP locator is configured. Content-prefix routes remain explicit; route policy is outside F03.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 face management", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-AX", "feature": "F03", "stack": "AX", "status": "Y", "reason": "Callsign-based destination routes do not require subnet/prefix assignment; port and route configuration still remains.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux AX.25 HOWTO: NET/ROM port configuration", "sources": [ "https://tldp.org/HOWTO/AX25-HOWTO/x1218.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-BA", "feature": "F03", "stack": "BA", "status": "Y", "reason": "The virtual-switch service needs no topology-dependent subnet assignment; interface attachment and MAC provisioning remain.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-BL", "feature": "F03", "stack": "BL", "status": "N", "reason": "ULA prefix/interface addressing remains provisioned; Babel distributes reachability rather than eliminating address configuration.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Locally assigned IPv6 ULA, RFC 4193", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-RI", "feature": "F03", "stack": "RI", "status": "N", "reason": "The selected network provisions a ULA prefix and IPv6 locators. RPL can distribute prefix information for address configuration, but that automates rather than removes prefix/locator configuration.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "This does not assert that every change of RPL parent changes the endpoint address; the criterion concerns whether the routed composition needs such address configuration at all." }, { "id": "F03-HP", "feature": "F03", "stack": "HP", "status": "N", "reason": "Both selected IP versions retain topology-dependent address/prefix provisioning. HIP identities remain distinct from these locators; automatic provisioning does not remove that model.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Automatic address configuration would not satisfy F03; this finding does not deny host mobility." }, { "id": "F03-CX", "feature": "F03", "stack": "CX", "status": "N", "reason": "The private IPv4/UDP underlay retains subnet/address configuration even though the CCNx forwarding namespace uses content names.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Name-prefix forwarding and underlay address configuration are distinct." }, { "id": "F03-LI", "feature": "F03", "stack": "LI", "status": "N", "reason": "The selected underlay still requires topology-dependent IP RLOC configuration. EID/RLOC separation does not remove this requirement across the complete stack.", "method": "Specification review", "source_label": "RFC 9300 (data plane) and RFC 9301 (control plane)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-IL", "feature": "F03", "stack": "IL", "status": "N", "reason": "Locators are topology-dependent subnetwork prefixes. Router Advertisements automate their acquisition but do not remove topology-dependent configuration across the routed network (RFC 6740 sections 3.2 and 4.1).", "method": "Specification review", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F03-TS", "feature": "F03", "stack": "TS", "status": "N", "reason": "The selected Internet underlay retains topology-dependent IP addressing. Stable overlay addresses do not eliminate that routed-network requirement.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F03-RA", "feature": "F03", "stack": "RA", "status": "N", "reason": "Stable application names do not eliminate routed address assignment. RINA assigns IPC-process addresses within each DIF; these are location-dependent forwarding names. The selected IRATI deployment configures name-to-address mappings per DIF, including separate mobile-provider and Internet-DIF instances. This fails the complete-stack requirement to dispense with attachment-related locator assignment.", "method": "Architecture, configuration and documented mobility-mode inspection; no new runtime test", "source_label": "ETSI RINA architecture report and IRATI configuration/mobility documentation", "sources": [ "https://www.etsi.org/deliver/etsi_gr/NGP/001_099/009/01.01.01_60/gr_ngp009v010101p.pdf", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/mobile.dif", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/mobile2.dif", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/internet.dif" ], "editorial_references": [ "round663.html" ], "qualification": "Application users need not configure IP addresses. Flat addresses can survive access-point changes inside one DIF; F03 does not require renumbering on every move. This verdict concerns DIF-scoped routed addressing, not Ethernet setup, trust policy or session-local port labels. See ETSI sections 7.1 and 7.4 and IRATI README section 3.2.2.3." }, { "id": "F04-PN", "feature": "F04", "stack": "PN", "status": "Y", "reason": "The selected PRP identity profile uses an IDENTITY SCIR whose suite-defined digest commits to canonical public-key material. A verifier can recompute that reference independently of a route or locator and use the committed key to check protocol possession evidence. The reference itself neither proves current possession nor grants authorization; locator independence does not guarantee discovery or reachability.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [], "editorial_references": [ "index.html#round072", "round072-audit.json" ], "qualification": "" }, { "id": "F04-PI", "feature": "F04", "stack": "PI", "status": "Y", "reason": "The selected PRP identity profile uses an IDENTITY SCIR whose suite-defined digest commits to canonical public-key material. A verifier can recompute that reference independently of a route or locator and use the committed key to check protocol possession evidence. The reference itself neither proves current possession nor grants authorization; locator independence does not guarantee discovery or reachability.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [], "editorial_references": [ "index.html#round072", "round072-audit.json" ], "qualification": "" }, { "id": "F04-IP", "feature": "F04", "stack": "IP", "status": "N", "reason": "The selected datagram service supplies addresses, not cryptographic participant identity or a persistent authenticated relationship. No IPsec or upper-layer identity protocol is included.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-BP", "feature": "F04", "stack": "BP", "status": "Y", "reason": "A certificate can authenticate NODE-ID independently of the link locator. This is certification, not EID self-certification.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2" ], "editorial_references": [], "qualification": "" }, { "id": "F04-CG", "feature": "F04", "stack": "CG", "status": "Y", "reason": "The selected TCPCL NODE-ID certificate binds a node reference independently of its IP locator. Local trust validates the certificate; this is certified identity, not a self-certifying BP endpoint identifier.", "method": "Documentary architectural inference; no executable qualification", "source_label": "Primary specifications; selected-profile analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2" ], "editorial_references": [], "qualification": "Validate the declared complete composition and local management in an executable deployment; this decision is not measured scale, conformance or interoperability." }, { "id": "F04-LT", "feature": "F04", "stack": "LT", "status": "Y", "reason": "In the declared exact-origin pairwise-key profile, the source EID selects a configured security policy and is protected by primary-block integrity together with payload coverage. Verification is independent of LTP engine/channel locators. This is a pre-established cryptographic EID-to-key binding, not a self-certifying EID or public verification by arbitrary observers. The verifier also holds the symmetric key, so this is not nonrepudiation.", "method": "Specification plus pinned receiver-policy analysis; no runtime experiment", "source_label": "BIB-HMAC-SHA2 integrity scope and native EID-indexed receiver policy", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc9172.html#section-6", "https://www.rfc-editor.org/rfc/rfc9758.html#section-5.5", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bpsec/policy/bpsec_policy_rule.c" ], "editorial_references": [ "round193-sources.json" ], "qualification": "Keep the same EID/key policy while changing provisioned adjacent transport mapping; verify primary and payload authentication, reject source substitution and test wrong keys. Complete transport integration and secure key provisioning remain unqualified." }, { "id": "F04-LP", "feature": "F04", "stack": "LP", "status": "Y", "reason": "A Peer ID is derived from serialized public-key material and can be checked independently of transport multiaddresses. Secure-channel authentication binds that key to the communicating peer; a Peer ID alone neither locates the peer nor establishes reachability.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://libp2p.io/docs/peers/" ], "editorial_references": [], "qualification": "" }, { "id": "F04-TO", "feature": "F04", "stack": "TO", "status": "Y", "reason": "A v3 onion address encodes the service's Ed25519 identity public key with version and checksum. The service reference is independent of its network locator. The checksum is not a signature or proof of current possession; the onion-service protocol supplies the separate authentication procedure.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://spec.torproject.org/rend-spec/encoding-onion-addresses.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-I2", "feature": "F04", "stack": "I2", "status": "Y", "reason": "An I2P Destination carries signing-key material; its hashed reference is independent of router transport locators. LeaseSets supply separate signed reachability information. This credits the destination reference, not RouterInfo addresses or an assumption that reference possession authenticates a live sender.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://www.i2p.net/en/docs/specs/common-structures/" ], "editorial_references": [], "qualification": "" }, { "id": "F04-YG", "feature": "F04", "stack": "YG", "status": "Y", "reason": "The selected node address is a cryptographic derivation of its public key rather than its underlay location. This credits node identities, not arbitrary hosts in the separately advertised /64: the documentation notes the reduced binding strength of that prefix. Address checks and session authentication remain distinct.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://yggdrasil-network.github.io/configuration.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-CJ", "feature": "F04", "stack": "CJ", "status": "Y", "reason": "cjdns derives a node's IPv6 address from its public key, independently of the UDP/IP peer locator. This is a cryptographic node reference under the selected direct-node profile; it does not promise discovery, reachability or civil identity.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/README.md" ], "editorial_references": [], "qualification": "" }, { "id": "F04-MQ", "feature": "F04", "stack": "MQ", "status": "Y", "reason": "QUIC authenticates a server identity through TLS (RFC 9001 sections 2.1 and 4.4), independently of a particular path locator. This is certificate/credential-based authentication, not self-certification or a persistent relationship object.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html#section-4.4" ], "editorial_references": [], "qualification": "" }, { "id": "F04-SC", "feature": "F04", "stack": "SC", "status": "N", "reason": "The selected application-UDP stack identifies a final endpoint by ISD-AS and host address, without an added locator-independent cryptographic participant reference. SCION infrastructure trust and path authentication do not by themselves bind an application participant to such a reference. Adding endpoint TLS or another identity layer would change this column.", "method": "Documentary review; no protocol execution", "source_label": "Primary specification / uniform participant-namespace scope", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-RT", "feature": "F04", "stack": "RT", "status": "Y", "reason": "A SINGLE destination hash incorporates its public key and remains usable when its location changes.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html#destination-naming" ], "editorial_references": [], "qualification": "" }, { "id": "F04-NS", "feature": "F04", "stack": "NS", "status": "Y", "reason": "The public key identifies the author independently of the relay.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F04-MT", "feature": "F04", "stack": "MT", "status": "Y", "reason": "A full public key is a location-independent cryptographic reference for direct-message authentication. The 32-bit node number alone is not a collision-resistant identity proof; this decision credits the confirmed full key.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/CryptoEngine.cpp#L287" ], "editorial_references": [], "qualification": "" }, { "id": "F04-GN", "feature": "F04", "stack": "GN", "status": "Y", "reason": "The destination public key identifies the peer independently of its current transport locator.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-ND", "feature": "F04", "stack": "ND", "status": "Y", "reason": "A trusted producer key and signed name bind the content independently of the face carrying it.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NDN packet format v0.3 signatures", "sources": [ "https://docs.named-data.net/NDN-packet-spec/0.3/signature.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-AX", "feature": "F04", "stack": "AX", "status": "N", "reason": "A callsign/alias is an identifier, not a cryptographically verifiable location-independent reference.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F04-BA", "feature": "F04", "stack": "BA", "status": "N", "reason": "An Ethernet address is not a cryptographic participant reference; no identity-security layer is selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-BL", "feature": "F04", "stack": "BL", "status": "N", "reason": "The selected ordinary IPv6 address is a locator, not a cryptographic identity reference.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-RI", "feature": "F04", "stack": "RI", "status": "Y", "reason": "The selected pairwise PSK identity is a locally provisioned key reference verified by handshake possession proofs, independently of the numeric peer locator.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "The label alone is not a proof. This is a private credential binding, not a self-certifying public identity or nonrepudiation." }, { "id": "F04-HP", "feature": "F04", "stack": "HP", "status": "Y", "reason": "The HIT is derived from the Host Identity public key, and the base exchange authenticates possession of that identity independently of the current locator. The selected pinned HI/HIT therefore supplies a cryptographic reference that survives a locator change.", "method": "Documentary capability and suite review; no runtime execution", "source_label": "Primary HIP/CCNx specifications and unchanged selected profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round254-sources.json", "round246.html" ], "qualification": "The selected ECDSA identity and its acceptance policy remain necessary. A stable reference alone does not decide authorization persistence, privacy or runtime mobility." }, { "id": "F04-CX", "feature": "F04", "stack": "CX", "status": "Y", "reason": "For signed Content Objects, KeyId is a hash of the producer public key and signature validation binds that key to the object. This cryptographic producer reference is independent of the forwarder locator from which the content arrives.", "method": "Documentary capability and suite review; no runtime execution", "source_label": "Primary HIP/CCNx specifications and unchanged selected profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round254-sources.json", "round246.html" ], "qualification": "The consumer must validate the signature against its selected trusted key. A content name alone is not self-certifying, and producer authentication does not authenticate the live forwarding peer or the consumer." }, { "id": "F04-LI", "feature": "F04", "stack": "LI", "status": "N", "reason": "The selected EID is an IP address, not a cryptographically verifiable participant reference. Mapping-registration authentication does not make an end-host EID a cryptographic identity.", "method": "Specification review", "source_label": "RFC 9300 (data plane) and RFC 9301 (control plane)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-IL", "feature": "F04", "stack": "IL", "status": "N", "reason": "The selected locally generated Node Identifier is not bound to a cryptographic key. Location independence alone does not satisfy the cryptographic-reference criterion; an optional cryptographic construction is not selected (RFC 6740 sections 3.1 and 9.2).", "method": "Specification review", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F04-TS", "feature": "F04", "stack": "TS", "status": "Y", "reason": "A node key pair supplies a cryptographic identity distinct from its changing transport locator. This credits node identity, not a permanently immutable user key.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/tailscale-identity" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F04-RA", "feature": "F04", "stack": "RA", "status": "Y", "reason": "The selected enrollment policy binds a peer IPCP name to a locally pinned RSA public key. Its challenge-response verification uses that key rather than the current routing address, providing a cryptographically verifiable participant reference independent of location.", "method": "Pinned documentation and authentication source inspection with explicit policy selection; no execution or audit", "source_label": "IRATI SSH2-inspired authentication policy", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/sm-auth-psoc/sm-auth-psoc-plugin.cc" ], "editorial_references": [ "round665.html" ], "qualification": "This is a configured name/key association, not a self-certifying name or global naming service. Secure initial key distribution and continued correctness of the local binding are assumptions. This does not establish application-level peer authentication or cross-session authorization continuity." }, { "id": "F05-PN", "feature": "F05", "stack": "PN", "status": "Y", "reason": "PRP Architecture section 4.2 defines a persistent continuity and authorization context that can exist without a session, path or carrier. Relationship Lifecycle section 4 separates relationship policy, session generation, trajectories and aliases. This establishes the persistent context required by F05 for both carrier profiles; it does not certify storage durability, recovery implementation or application permissions.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [], "editorial_references": [ "index.html#round072", "round072-audit.json" ], "qualification": "" }, { "id": "F05-PI", "feature": "F05", "stack": "PI", "status": "Y", "reason": "PRP Architecture section 4.2 defines a persistent continuity and authorization context that can exist without a session, path or carrier. Relationship Lifecycle section 4 separates relationship policy, session generation, trajectories and aliases. This establishes the persistent context required by F05 for both carrier profiles; it does not certify storage durability, recovery implementation or application permissions.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [], "editorial_references": [ "index.html#round072", "round072-audit.json" ], "qualification": "" }, { "id": "F05-IP", "feature": "F05", "stack": "IP", "status": "N", "reason": "The selected datagram service supplies addresses, not cryptographic participant identity or a persistent authenticated relationship. No IPsec or upper-layer identity protocol is included.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-BP", "feature": "F05", "stack": "BP", "status": "Y", "reason": "The selected bounded F16 configuration already retains an ION/BSL APPOUT policy requiring primary-and-payload BIB verification with a locally named pairwise key and rejection on failure. The key is shared only with the single authorized remote sender, not transit. Retaining this admission rule and key registry across transport teardown lets subsequent bundles from that peer be authorized independently of the former convergence-layer session. ION loads policy and key-registry files separately from transport connections. The policy, rather than EID stability or queued bundles, supplies the retained authorization context. The old No omitted this selected native gate.", "method": "Selected-profile consistency correction; no runtime execution", "source_label": "Pinned ION/BSL policy loading and the selected native APPOUT admission witness", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bsl/bsl.c" ], "editorial_references": [ "round137-policy.json", "round137-sources.json", "round137.html", "round290-sources.json" ], "qualification": "Credit is limited to one authorized remote sender at a time under the existing F16 witness. Retain the configured rule and key registry when replacing transport/contact state; changing the authorized peer still requires the documented revocation cutover. The wildcard rule does not authenticate an arbitrary claimed source EID; continuity identifies the unique remote key holder. This is documentary capability, not a new ION execution, seamless mobility, automatic discovery or permission recovery. Reachability and native link provisioning remain separate. Complete TCPCL/TLS or LTP/Encapsulation/AOS integration and SABR mapping remain unqualified where already recorded; this decision concerns the retained BP endpoint policy. No new application authentication layer or profile change." }, { "id": "F05-CG", "feature": "F05", "stack": "CG", "status": "Y", "reason": "The selected bounded F16 configuration already retains an ION/BSL APPOUT policy requiring primary-and-payload BIB verification with a locally named pairwise key and rejection on failure. The key is shared only with the single authorized remote sender, not transit. Retaining this admission rule and key registry across transport teardown lets subsequent bundles from that peer be authorized independently of the former convergence-layer session. ION loads policy and key-registry files separately from transport connections. The policy, rather than EID stability or queued bundles, supplies the retained authorization context. The old No omitted this selected native gate.", "method": "Selected-profile consistency correction; no runtime execution", "source_label": "Pinned ION/BSL policy loading and the selected native APPOUT admission witness", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bsl/bsl.c" ], "editorial_references": [ "round137-policy.json", "round137-sources.json", "round137.html", "round290-sources.json" ], "qualification": "Credit is limited to one authorized remote sender at a time under the existing F16 witness. Retain the configured rule and key registry when replacing transport/contact state; changing the authorized peer still requires the documented revocation cutover. The wildcard rule does not authenticate an arbitrary claimed source EID; continuity identifies the unique remote key holder. This is documentary capability, not a new ION execution, seamless mobility, automatic discovery or permission recovery. Reachability and native link provisioning remain separate. Complete TCPCL/TLS or LTP/Encapsulation/AOS integration and SABR mapping remain unqualified where already recorded; this decision concerns the retained BP endpoint policy. No new application authentication layer or profile change." }, { "id": "F05-LT", "feature": "F05", "stack": "LT", "status": "Y", "reason": "The selected bounded F16 configuration already retains an ION/BSL APPOUT policy requiring primary-and-payload BIB verification with a locally named pairwise key and rejection on failure. The key is shared only with the single authorized remote sender, not transit. Retaining this admission rule and key registry across transport teardown lets subsequent bundles from that peer be authorized independently of the former convergence-layer session. ION loads policy and key-registry files separately from transport connections. The policy, rather than EID stability or queued bundles, supplies the retained authorization context. The old No omitted this selected native gate.", "method": "Selected-profile consistency correction; no runtime execution", "source_label": "Pinned ION/BSL policy loading and the selected native APPOUT admission witness", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bsl/bsl.c" ], "editorial_references": [ "round137-policy.json", "round137-sources.json", "round137.html", "round290-sources.json" ], "qualification": "Credit is limited to one authorized remote sender at a time under the existing F16 witness. Retain the configured rule and key registry when replacing transport/contact state; changing the authorized peer still requires the documented revocation cutover. The wildcard rule does not authenticate an arbitrary claimed source EID; continuity identifies the unique remote key holder. This is documentary capability, not a new ION execution, seamless mobility, automatic discovery or permission recovery. Reachability and native link provisioning remain separate. Complete TCPCL/TLS or LTP/Encapsulation/AOS integration and SABR mapping remain unqualified where already recorded; this decision concerns the retained BP endpoint policy. No new application authentication layer or profile change." }, { "id": "F05-LP", "feature": "F05", "stack": "LP", "status": "N", "reason": "Peer IDs and peer addresses do not define the required persistent continuity and authorization context in this minimal composition. Applications can add one. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://libp2p.io/docs/peers/" ], "editorial_references": [], "qualification": "" }, { "id": "F05-TO", "feature": "F05", "stack": "TO", "status": "Y", "reason": "With onion-v3 client authorization enabled, the service retains authorized-client public-key records and the client retains service-bound private credentials across circuits and transport sessions. This supplies the persistent authorization context required by F05, beyond a stable service name. This does not establish immediate revocation of established streams.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://tpo.pages.torproject.net/core/torspec/rend-spec/client-authorization.html" ], "editorial_references": [], "qualification": "Pin Tor and use filesystem client authorization. Rebuild circuits and restart endpoints while preserving the authorization records; inspect descriptor refresh and removal behavior separately. No connection-migration or instantaneous revocation claim; no execution performed." }, { "id": "F05-I2", "feature": "F05", "stack": "I2", "status": "N", "reason": "Core I2P supplies destinations, tunnels and client-router sessions, not a peer continuity and authorization context surviving session termination. I2CP explicitly destroys its session on disconnect. Persistent destination keys alone do not satisfy F05. Scope inference; Streaming remains excluded.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://i2p.net/en/docs/specs/i2cp/" ], "editorial_references": [], "qualification": "" }, { "id": "F05-YG", "feature": "F05", "stack": "YG", "status": "N", "reason": "The selected composition supplies node keys, configured peerings and routes. It does not define a peer continuity and authorization context independent of its transport sessions. Application relationships are outside this composition. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://yggdrasil-network.github.io/implementation.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-CJ", "feature": "F05", "stack": "CJ", "status": "N", "reason": "CryptoAuth sessions and persistent node keys provide authentication and forwarding, not the persistent peer continuity and authorization context required by F05. A configured peer or key is insufficient under the same rule applied to libp2p. Scope inference for the selected composition.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#the-cryptoauth" ], "editorial_references": [], "qualification": "" }, { "id": "F05-MQ", "feature": "F05", "stack": "MQ", "status": "Y", "reason": "The selected composition already includes mutual TLS authentication, locally trusted peer certificates and an explicit final-peer key allowlist (F16-MQ), with resumption and 0-RTT disabled. Retain that admission policy independently of QUIC connections. A new connection from another reachable attachment must prove the same admitted key in a fresh TLS handshake before delivery. The retained allow/deny decision supplies the authorization context; certificate stability alone does not. RFC 9001 section 4.4 provides QUIC peer authentication through TLS, while RFC 8446 separates credential verification from access control. The old No considered only connection state and resumption and omitted the selected policy.", "method": "Consistency correction using primary specifications; no runtime execution", "source_label": "QUIC/TLS peer authentication and the already selected local admission policy", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.2.4", "https://www.rfc-editor.org/rfc/rfc8446.html#section-6.2" ], "editorial_references": [ "round289-sources.json", "cells/F16-MQ.html", "round268.html", "round288.html" ], "qualification": "Documentary capability under explicitly retained local policy, using the same boundary as F05-HIP and F05-RI. It is not a default guarantee for arbitrary QUIC deployments. Keep admission records across connection teardown, enforce them in each fresh handshake and deny unlisted peers before application delivery. Provisioning, reachable numeric peers and carrier attachment remain prerequisites. No live handover, automatic identity discovery, crash-persistence, complete multipath-21 conformance or new runtime test is claimed. This corrects No to Yes; it does not close a previously Pending cell, alter the selected composition or add a new application authentication layer." }, { "id": "F05-SC", "feature": "F05", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP composition supplies endpoint addresses and packet-carried forwarding paths, not a persistent peer authorization and continuity context independent of transport lifetime. An application could supply such a context, but is not included. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-RT", "feature": "F05", "stack": "RT", "status": "N", "reason": "The selected Link owns connection state and keys and is torn down after its stale/keepalive timeout. A persistent destination key is not a retained context carrying peer continuity and authorization beyond connection lifetimes. Scope inference for Link, not all applications built on Reticulum.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [], "qualification": "" }, { "id": "F05-NS", "feature": "F05", "stack": "NS", "status": "N", "reason": "Events and subscriptions do not define the required continuity-and-authorization contract. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F05-MT", "feature": "F05", "stack": "MT", "status": "Y", "reason": "The selected F16 headless KNOWN_ONLY/STRICT witness includes locally authorized User records, confirmed full peer keys and an ignore policy, not merely retained destination keys. Router rejects unknown senders before first-contact learning and applies the retained cryptographic checks to admitted records. Keeping that configured admission context while delivery/radio activity stops allows later messages from the same authorized peer after a compatible authorized reattachment. No transport-session object is required by F05. The previous No considered per-message key derivation but omitted the already selected admission policy.", "method": "Selected-profile consistency correction; no runtime execution", "source_label": "Pinned Router and NodeDB plus the already selected F16 policy witness", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NodeDB.cpp" ], "editorial_references": [ "round122-sources.json", "round290-sources.json" ], "qualification": "Use the explicit F16 witness, not the separate C04/C08 CLIENT/ALL probe configuration or a database populated by arbitrary learned peers. Preserve authorized records, full-key bindings and ignore policy; peers must still share compatible radio/channel settings. No automatic channel migration, cross-medium bridging, replay suppression or new firmware/radio test is claimed. Storage and cold-start controls remain those already required by the selected witness. Packet-oriented operation does not by itself establish continuity: the retained admission decision is essential." }, { "id": "F05-GN", "feature": "F05", "stack": "GN", "status": "N", "reason": "CADET channels and their tunnel session persist while connected, but the selected profile supplies no final-peer authorization and continuity context independent of session lifetime. Stable peer keys alone do not meet F05.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-ND", "feature": "F05", "stack": "ND", "status": "N", "reason": "PIT, FIB, caches and provisioned trust support named-data retrieval, not a persistent authorization relationship between final peers. No application relationship protocol is selected.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "NFD 24.07 module and forwarding architecture", "sources": [ "https://docs.named-data.net/NFD/24.07/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-AX", "feature": "F05", "stack": "AX", "status": "N", "reason": "Circuit state supplies session flow/error control, not an authorization relationship surviving circuit lifetime. Callsign stability is insufficient.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F05-BA", "feature": "F05", "stack": "BA", "status": "N", "reason": "The selected virtual Ethernet service retains forwarding state, not a persistent final-peer authorization/continuity relationship. No higher-layer relationship protocol is selected.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-BL", "feature": "F05", "stack": "BL", "status": "N", "reason": "IPv6 forwarding and Babel routes supply no persistent final-peer authorization context; destination reachability is not a relationship.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-RI", "feature": "F05", "stack": "RI", "status": "Y", "reason": "The selected pairwise external-PSK DTLS profile can retain the native peer-admission policy already credited in F16-RI independently of its associations. Keep a record binding the opaque PSK identity to the intended peer/roles, secret, hash and an explicit allow/deny decision. RFC 8446 sections 4.2.11 and 6.2 distinguish binder verification from access control: even a valid PSK can be denied. Retain this record when discarding session traffic keys, then apply the same decision to a fresh handshake after reattachment through another authorized, reachable carrier. Admission is indexed by the provisioned peer context, not the old IP/port tuple. This is a documentary capability inference from native external-PSK and admission mechanisms, not from key stability alone.", "method": "Documentary native-policy composition; explicit retained authorization record and fresh-association boundary", "source_label": "TLS/DTLS external-PSK admission specifications and existing F16-RI policy witness", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-6.2", "https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.11", "https://www.rfc-editor.org/rfc/rfc8446.html#section-7", "https://www.rfc-editor.org/rfc/rfc9147.html#section-5.10", "https://www.rfc-editor.org/rfc/rfc9257.html#section-6.1" ], "editorial_references": [ "round288-sources.json", "round268.html" ], "qualification": "Configure retained local admission records and distinct high-entropy keys per client/server pair with fixed roles; do not delete that policy on association teardown. RFC 9257 explicitly covers DTLS 1.3 and describes pairwise provisioning and stack PSK-selection interfaces. No tickets, early data, certificate fallback or application-login protocol is added. The later session uses fresh traffic secrets. Link access, neighbor discovery and routing must separately restore reachability. This does not establish seamless handover, automatic peer discovery, crash persistence or an executed full RPL/DTLS stack. No new runtime test occurred. The policy-retention condition is explicit, as for F05-HIP; the existing criterion and selected composition are unchanged." }, { "id": "F05-HP", "feature": "F05", "stack": "HP", "status": "Y", "reason": "RFC 7401 section 7 defines responder ACLs selecting the Host Identities whose base exchanges are accepted, with policy parameters. Retaining this local admission policy across association teardown lets the same authorized peer establish a later association from another reachable locator.", "method": "Documentary native-policy composition; no cutover or isolation experiment", "source_label": "HIP policy and ESP teardown; DTLS/TLS external-PSK and closure specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-7" ], "editorial_references": [ "round268-sources.json" ], "qualification": "Credits retained HI-based admission policy, not merely a stable key or retained traffic secrets. Configure the selected pinned peers as accepted identities and retain that policy. No application roles, automatic trust recovery or crash-persistence test is inferred." }, { "id": "F05-CX", "feature": "F05", "stack": "CX", "status": "N", "reason": "CCNx core pending Interests, forwarding tables, caches and producer-key validation do not define a persistent authorization context between final peers across session termination and carrier changes. The selected CRC32C Interests do not authenticate consumers.", "method": "Documentary dependency and state inventory; no execution", "source_label": "Primary protocol specifications and selected local deployment/trust configuration", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-1.2" ], "editorial_references": [ "round264-sources.json" ], "qualification": "Persistent producer trust authenticates content origin; it is not retained authorization for a final requesting peer. No application relationship or authorization protocol is included." }, { "id": "F05-LI", "feature": "F05", "stack": "LI", "status": "N", "reason": "EID-to-RLOC mapping and authenticated Map-Register state concern routing and registration. They do not establish durable final-peer authorization across application sessions. The selected ordinary UDP endpoints add no such relationship mechanism.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-IL", "feature": "F05", "stack": "IL", "status": "N", "reason": "The ILCC and nonces preserve current communication state; stable NIDs and DNS records do not establish enduring final-peer authorization across terminated sessions. No additional authorization layer is selected.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F05-TS", "feature": "F05", "stack": "TS", "status": "Y", "reason": "Persistent tailnet policy binds permitted sources and destinations independently of individual WireGuard session keys and physical attachment. New sessions apply the retained authorization policy.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "Policy may expire or be revoked; this does not credit participant control of the hosted coordinator." }, { "id": "F05-RA", "feature": "F05", "stack": "RA", "status": "Y", "reason": "The selected enrollment mode retains local peer-name/public-key admission bindings independently of session state. Each new authentication context reloads the expected peer key by name; a missing or unreadable binding fails authentication. With the same authorized peer configuration retained across Ethernet/Wi-Fi carrier changes, the IPCP can establish a new session under the existing admission decision.", "method": "Pinned source inspection of selected admission and forwarding policies; no runtime/security test", "source_label": "IRATI peer-key admission and authenticated SDU forwarding", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/security-manager-ps.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md" ], "editorial_references": [ "round669.html" ], "qualification": "Scope is IPCP enrollment authority and peer continuity, not application roles or preservation of live transport state. This credits persistent configured admission bindings plus their mandatory verification, not merely possession of a stable key. The default authorization policy accepts successfully authenticated members; additional per-application restrictions are not inferred. Reusing the configuration does not establish revocation of already active sessions." }, { "id": "F06-PN", "feature": "F06", "stack": "PN", "status": "Y", "reason": "Selected E2E suite 0x0202 combines X25519 and ML-KEM-1024, derives directional keys bound to the signed HS2 transcript, and protects traffic with ChaCha20-Poly1305. NONE suites are not credited with encryption.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "round202.html" ], "qualification": "" }, { "id": "F06-PI", "feature": "F06", "stack": "PI", "status": "Y", "reason": "Selected E2E suite 0x0202 combines X25519 and ML-KEM-1024, derives directional keys bound to the signed HS2 transcript, and protects traffic with ChaCha20-Poly1305. NONE suites are not credited with encryption.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "round202.html" ], "qualification": "" }, { "id": "F06-IP", "feature": "F06", "stack": "IP", "status": "N", "reason": "The selected composition has no IPsec security association, encryption, padding or cover-traffic mechanism. Such protection requires an explicitly added security profile.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-BP", "feature": "F06", "stack": "BP", "status": "Y", "reason": "The retained capability requires BPSec payload confidentiality with the security source at the bundle source, the security acceptor at the final destination and decryption keys unavailable to intermediaries. RFC 9172 explicitly identifies this as end-to-end protection. TCPCL TLS alone is insufficient. This does not establish the mandatory admission/provenance gate still open in F16/F21.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9172.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-CG", "feature": "F06", "stack": "CG", "status": "Y", "reason": "Selected final-pair BCB-AES-GCM encrypts the payload; forwarding nodes are not given those keys. This is a configured end-to-end protection scope.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9173, BPSec default contexts", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "F06-LT", "feature": "F06", "stack": "LT", "status": "Y", "reason": "Final-pair BCB-AES-GCM provides payload confidentiality across forwarding nodes that lack the final keys. LTP itself is not credited with encryption.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "RFC 9173, BPSec default contexts", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F06-LP", "feature": "F06", "stack": "LP", "status": "Y", "reason": "The selected QUIC transport protects application traffic between the communicating libp2p peers using TLS-derived packet-protection keys. Protection terminates at those peers, not at intermediate IP routers. It does not cover storage or plaintext beyond the peer endpoint.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-TO", "feature": "F06", "stack": "TO", "status": "Y", "reason": "The onion-service rendezvous handshake establishes keys between the client and onion service, beyond the separate relay-link encryption. The rendezvous relay joins circuits without becoming the application plaintext endpoint. The boundary ends at the service's Tor endpoint; a separate backend connection is not automatically protected.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-I2", "feature": "F06", "stack": "I2", "status": "Y", "reason": "Garlic encryption protects destination messages beyond the layered tunnel protection, so outbound tunnel endpoints and inbound gateways are not the plaintext recipients. This credits destination-level delivery, not merely NTCP2 transport encryption, and does not add the unselected Streaming library.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.i2p.net/en/docs/overview/tech-intro/" ], "editorial_references": [], "qualification": "" }, { "id": "F06-YG", "feature": "F06", "stack": "YG", "status": "Y", "reason": "The selected native Yggdrasil endpoints exchange end-to-end encrypted traffic using their node keys. Intermediate Yggdrasil nodes do not terminate that protection. Credit does not extend to plaintext links behind a gateway serving non-Yggdrasil hosts.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://yggdrasil-network.github.io/implementation.html", "https://yggdrasil-network.github.io/faq.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-CJ", "feature": "F06", "stack": "CJ", "status": "Y", "reason": "The cjdns router's end-to-end CryptoAuth wrapping protects traffic between the selected native cjdns nodes, separately from outer neighbor-link protection. Routers forwarding that encrypted traffic are not the endpoint key holders. This is not encryption beyond a terminating gateway.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [], "qualification": "" }, { "id": "F06-MQ", "feature": "F06", "stack": "MQ", "status": "Y", "reason": "QUIC uses TLS-derived AEAD packet protection for application data between connection endpoints. The selected multipath extension changes path use, not encryption termination. Publicly derivable Initial protection is not the basis for this application-content positive.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-SC", "feature": "F06", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP composition has no endpoint content-encryption layer. Path and hop authentication protect forwarding information rather than application payload confidentiality. Adding TLS or an encrypted application protocol would change the selected stack.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-RT", "feature": "F06", "stack": "RT", "status": "Y", "reason": "Link establishes an encrypted channel between its endpoints.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-NS", "feature": "F06", "stack": "NS", "status": "N", "reason": "NIP-01 signs events but does not encrypt author-to-reader content; TLS terminates at the relay.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F06-MT", "feature": "F06", "stack": "MT", "status": "Y", "reason": "For selected direct messages, X25519-derived AES-CCM protects payloads between the two radio nodes. Relays do not terminate that encryption. The trusted serial client is inside the endpoint boundary; channel-key holders are not credited as private direct-message endpoints.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/CryptoEngine.cpp#L287" ], "editorial_references": [], "qualification": "Validate ciphertext-only transit and endpoint/client key custody on the pinned hardware build; no radio capture or firmware execution performed." }, { "id": "F06-GN", "feature": "F06", "stack": "GN", "status": "Y", "reason": "CADET encrypts between final peers; forwarding peers cannot decrypt the application payload.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Pin an executable release matching the documentary baseline and validate that only final CADET peers hold payload keys." }, { "id": "F06-ND", "feature": "F06", "stack": "ND", "status": "N", "reason": "The selected signed Data format protects provenance/integrity, not confidentiality; no content-encryption mechanism is selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NDN packet format v0.3 Data packet", "sources": [ "https://docs.named-data.net/NDN-packet-spec/0.3/data.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-AX", "feature": "F06", "stack": "AX", "status": "N", "reason": "The classic information-frame format supplies error/flow control, not endpoint encryption; no cryptographic wrapper is selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F06-BA", "feature": "F06", "stack": "BA", "status": "N", "reason": "The selected virtual Ethernet service supplies no end-to-end encryption layer.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-BL", "feature": "F06", "stack": "BL", "status": "N", "reason": "Base IPv6 plus Babel provides no end-to-end payload encryption; IPsec is not selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-RI", "feature": "F06", "stack": "RI", "status": "Y", "reason": "DTLS 1.3 protects application records between the final communicating endpoints using the selected AES-128-GCM traffic keys. The profile excludes a DTLS-terminating gateway.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "The PSK-only construction does not provide forward secrecy. This verdict does not cover RPL control messages or traffic metadata." }, { "id": "F06-HP", "feature": "F06", "stack": "HP", "status": "Y", "reason": "RFC 7402 specifies host-to-host ESP protection using HIP-derived keys. Selected transform 8 encrypts the payload with AES-128-CBC and authenticates it with HMAC-SHA-256.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Selected encryption, not ESP NULL or authentication-only operation. Intermediate routers do not terminate the final-host security association; no new executable test." }, { "id": "F06-CX", "feature": "F06", "stack": "CX", "status": "N", "reason": "CCNx defines validation but no encryption envelope. Neither the selected UDP binding nor content signatures encrypt the payload.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Encrypted-session extensions are not in this column. Integrity and signer authentication are separate from confidentiality." }, { "id": "F06-LI", "feature": "F06", "stack": "LI", "status": "N", "reason": "LISP encapsulation does not encrypt application content between end hosts. Neither endpoint TLS nor IPsec is selected; mapping-control authentication has a different scope.", "method": "Specification review", "source_label": "RFC 9300 (data plane) and RFC 9301 (control plane)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-IL", "feature": "F06", "stack": "IL", "status": "N", "reason": "The selected ILNPv6/TCP composition does not encrypt endpoint payloads. IPsec can supply protection but is not part of this profile (RFC 6740 section 7).", "method": "Specification review", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-7", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F06-TS", "feature": "F06", "stack": "TS", "status": "Y", "reason": "WireGuard encrypts between the two selected Tailscale nodes, including when DERP relays carry the encrypted packets. No exit-node plaintext segment is selected.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/tailscale-encryption" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F06-RA", "feature": "F06", "stack": "RA", "status": "Y", "reason": "The explicitly selected two-end-host upper DIF applies native SDU encryption between its only two member IPCPs. Lower routed DIFs carry the protected upper PDUs without holding the upper keys. Thus application payload is protected between the compared endpoint hosts, rather than merely on each transit adjacency.", "method": "Native architecture and pinned SDU/RMT source inspection; no runtime or attack experiment", "source_label": "RINA recursive protection placement and IRATI default SDU crypto policy", "sources": [ "https://www.etsi.org/deliver/etsi_gr/NGP/001_099/009/01.01.01_60/gr_ngp009v010101p.pdf", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup-crypto-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md" ], "editorial_references": [ "round666.html" ], "qualification": "Requires applications to use the protected upper DIF, with only the endpoint hosts admitted to it and correctly pinned peer keys. Encrypting a multi-member transit DIF alone would not establish this result: its RMT removes ingress protection before forwarding. The added composition uses native recursion, not application TLS. Source/architecture evidence only; no runtime or cryptographic audit." }, { "id": "F07-PN", "feature": "F07", "stack": "PN", "status": "Y", "reason": "Wire-v4 section 11.3 requires independent identity proofs in both HS2 flights. This supports cryptographic participant authentication without Application Agreement; application authorization is a separate property.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "F07-PI", "feature": "F07", "stack": "PI", "status": "Y", "reason": "Wire-v4 section 11.3 requires independent identity proofs in both HS2 flights. This supports cryptographic participant authentication without Application Agreement; application authorization is a separate property.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "F07-IP", "feature": "F07", "stack": "IP", "status": "N", "reason": "The selected datagram service supplies addresses, not cryptographic participant identity or a persistent authenticated relationship. No IPsec or upper-layer identity protocol is included.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-BP", "feature": "F07", "stack": "BP", "status": "Y", "reason": "The selected TCPCLv4 TLS profile verifies certificates with NODE-ID matching and local trust, authenticating the communicating remote BP node. This satisfies F07's remote-participant criterion; it does not establish that a forwarding neighbor is the original bundle author. BPSec security sources and the F21 final-source delivery gate remain distinct.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc9172.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-CG", "feature": "F07", "stack": "CG", "status": "Y", "reason": "BIB-HMAC-SHA2 verification with a locally bound pairwise key authenticates a configured remote security source. This does not yet qualify the final-source application API in F21.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9173, BPSec default contexts", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "F07-LT", "feature": "F07", "stack": "LT", "status": "Y", "reason": "Selected pairwise BIB-HMAC-SHA2 verification authenticates the configured remote security source; final application identity exposure remains separately unresolved.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "RFC 9173, BPSec default contexts", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F07-LP", "feature": "F07", "stack": "LP", "status": "Y", "reason": "The libp2p QUIC handshake uses the libp2p TLS identity binding to authenticate the remote Peer ID. Key-bound peer authentication is distinct from application permissions or civil identity; merely observing a claimed Peer ID is insufficient.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://libp2p.io/docs/tls/" ], "editorial_references": [], "qualification": "" }, { "id": "F07-TO", "feature": "F07", "stack": "TO", "status": "Y", "reason": "The rendezvous handshake proves the onion service identity to the client. F07 requires an authenticated remote participant, not mutual civil identity. The positive is not a claim that restricted descriptor access identifies every client or that every optional client-authentication extension is implemented.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-I2", "feature": "F07", "stack": "I2", "status": "Y", "reason": "A signed LeaseSet binds destination reachability information to the Destination signing key. F07 permits signed authorship and does not require current presence or mutual authentication. This positive does not authenticate every incoming application-message sender; the default destination/tunnel interface and added sender-aware protocols are separate.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.i2p.net/en/docs/specs/common-structures/" ], "editorial_references": [], "qualification": "" }, { "id": "F07-YG", "feature": "F07", "stack": "YG", "status": "Y", "reason": "Node public keys identify Yggdrasil participants and cryptographic signatures authenticate protocol messages. The selected direct-node profile therefore supplies a remote cryptographic participant, without civil identity or application authorization. An advertised subnet's arbitrary hosts are outside this credit.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://yggdrasil-network.github.io/implementation.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-CJ", "feature": "F07", "stack": "CJ", "status": "Y", "reason": "CryptoAuth establishes communication bound to the remote node key; the derived IPv6 node address supplies its key-based reference. This credits the selected native cjdns endpoint, not unauthenticated address text, civil identity or application privileges. No new replay or forward-secrecy guarantee is inferred.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [], "qualification": "" }, { "id": "F07-MQ", "feature": "F07", "stack": "MQ", "status": "Y", "reason": "The selected QUIC profile explicitly uses mutually authenticated TLS with locally trusted endpoint certificates. This authenticates the configured remote cryptographic identity. Ordinary server-only TLS is not silently treated as mutual authentication, and certificate trust remains a provisioning requirement.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-SC", "feature": "F07", "stack": "SC", "status": "N", "reason": "The selected application-UDP profile lacks an authenticated final application participant. Infrastructure certificates and hop-field authentication secure SCION roles and paths, not an application endpoint's identity. No endpoint TLS or application authentication layer is selected.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-RT", "feature": "F07", "stack": "RT", "status": "Y", "reason": "The initiator verifies the destination signature; initiator identification is optional, so mandatory mutual authentication is not claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-NS", "feature": "F07", "stack": "NS", "status": "Y", "reason": "An event signature proves authorship, not present liveness or the identity of its retransmitter.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F07-MT", "feature": "F07", "stack": "MT", "status": "Y", "reason": "The receiver verifies direct-message AEAD using the previously confirmed sender public key and its own private key. This proves the cryptographic sender under that key binding, not civil identity, freshness or universal trust in discovered NodeInfo.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp#L959" ], "editorial_references": [], "qualification": "Exercise confirmed-key, changed-key, forged-ciphertext and replay cases separately; this documentary decision does not establish freshness." }, { "id": "F07-GN", "feature": "F07", "stack": "GN", "status": "Y", "reason": "Signed ephemeral keys authenticate the final cryptographic peer under the selected known-key trust assumptions.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Test known-key mismatch, replay and channel authentication in the pinned executable; handbook evidence is not a runtime audit." }, { "id": "F07-ND", "feature": "F07", "stack": "ND", "status": "Y", "reason": "Consumer verification of ECDSA Data proves producer authorship under local trust; it does not prove current producer presence.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NDN packet format v0.3 signatures", "sources": [ "https://docs.named-data.net/NDN-packet-spec/0.3/signature.html" ], "editorial_references": [], "qualification": "Test consumer ECDSA validation against the local trust anchors; reject digest-only and untrusted-key content." }, { "id": "F07-AX", "feature": "F07", "stack": "AX", "status": "N", "reason": "Connection requests carry callsigns but no cryptographic participant proof in the selected classic protocol.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F07-BA", "feature": "F07", "stack": "BA", "status": "N", "reason": "Frame forwarding alone does not cryptographically authenticate the remote participant.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-BL", "feature": "F07", "stack": "BL", "status": "N", "reason": "No final-peer authentication layer is selected. Routing-neighbor protection, if added, would not authenticate final payload senders.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-RI", "feature": "F07", "stack": "RI", "status": "Y", "reason": "The PSK binder and Finished verification prove possession of the selected pairwise secret. Because each secret is held only by the two final peers, the receiver can authenticate its configured remote peer.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "A group-shared key would not identify one remote participant. Civil identity and public verifiability are not claimed." }, { "id": "F07-HP", "feature": "F07", "stack": "HP", "status": "Y", "reason": "The HIP base exchange authenticates the peers using their Host Identities and signatures. This profile pins peer keys rather than relying on opportunistic acceptance.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Cryptographic host identity, not civil identity, application permission or a newly tested application API." }, { "id": "F07-CX", "feature": "F07", "stack": "CX", "status": "Y", "reason": "The selected ECDSA-SHA256 Content Object signature can be verified against the producer key already trusted by the consumer.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Credit signed authorship under F07, not consumer authentication, current producer presence or authentication of the cache that serves the object." }, { "id": "F07-LI", "feature": "F07", "stack": "LI", "status": "N", "reason": "The selected stack does not cryptographically authenticate the remote application participant. The Map-Register authentication key protects registration at the Map-Server, not remote end-host identity.", "method": "Specification review", "source_label": "RFC 9300 (data plane) and RFC 9301 (control plane)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-IL", "feature": "F07", "stack": "IL", "status": "N", "reason": "The Nonce Destination Option protects established network sessions against off-path injection; it is not cryptographic proof of a remote participant identity. Stronger optional IPsec protection is not selected (RFC 6740 section 9.1).", "method": "Specification review", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-9.1", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F07-TS", "feature": "F07", "stack": "TS", "status": "Y", "reason": "WireGuard authenticates the peer node key; selected Tailnet Lock additionally requires node-key signatures from trusted signing nodes. This is node authentication, not proof of a civil identity.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/tailscale-identity" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F07-RA", "feature": "F07", "stack": "RA", "status": "Y", "reason": "The selected policy authenticates the remote enrolled IPCP through RSA-OAEP challenges and checked responses incorporating the DH shared secret. The code loads the expected peer key by peer name, validates replies and fails the exchange when the check fails.", "method": "Pinned documentation and authentication source inspection with explicit policy selection; no execution or audit", "source_label": "IRATI SSH2-inspired authentication policy", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/sm-auth-psoc/sm-auth-psoc-plugin.cc" ], "editorial_references": [ "round665.html" ], "qualification": "The authenticated participant is the IPCP in the enrollment exchange, not automatically the final application behind it. The implementation is SSH2-inspired, with custom key derivation and MD5-based internal challenge hashing; selecting SHA256 for SDU MACs does not remove those internal uses. Yes records the authentication mechanism, not a security audit, contemporary cryptographic recommendation or proof of absence of attacks." }, { "id": "F08-PN", "feature": "F08", "stack": "PN", "status": "Y", "reason": "Relationship Lifecycle section 7 requires connection aliases, service lanes, ordering, replay and item identities to remain unchanged during authenticated path replacement. Directional Carrier sections 7–8 share logical connection/session state across authorized paths. This is the same logical connection, not reconnection by stable identity. Failed continuity checks may terminate it; handover latency was not measured.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F08-PI", "feature": "F08", "stack": "PI", "status": "Y", "reason": "Relationship Lifecycle section 7 requires connection aliases, service lanes, ordering, replay and item identities to remain unchanged during authenticated path replacement. Directional Carrier sections 7–8 share logical connection/session state across authorized paths. This is the same logical connection, not reconnection by stable identity. Failed continuity checks may terminate it; handover latency was not measured.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F08-IP", "feature": "F08", "stack": "IP", "status": "N", "reason": "IP has no end-to-end transport connection to preserve. This No follows the connection-preservation wording; it is not a claim that IP cannot reroute packets.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-BP", "feature": "F08", "stack": "BP", "status": "N", "reason": "The selected TCPCLv4 session uses a TCP connection; reconnecting and resending retained bundles does not preserve that transport connection after its address pair changes. No connection-migration extension is selected.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.1" ], "editorial_references": [], "qualification": "" }, { "id": "F08-CG", "feature": "F08", "stack": "CG", "status": "N", "reason": "This profile carries bundles across adjacent TCPCL sessions. It does not provide a persistent final-to-final transport connection that migrates between paths.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9174, TCPCLv4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-LT", "feature": "F08", "stack": "LT", "status": "N", "reason": "Adjacent LTP block-transfer sessions do not supply a migrating final-to-final transport connection. Preserved bundles are not that connection.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "LTP specification, RFC 5326", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-LP", "feature": "F08", "stack": "LP", "status": "Y", "reason": "QUIC client-initiated migration is enabled in this composition. This is not arbitrary server mobility or a library test.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9" ], "editorial_references": [], "qualification": "" }, { "id": "F08-TO", "feature": "F08", "stack": "TO", "status": "Y", "reason": "Conflux section 2.7 specifies resumption with retained ordering state over replacement circuit legs. This preserves the logical stream, not its underlying TCP channel. Full loss recovery is design-level; C-Tor lacks full resumption.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://spec.torproject.org/proposals/329-traffic-splitting.html" ], "editorial_references": [], "qualification": "Bind the onion-service design to executable code; test loss, buffers and stream continuity. No execution or deployment claim." }, { "id": "F08-I2", "feature": "F08", "stack": "I2", "status": "N", "reason": "The selected I2P destination/tunnel layer does not include the end-to-end Streaming library. NTCP2 is a router-to-router TCP transport, not a migratable end-to-end application connection. Tunnel replacement and destination recovery therefore do not supply F08 in this composition. This negative must not be generalized to I2P applications using Streaming.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/api/streaming/" ], "editorial_references": [], "qualification": "" }, { "id": "F08-YG", "feature": "F08", "stack": "YG", "status": "N", "reason": "Application UDP has no connection to migrate. This does not deny address mobility or route recovery; TCP/QUIC would be another composition.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-CJ", "feature": "F08", "stack": "CJ", "status": "N", "reason": "Application UDP has no connection to migrate. This does not deny address mobility or route recovery; TCP/QUIC would be another composition.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-MQ", "feature": "F08", "stack": "MQ", "status": "Y", "reason": "QUIC can retain an established connection while changing network paths through its connection-ID and path-validation mechanisms. The selected migration-enabled multipath profile retains that capability. Credit assumes an available valid replacement path and suitable connection IDs; it does not promise lossless or instantaneous handover, server migration in every deployment, or measured mobility performance.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9" ], "editorial_references": [], "qualification": "" }, { "id": "F08-SC", "feature": "F08", "stack": "SC", "status": "N", "reason": "Application UDP has no connection to migrate. This does not deny address mobility or route recovery; TCP/QUIC would be another composition.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-RT", "feature": "F08", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link records an attached interface on establishment; its receive path rejects traffic from another interface. It supplies no endpoint-attachment migration operation for the same Link. Destination relocation followed by a new Link does not satisfy connection survival. This negative does not deny route changes that leave the existing attachment usable.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [], "qualification": "" }, { "id": "F08-NS", "feature": "F08", "stack": "NS", "status": "N", "reason": "TCP/WebSocket provides no connection migration to a new address pair. Route changes retaining addresses are a different case.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9293.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-MT", "feature": "F08", "stack": "MT", "status": "N", "reason": "The selected service transfers independently addressed messages with acknowledgment/retry state, rather than a negotiated end-to-end transport connection. Continuing to address the same node after movement therefore does not satisfy connection migration.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [], "qualification": "" }, { "id": "F08-GN", "feature": "F08", "stack": "GN", "status": "Y", "reason": "The documented CADET channel is independent of the underlying connections used by its destination tunnel. Replacing a failed intermediate path can retain the channel, provided endpoints and tunnel state survive. This is an architectural inference, not measured handover or unlimited outage tolerance.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Pin a runtime compatible with the v0.20.x documentary profile. Replace an intermediate connection while retaining the same channel handle and tunnel state; verify delivery, ordering and timeout behavior. The historical handbook is not an executable qualification." }, { "id": "F08-ND", "feature": "F08", "stack": "ND", "status": "N", "reason": "The selected Interest/Data service has no end-to-end transport connection to migrate. Adjacent face persistence is distinct.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 module and forwarding architecture", "sources": [ "https://docs.named-data.net/NFD/24.07/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-AX", "feature": "F08", "stack": "AX", "status": "Y", "reason": "Endpoint circuit identifiers do not encode intermediate routes. Switching an available next hop can preserve the same circuit before its timeout; endpoint relocation and arbitrary outages are not credited.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "Pin an implementation; establish a circuit with two known routes, fail one crosslink and confirm unchanged endpoint circuit identifiers and successful delivery before timeout. No execution performed." }, { "id": "F08-BA", "feature": "F08", "stack": "BA", "status": "N", "reason": "Native Ethernet frames have no end-to-end transport connection; higher-layer connection continuity is outside this profile.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-BL", "feature": "F08", "stack": "BL", "status": "N", "reason": "The selected IPv6 datagram service has no transport connection to preserve across path changes.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-RI", "feature": "F08", "stack": "RI", "status": "Y", "reason": "With nonempty DTLS Connection IDs negotiated in both directions, the existing protected association can accept a record arriving on a changed UDP path. The pinned implementation retains the WOLFSSL association and promotes a pending peer address only after record deprotection and a newest-record check; it does not need a new handshake for that transition.", "method": "Source/API provenance and bounded documentary witness; no execution", "source_label": "Pinned wolfSSL source and DTLS 1.3 specification", "sources": [ "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/internal.c", "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/wolfssl/ssl.h", "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/dtls13.c", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round271-sources.json" ], "qualification": "Explicit optional-CID witness: enable DTLS 1.3/CID, verify negotiation, keep the object, keys, replay/epoch state and timeout alive, and provide each candidate source address through the pending-peer receive path. Do not blindly call set_peer on an unauthenticated packet. Test wrong CID, invalid authentication, replay and stale records; no execution occurred. This is DTLS association continuity, not a reliability/ordering guarantee for application datagrams or proof of complete radio/RPL mobility." }, { "id": "F08-HP", "feature": "F08", "stack": "HP", "status": "N", "reason": "The selected HIP/ESP profile carries application UDP, which has no end-to-end transport connection. RFC 8046 preserves host-identity bindings and permits locator changes without replacing the HIP/ESP context, but that network-level continuity does not create a transport connection. This applies the same connection-specific boundary used for the selected IP, Yggdrasil and cjdns UDP compositions.", "method": "Documentary profile-boundary and source-path analysis; no execution", "source_label": "Primary RFCs and pinned PARC upstream source", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-1", "https://www.rfc-editor.org/rfc/rfc768.html", "https://www.rfc-editor.org/rfc/rfc7402.html" ], "editorial_references": [ "round274-sources.json" ], "qualification": "This is not a denial of HIP mobility: F23-HP remains Yes. A connected UDP socket is a local API association, not an additional wire-level connection. ESP SAs and HIP associations are below the selected application transport; DTLS in RI supplies a protected transport association and is a different composition. Adding TCP or broadening F08 to communication-context continuity would require a separate profile or criterion change. No runtime failure is alleged." }, { "id": "F08-CX", "feature": "F08", "stack": "CX", "status": "N", "reason": "The selected UDP/CCNx composition has no persistent transport connection to migrate. Pending Interests and renewed requests do not preserve the same transport connection across a path change.", "method": "Selected-profile documentary review; no runtime test", "source_label": "CCNx 1.0 semantics and selected UDP/CRC32C Interest profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-1.3", "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round258-sources.json" ], "qualification": "This verdict concerns F08 transport continuity, not whether content can be fetched through a different route." }, { "id": "F08-LI", "feature": "F08", "stack": "LI", "status": "N", "reason": "The selected endpoint transport is UDP. Updating the route to a stable EID can preserve reachability, but there is no transport connection in this composition to preserve. This is not a negative claim about LISP carrying TCP in another profile.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html#section-4.2; rfc768.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-4.2", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F08-IL", "feature": "F08", "stack": "IL", "status": "Y", "reason": "ILNP binds TCP connection state and transport checksums to stable Node Identifiers rather than Locators. Locator Updates allow the same connection to continue while attachment changes in the selected overlapping-coverage host-mobility case (RFC 6740 sections 3.1.1, 3.5 and 6.2).", "method": "Specification review", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-6.2", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "Documented architectural capability only. Pin and execute an ILNPv6/TCP implementation across two authorized attachments with overlapping connectivity; verify Locator Updates and retention of the same TCP connection. No measured lossless handover, simultaneous endpoint movement or deployment certification is claimed." }, { "id": "F08-TS", "feature": "F08", "stack": "TS", "status": "Y", "reason": "Path selection beneath the stable Tailscale interface can change between direct UDP and DERP without changing the inner TCP endpoint addresses or resetting the host TCP connection. The same host connection can therefore continue across a supported path change.", "method": "Primary documentation and pinned source; explicit architectural inference", "source_label": "Tailscale addressing, control plane, magicsock and tailcfg", "sources": [ "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/tailcfg/tailcfg.go", "https://tailscale.com/blog/sqlite-wal-reset-bug" ], "editorial_references": [ "round591.html", "round591-sources.json" ], "qualification": "Architectural inference supported by stable overlay addressing, documented connection migration and magicsock data-path switching. Credits a host TCP connection carried by the selected TUN service, not UDP as a connection. Both endpoints retain state; excessive interruption, key revocation or application timeouts can still terminate it. No lossless-handover test performed." }, { "id": "F08-RA", "feature": "F08", "stack": "RA", "status": "Y", "reason": "The selected mobility mode preserves the upper application transport flows while replacing lower attachments. Tutorial 10 retains both upper flow port identifiers across provider handover; the mobman procedure enrolls the new lower path and disconnects the old neighbor without recreating the application flows.", "method": "Primary tutorial, configuration and implementation-source assessment; no execution", "source_label": "IRATI native bootstrap and two-provider mobility documentation", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Tutorial-10%3A-DMM-two-providers-ARCFIRE-2018.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/ipcm.conf", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/internet.dif", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcm/addons/mobility-manager.cc" ], "editorial_references": [ "round658.html" ], "qualification": "Documentary and source-level evidence, not a local rerun. The witness uses a configured two-interface make-before-break handover. Abrupt outage recovery, lossless operation, simultaneous movement of both peers and arbitrary provider admission are not established. Local privileged setup is disclosed; it is not infrastructure route-administration authority." }, { "id": "F09-PN", "feature": "F09", "stack": "PN", "status": "Y", "reason": "The project comparative whitepaper explicitly describes balancing over multiple admitted trajectories while preserving one item sequence and context (extension T and capability table). Lifecycle 3.4 permits concurrent eligible paths. This is architectural capability evidence; a concrete wire-v4 scheduler and concurrent payload test remain implementation qualifications.", "method": "Architectural documentary analysis", "source_label": "Project architecture whitepaper and specification; not runtime qualification", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Bind concurrent payload scheduling to wire-v4 and validate multiple useful paths; simultaneous eligibility alone is insufficient implementation evidence." }, { "id": "F09-PI", "feature": "F09", "stack": "PI", "status": "Y", "reason": "The project comparative whitepaper explicitly describes balancing over multiple admitted trajectories while preserving one item sequence and context (extension T and capability table). Lifecycle 3.4 permits concurrent eligible paths. This is architectural capability evidence; a concrete wire-v4 scheduler and concurrent payload test remain implementation qualifications.", "method": "Architectural documentary analysis", "source_label": "Project architecture whitepaper and specification; not runtime qualification", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Bind concurrent payload scheduling to wire-v4 and validate multiple useful paths; simultaneous eligibility alone is insufficient implementation evidence." }, { "id": "F09-IP", "feature": "F09", "stack": "IP", "status": "Y", "reason": "The column now explicitly selects optional per-packet unicast next-hop rotation over multiple provisioned routes, as documented in RFC 2991 section 2. Packets of the same communication can use concurrent paths. Flow-hashed ECMP alone would not establish this result. Reordering and unequal path MTUs are limitations; no endpoint path control or performance gain is claimed.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://www.rfc-editor.org/rfc/rfc2991.html#section-2" ], "editorial_references": [], "qualification": "Bind a router implementation with per-packet scheduling and verify packets of one communication traverse both paths. Measure reordering/MTU consequences; do not substitute flow-hashed ECMP." }, { "id": "F09-BP", "feature": "F09", "stack": "BP", "status": "Y", "reason": "RFC 9171 sections 3.2 and 5.4 permit concurrent bundle transmissions to selected next hops. The profile selects concurrent forwarding for one bundle; this is architectural capability, not a tested scheduler.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [], "qualification": "Pin an implementation and forwarding configuration; test concurrency, route diversity, duplicate handling and group delivery. No execution performed." }, { "id": "F09-CG", "feature": "F09", "stack": "CG", "status": "Y", "reason": "Architectural composition witness: send copies of one critical bundle over two CGR routes with different next hops and overlapping feasible contacts, using distinct TCPCLv4/TLS sessions on independently usable IP paths. The pinned ION BP forwarding path clones and enqueues the same bundle for eligible next hops; RFC 9174 section 5.2.2 explicitly permits simultaneous transfers through multiple TCPCL sessions. The one-session non-interleaving rule is not a cross-session serialization requirement. This establishes supported composition at specification level, not measured concurrent delivery by an integrated pinned implementation.", "method": "Explicit specification-level composition; integration unqualified", "source_label": "RFC 9174 section 5.2.2 plus pinned ION critical-bundle routing", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-5.2.2", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/ipn/ipnfw.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/bprc.pod", "https://ccsds.org/Pubs/734x3b1.pdf", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/tcp/tcpcli.c" ], "editorial_references": [ "round193-sources.json", "round196-sources.json", "round199-sources.json" ], "qualification": "Configure two independently usable IP paths, overlapping contacts and separate authenticated TCPCLv4/TLS sessions. Correlate the same original bundle identity on both payload-bearing transfers and demonstrate temporal overlap. Do not substitute queue overlap, probes, different bundles or sequential failover. Verify the exact TCPCLv4 integration independently of the pinned BP-layer source. No bandwidth gain or delivery guarantee is inferred. Inspection of the pinned bpv7/tcp/tcpcli.c finds an emitted TCPCL version 0x03 header. That adapter is not an executable TCPCLv4/TLS witness; the Yes remains a specification-level composition, not certification of this ION adapter." }, { "id": "F09-LT", "feature": "F09", "stack": "LT", "status": "Y", "reason": "Documentary plausibility: ION critical-bundle forwarding clones the same originating bundle toward distinct eligible route-entry neighbours before loss, and ltpclo services each configured outduct through ltp_send to its destination engine. Non-best-effort output uses LTP_ALL_RED. With overlapping contacts and independently serviceable LTP/Encapsulation/AOS links, these mechanisms plausibly allow useful copies of one communication to progress on concurrent paths; no stop-and-wait requirement between the separate outducts has been identified. Requiring a complete physical-link capture exceeded the requested capability-level evidence standard.", "method": "Documentary plausibility; explicit configuration-dependent architectural inference", "source_label": "Pinned ION critical-bundle forwarding and per-outduct LTP task", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/ltp/ltpclo.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/ipn/ipnfw.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/bprc.pod" ], "editorial_references": [ "round193-sources.json", "round198-sources.json", "round302-sources.json" ], "qualification": "Conditional architectural inference, not an observed simultaneous transmission. Requires independently serviceable physical links, overlapping contacts and report-return opportunities for all-red LTP. A shared single serializer/radio can remove concurrency and is not the qualifying configuration. Existing sources demonstrate cloning and separate submission; the complete Encapsulation/AOS integration and on-wire timing have not been tested. No throughput gain, physical path disjointness, deployment readiness or performance guarantee is claimed." }, { "id": "F09-LP", "feature": "F09", "stack": "LP", "status": "N", "reason": "QUIC v1 sends non-probing traffic on one path at a time. This column includes no multipath extension.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-21.1.3" ], "editorial_references": [], "qualification": "" }, { "id": "F09-TO", "feature": "F09", "stack": "TO", "status": "Y", "reason": "Conflux explicitly links onion-service rendezvous circuits and schedules useful traffic across them. The selected optional proposal-329 composition receives architectural credit.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://spec.torproject.org/proposals/329-traffic-splitting.html" ], "editorial_references": [], "qualification": "Implement and exercise onion-service linking, concurrent payload and ordering. Public availability is not established." }, { "id": "F09-I2", "feature": "F09", "stack": "I2", "status": "Y", "reason": "I2P distributes messages through active tunnel pools. Select multiple active outbound tunnels for one destination, carrying different useful messages concurrently. This supports parallel paths for one communication without adding Streaming; it does not establish proactive duplication of each message (F10).", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://i2p.net/en/docs/specs/tunnel-implementation/" ], "editorial_references": [], "qualification": "Pin the implementation and configure at least two active, rather than backup-only, tunnels. Capture useful traffic for one destination on both concurrently and measure route overlap, reordering and load distribution. No execution performed. Round 0.38: the ordinary Java client pipeline at 37039e6594f1372368f0c1cf8258cdaf805a7fb4 caches a tunnel per destination pair. Architectural concurrency requires an explicit scheduler binding; it is not demonstrated by that default pipeline." }, { "id": "F09-YG", "feature": "F09", "stack": "YG", "status": "N", "reason": "The pinned pathfinder selects one current path per destination and router.handleTraffic selects one next peer. Alternate topology and concurrent traffic to different destinations do not establish concurrent paths for the same delivery. The selected ordinary TCP underlay excludes MPTCP and custom scheduling.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go#L194" ], "editorial_references": [], "qualification": "" }, { "id": "F09-CJ", "feature": "F09", "stack": "CJ", "status": "N", "reason": "For ordinary IPv6 application traffic without an explicit route-label override, SessionManager selects paths[0] after metric ranking. Other stored paths and later reranking support alternate-route selection, not a scheduler distributing concurrent useful traffic across multiple paths. This is a bounded code-path conclusion, not a claim about custom raw routing handlers.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c#L804" ], "editorial_references": [], "qualification": "" }, { "id": "F09-MQ", "feature": "F09", "stack": "MQ", "status": "Y", "reason": "The existing architectural Yes now has a bounded executable witness: the pinned picoquic combined mutual-authentication test negotiated multipath, validated two paths and completed a content-checked transfer. The final server qlog recorded 835 sent STREAM frames on path 0 and 757 on path 1 in the same connection, with both paths used during the transfer.", "method": "Documentary capability supplemented by bounded executed evidence", "source_label": "Multipath-21 and executed pinned picoquic simulated-network witness", "sources": [ "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-5.5", "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquictest/multipath_test.c" ], "editorial_references": [ "round295-runtime.json", "round295-sources.json", "round295_quic.c" ], "qualification": "Retained evidence is from upstream simulated links, not physical independent carriers. No throughput, scheduler optimality, global scale, shared-bottleneck fairness or external interoperability claim. The 41 cross-path repeated ranges also show duplication during this execution, without proving every duplicate was proactive or every payload was duplicated. General capability remains defined by multipath-21; the known positive-limit configuration qualification is retained." }, { "id": "F09-SC", "feature": "F09", "stack": "SC", "status": "Y", "reason": "Packet-carried forwarding state supports multipath between endpoints; no scheduler performance is certified.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/overview.html#routing" ], "editorial_references": [], "qualification": "" }, { "id": "F09-RT", "feature": "F09", "stack": "RT", "status": "N", "reason": "For the selected established Link, Transport outbound processing restricts transmission to its attached interface and forwarding uses link/path state rather than a concurrent payload scheduler or proactive diverse-path replication. Broadcast of announcements or other non-Link packets does not supply these capabilities to the selected Link.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [], "qualification": "" }, { "id": "F09-NS", "feature": "F09", "stack": "NS", "status": "Y", "reason": "Select concurrent publication of one signed event to two independently reachable relays. Both paths carry useful copies of the same communication, not unrelated sessions. This is event-level parallelism, not multipath inside one WebSocket.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nostr/master/README.md" ], "editorial_references": [], "qualification": "Shared F09/F10: pin a client that publishes concurrently before any failure; verify identical event IDs, independent routes, duplicate handling and costs. Multiple relay URLs alone do not prove path diversity. No execution performed." }, { "id": "F09-MT", "feature": "F09", "stack": "MT", "status": "Y", "reason": "The no-next-hop forwarding branch can maintain two live forwarding branches for the same communication. Witness: A reaches CLIENT relays B and C; B and C cannot hear each other, and each reaches D. Both copy the initial packet for forwarding before either hears a duplicate; D can receive through either branch. This is concurrent logical path use over a shared radio medium, not simultaneous physical transmissions, bandwidth aggregation or a source-selected multipath scheduler. Known-next-hop traffic may use only one branch. Architectural inference from forwarding and duplicate-cancellation code.", "method": "Read-only code analysis and explicit topology inference", "source_label": "Pinned Meshtastic firmware: forwarding, authenticated receive and client serialization", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp#L243" ], "editorial_references": [], "qualification": "Run the hidden-relay diamond with no next-hop hint and adequate hop budget. Capture both forwarders and D; distinguish overlapping logical paths from collision or source retry. Then establish a next-hop hint and compare. No execution yet." }, { "id": "F09-GN", "feature": "F09", "stack": "GN", "status": "Y", "reason": "A destination tunnel maintains several connections. get_ready_connection selects ready connections round-robin; try_send_normal_payload sends queued messages through a ready connection and removes it from the ready list until it can transmit again. With distinct live paths and queued messages from one channel, useful payload can use multiple paths concurrently. This is not merely a list of standby routes; disjointness and throughput are not guaranteed.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "src/cadet/gnunet-service-cadet_tunnels.c: get_ready_connection, connection_ready_cb, try_send_normal_payload, GCT_send", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Pin a normal GNUnet 0.20.0 build, establish two distinct paths for one channel, pipeline payload and capture overlapping useful transmissions. Check window/backpressure and shared bottlenecks; no throughput measurement was performed." }, { "id": "F09-ND", "feature": "F09", "stack": "ND", "status": "Y", "reason": "A bounded witness uses one segmented content retrieval with two known segment-name prefixes mapped to distinct Ethernet next hops. The consumer pipelines Interests for the different segments; BestRoute selects the lowest-cost eligible next hop separately for each PIT entry, so distinct useful Data can return concurrently over the two branches. This uses existing static prefix routes, not an added multipath strategy or multiple transport sessions. It requires provisioned routes and concurrent requests: a single prefix with one preferred route does not automatically stripe traffic, and a single Interest is not proactively duplicated. F10 remains No for stock BestRoute.", "method": "Constructive static-route and pinned strategy analysis; no runtime execution", "source_label": "NFD 24.07 BestRoute and prefix route management", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/best-route-strategy.cpp", "https://docs.named-data.net/NFD/24.07/manpages/nfdc-route.html", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/table/pit.cpp", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [], "qualification": "Serve two segments of one named object over disjoint Ethernet branches. Install more-specific segment routes and pipeline both Interests before either response. Capture overlapping useful Data, verify signatures and repeat with a single-prefix control. No throughput or scheduler benchmark performed." }, { "id": "F09-AX", "feature": "F09", "stack": "AX", "status": "N", "reason": "Classic NET/ROM retains up to three candidate routes but selects one active route per destination. Alternatives are failover candidates, not concurrent useful data paths.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F09-BA", "feature": "F09", "stack": "BA", "status": "Y", "reason": "With native bonding enabled, batadv_find_router rotates eligible first-hop candidates across outgoing interfaces, retaining the last candidate rather than hashing an application flow to one route. A stream of frames to one destination can therefore use A-B-D and A-C-D concurrently. Select BATMAN_IV, two comparable eligible routes and active interfaces. The common scheduler also has comparator support in BATMAN_V, but the executable witness is fixed to IV. This is optional first-hop packet distribution, not loss-triggered failover, duplication, guaranteed disjointness or a throughput claim. No new transport layer is added.", "method": "Pinned primary-source inspection and bounded configuration/topology inference; no execution", "source_label": "Linux v6.12 source; NET/ROM 1.3 manual where indicated", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_iv_ogm.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_v.c" ], "editorial_references": [], "qualification": "Set BATMAN_IV and bonding=1 on a two-interface source. Establish comparable routes to one destination via B and C. Capture consecutive frames from one communication on both initial branches; verify useful delivery and record reordering. Default bonding=0 is not the credited configuration." }, { "id": "F09-BL", "feature": "F09", "stack": "BL", "status": "N", "reason": "RFC 8966 section 3.6 defines selection of one route per prefix for forwarding and advertisement. Alternate candidates support repair, not concurrent useful paths for one communication. The declared IPv6/UDP/Babel composition selects no additional multipath data-plane policy or transport. It therefore does not meet F09. This is not a prohibition on multipath extensions or independently configured IPv6 forwarding. The IP column explicitly includes per-packet next-hop rotation; that policy is not inherited merely because Babel also runs over IP. Different destinations using different routes do not establish this criterion.", "method": "Primary specification analysis of the declared composition; no runtime test", "source_label": "RFC 8966 sections 2.2 and 3.6, Appendix A.3", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.6" ], "editorial_references": [], "qualification": "" }, { "id": "F09-RI", "feature": "F09", "stack": "RI", "status": "N", "reason": "The selected OF0 sends upward traffic through one preferred parent, explicitly without load balancing, and uses a backup when that path fails. The selected pairwise DTLS stack adds no concurrent-path scheduler for one communication.", "method": "Documentary bounded-witness and state inventory; no runtime execution", "source_label": "Primary forwarding, mobility and state specifications; selected-profile witnesses", "sources": [ "https://www.rfc-editor.org/rfc/rfc6552.html#section-4" ], "editorial_references": [ "round265-sources.json" ], "qualification": "Multiple candidate parents and route diversity are not simultaneous useful-data paths. This verdict does not extend to every RPL objective function or an unselected multipath extension." }, { "id": "F09-HP", "feature": "F09", "stack": "HP", "status": "N", "reason": "The selected RFC 8046 mobility procedure changes the locator used by the existing host communication. It does not supply concurrent useful-data scheduling over multiple paths; host multihoming procedures are assigned to RFC 8047, which is not selected.", "method": "Selected-profile documentary review; no mobility experiment", "source_label": "HIP host mobility and DTLS 1.3 primary specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-1" ], "editorial_references": [ "round261-sources.json" ], "qualification": "A LOCATOR_SET can list addresses without providing a selected multipath data scheduler. Address verification traffic and make-before-break overlap do not establish concurrent payload paths." }, { "id": "F09-CX", "feature": "F09", "stack": "CX", "status": "Y", "reason": "Apply the same useful-copy interpretation already used for BP, CGR and Nostr: two proactive copies of one requested object can carry useful redundant data concurrently. Athena sends an Interest to every configured send-ready next hop; two independent UDP replica branches can return the same immutable signed object with overlapping transmissions before the first return consumes the converging PIT entry. Distinct segments or aggregate throughput gains are not required by the existing criterion.", "method": "Documentary composition and source inspection; no runtime execution", "source_label": "Pinned PARC consumer/forwarder sources and cross-column criterion consistency", "sources": [ "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_TransportLinkAdapter.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_PIT.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_FIB.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_TransportLinkModuleUDP.c" ], "editorial_references": [ "round276-sources.json" ], "qualification": "This corrects the extra distinct-portions requirement introduced in revision 2.75; it does not change F09. Use two independently serviceable branches, identical object bytes/hash and a local cache miss, with no shared serialization bottleneck forcing non-overlap. Verify actual payload overlap and first-response suppression before runtime qualification. Multiple sockets or queued requests alone do not suffice. The verdict is a supported documentary composition, like F09-CG, not a measured scheduler, physical-diversity result or complete ECDSA implementation. F10 remains the separate proactive-duplication property." }, { "id": "F09-LI", "feature": "F09", "stack": "LI", "status": "Y", "reason": "Architectural Yes with an explicit optional packet scheduler. RFC 9300 section 9 gives the client-side ITR distribution choice when the eligible best-priority RLOCs have zero weights. Section 12 makes its flow-hash selection algorithm optional. Select two reachable locators for the same destination EID and alternate successive useful UDP packets between them over distinct provisioned paths. Both paths carry the same communication while it is active. Keeping the outer UDP source port constant preserves the separate per-flow source-port recommendation. This supplies the previously missing scheduler policy at the architectural capability level, using the same optional-policy standard already applied to IP F09.", "method": "Normative policy analysis and explicit architectural witness; no execution", "source_label": "RFC 9300 sections 9 and 12; optional-policy parity with F09-IP", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-9", "https://www.rfc-editor.org/rfc/rfc9300.html#section-12" ], "editorial_references": [ "round412.html", "round412-evidence.json" ], "qualification": "This optional deployment policy is now explicit in the LI profile; it is not the flow-hashed behavior observed in lispers.net a61c30b. No existing implementation is asserted to expose this policy, and no traffic test, performance gain or independent interoperability result was produced. Two RLOCs alone do not prove distinct physical routes. Reordering and path MTU differences remain deployment concerns. Selection is at the ITR, not autonomous endpoint control; F20/F23 and all other verdicts are unchanged." }, { "id": "F09-IL", "feature": "F09", "stack": "IL", "status": "Y", "reason": "The IETF126/Vienna report documents one regular TCP CUBIC flow using several concurrent NID-to-L64 bindings. The network layer supplies multipath operation without MPTCP or a modified application. Figure 4 identifies four Locator paths and the report explains activation of additional interfaces during the same flow.", "method": "Primary experiment/release documentation review", "source_label": "ILNP project experiment and release records", "sources": [ "https://ilnp.cs.st-andrews.ac.uk/freebsd/20260718-ietf126_hackathon/", "https://doi.org/10.17630/6a8f5c05-4d52-49a7-a4c1-75e1a38d4158" ], "editorial_references": [], "qualification": "Project-attributed FreeBSD 14.3 ILNP v1.2.0 witness, not an independent rerun. The demo also contains newer draft refinements; credit only the ordinary-TCP multiple-Locator mechanism, not wholesale equivalence with every 2012 wire detail. The 4 Mbit/s demonstration and similar paths do not establish performance, physical path disjointness or multipath-aware congestion control." }, { "id": "F09-TS", "feature": "F09", "stack": "TS", "status": "Y", "reason": "When a known UDP path has outlived its trust interval, addrForSendLocked can return both that path and DERP. The data send method then sends the same packet buffers on both paths, not merely discovery probes.", "method": "Pinned source inspection and official purpose statement; no runtime experiment", "source_label": "Tailscale magicsock and packet filter, official privacy statement", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/filter/filter.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/magicsock.go", "https://tailscale.com/blog/tailscale-privacy-anonymity", "https://tailscale.com/security" ], "editorial_references": [ "round589.html", "round589-sources.json" ], "qualification": "Transient overlap during path revalidation qualifies under concurrent useful data paths. No continuous bandwidth aggregation, physically disjoint links or user-selectable multipath service is claimed." }, { "id": "F09-RA", "feature": "F09", "stack": "RA", "status": "Y", "reason": "The newly explicit redundant-path mode carries the same communication concurrently through distinct next hops. Each branch transports a useful copy toward the same receiving IPCP, unlike sequential mobility failover or per-flow ECMP. The earlier No assessed the default single-path mode and is superseded by this declared composition change.", "method": "Pinned source call-chain inspection with explicit native policy selection; no execution", "source_label": "IRATI static routing, forwarding-table generator, default PFF and RMT", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/static-routing-ps.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/resource-allocator-ps.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/pff-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/dtp.c" ], "editorial_references": [ "round664.html" ], "qualification": "This credits simultaneous redundant transport, not throughput aggregation or striping. Distinct next hops alone do not guarantee disjoint failure domains; provision the downstream paths accordingly. DTCP-enabled DTP rejects sequence numbers at or below its receive-window edge, but complete duplicate/reordering behavior, startup races and failure recovery have not been exercised here." }, { "id": "F10-PN", "feature": "F10", "stack": "PN", "status": "Y", "reason": "The project comparative whitepaper extension T explicitly includes redundant transmission over independently admitted trajectories while preserving item sequence and context. Retention section 5 separately specifies stable item identity, path-appropriate reprotection and duplicate-delivery prevention, but its activation gate remains open. The redundancy positive is architectural, not proof that a complete wire-v4 duplication policy is implemented or that the retention gate is closed.", "method": "Architectural documentary analysis", "source_label": "Project architecture whitepaper and specification; not runtime qualification", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Bind proactive replication and same-item deduplication across independent paths; demonstrate safe nonce/replay handling. Architectural redundancy is not a tested scheduler." }, { "id": "F10-PI", "feature": "F10", "stack": "PI", "status": "Y", "reason": "The project comparative whitepaper extension T explicitly includes redundant transmission over independently admitted trajectories while preserving item sequence and context. Retention section 5 separately specifies stable item identity, path-appropriate reprotection and duplicate-delivery prevention, but its activation gate remains open. The redundancy positive is architectural, not proof that a complete wire-v4 duplication policy is implemented or that the retention gate is closed.", "method": "Architectural documentary analysis", "source_label": "Project architecture whitepaper and specification; not runtime qualification", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Bind proactive replication and same-item deduplication across independent paths; demonstrate safe nonce/replay handling. Architectural redundancy is not a tested scheduler." }, { "id": "F10-IP", "feature": "F10", "stack": "IP", "status": "N", "reason": "The selected datagram service defines neither proactive multipath copies nor retained delivery across disconnection/non-overlapping contacts.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html" ], "editorial_references": [], "qualification": "" }, { "id": "F10-BP", "feature": "F10", "stack": "BP", "status": "Y", "reason": "Section 5.4 sends the same bundle to each selected next hop without requiring prior loss. The profile selects proactively duplicated forwarding over distinct routes. Route diversity is an explicit deployment condition.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [], "qualification": "Pin an implementation and forwarding configuration; test concurrency, route diversity, duplicate handling and group delivery. No execution performed." }, { "id": "F10-CG", "feature": "F10", "stack": "CG", "status": "Y", "reason": "Pinned ION BPv7 maps the client critical option to BP_MINIMUM_LATENCY and stores it in the originating bundle. CGR selects a best eligible route per proximate node; sendCriticalBundle clones and enqueues copies for distinct route-entry neighbors before any loss. This is an origin-side proactive-replication witness with two provisioned distinct routes, not a claim that critical metadata survives every subsequent hop or that neighbors imply physically disjoint paths. The same source explicitly bypasses ordinary reforwarding for critical bundles, because they were already queued on eligible routes. Proactive duplication is therefore not an unconditional delivery guarantee.", "method": "Source audit of an explicit BP-layer witness; no execution", "source_label": "Pinned ION BPv7 client, CGR selector and IPN forwarder", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/ipn/ipnfw.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/cgr/libcgr.c" ], "editorial_references": [ "round193-sources.json", "round195-sources.json" ], "qualification": "Integrate the selected convergence layers; send one marked bundle over two independent routes and capture both copies before any loss. Check next-neighbor suppression, forwarding duplicate guard, final delivery duplication, resource cost and metadata at subsequent hops. No physical diversity, performance or end-to-end deduplication result is claimed." }, { "id": "F10-LT", "feature": "F10", "stack": "LT", "status": "Y", "reason": "Pinned ION BPv7 maps the client critical option to BP_MINIMUM_LATENCY and stores it in the originating bundle. CGR selects a best eligible route per proximate node; sendCriticalBundle clones and enqueues copies for distinct route-entry neighbors before any loss. This is an origin-side proactive-replication witness with two provisioned distinct routes, not a claim that critical metadata survives every subsequent hop or that neighbors imply physically disjoint paths. The same source explicitly bypasses ordinary reforwarding for critical bundles, because they were already queued on eligible routes. Proactive duplication is therefore not an unconditional delivery guarantee.", "method": "Source audit of an explicit BP-layer witness; no execution", "source_label": "Pinned ION BPv7 client, CGR selector and IPN forwarder", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/ipn/ipnfw.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/cgr/libcgr.c" ], "editorial_references": [ "round193-sources.json", "round195-sources.json" ], "qualification": "Integrate the selected convergence layers; send one marked bundle over two independent routes and capture both copies before any loss. Check next-neighbor suppression, forwarding duplicate guard, final delivery duplication, resource cost and metadata at subsequent hops. No physical diversity, performance or end-to-end deduplication result is claimed." }, { "id": "F10-LP", "feature": "F10", "stack": "LP", "status": "N", "reason": "QUIC v1 sends non-probing traffic on one path at a time. This column includes no multipath extension.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-21.1.3" ], "editorial_references": [], "qualification": "" }, { "id": "F10-TO", "feature": "F10", "stack": "TO", "status": "N", "reason": "The selected Conflux scheduler splits cells between legs; it does not proactively replicate each payload. Resending missing cells during recovery is reactive.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://spec.torproject.org/proposals/329-traffic-splitting.html" ], "editorial_references": [], "qualification": "" }, { "id": "F10-I2", "feature": "F10", "stack": "I2", "status": "N", "reason": "The pinned ordinary client-message pipeline dispatches a message through one selected outbound tunnel and one destination lease. It supplies no proactive duplicate fanout. Multiple active tunnels and retransmission by an extra Streaming layer are different mechanisms.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/message/OutboundClientMessageOneShotJob.java" ], "editorial_references": [], "qualification": "" }, { "id": "F10-YG", "feature": "F10", "stack": "YG", "status": "N", "reason": "pathfinder caches a traffic copy for broken-path recovery but sends once through router.handleTraffic. The local cache is not a proactive second transmission over a distinct path.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go#L194" ], "editorial_references": [], "qualification": "" }, { "id": "F10-CJ", "feature": "F10", "stack": "CJ", "status": "N", "reason": "The ordinary application send path selects one route label and passes one message to readyToSend and its encryption interface. It does not clone a payload onto multiple routes before loss. Search messages, path validation and later route changes are separate from proactive application-data redundancy.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c#L722" ], "editorial_references": [], "qualification": "" }, { "id": "F10-MQ", "feature": "F10", "stack": "MQ", "status": "Y", "reason": "Architectural composition inference: explicitly select a local proactive STREAM-copy policy on two validated paths. Draft-21 section 5.5 leaves path scheduling local; RFC 9000 section 2.2 permits repeated identical bytes at the same stream offset. Schedule two separately numbered/protected packets carrying the same stream range while the first is unacknowledged, without waiting for loss, within each path congestion window. This is optional transport policy, not a standardized scheduler or a claim that XQUIC implements draft-21.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [], "editorial_references": [ "index.html#round045" ], "qualification": "Bind this explicit policy to a draft-21 implementation. Verify distinct path IDs and correct per-path packet numbers/nonces, independent ACK and congestion accounting, single application delivery, canceled redundant work after acknowledgment, unequal MTUs and failed paths. Establish physical diversity and measure overhead. The XQUIC draft-05/06 evidence is a mechanism precedent only; interoperability and performance have not been tested." }, { "id": "F10-SC", "feature": "F10", "stack": "SC", "status": "N", "reason": "In the selected ordinary SCION/application-UDP send path, SCIONPacketConn.WriteTo serializes one packet and performs one underlay write to the selected next hop. Path choice alone supplies no proactive replication policy. A custom application replicator would be an additional composition, not this profile.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/scionproto/scion/blob/67012de509c89ceedb29c388c01991edfaa5949c/pkg/snet/packet_conn.go#L151" ], "editorial_references": [], "qualification": "" }, { "id": "F10-RT", "feature": "F10", "stack": "RT", "status": "N", "reason": "For the selected established Link, Transport outbound processing restricts transmission to its attached interface and forwarding uses link/path state rather than a concurrent payload scheduler or proactive diverse-path replication. Broadcast of announcements or other non-Link packets does not supply these capabilities to the selected Link.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [], "qualification": "" }, { "id": "F10-NS", "feature": "F10", "stack": "NS", "status": "Y", "reason": "The selected client proactively publishes the same signed event through distinct relay paths before loss. This is application-protocol redundancy already inside the Nostr column, not network-layer replication.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nostr/master/README.md" ], "editorial_references": [], "qualification": "" }, { "id": "F10-MT", "feature": "F10", "stack": "MT", "status": "Y", "reason": "In the A-B-D / A-C-D hidden-relay witness, B and C each schedule a copy of the same initial no-next-hop packet without waiting for a failed delivery or a retry timeout. Cancellation requires hearing a duplicate; mutually hidden relays need not cancel. This is proactive replication with duplicate suppression, not only post-loss retransmission. It supplies redundant branches in that topology, not a guarantee of disjoint paths for every packet or an explicit user path-selection control.", "method": "Read-only code analysis and explicit topology inference", "source_label": "Pinned Meshtastic firmware: forwarding, authenticated receive and client serialization", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp#L117" ], "editorial_references": [], "qualification": "Verify both initial forwarding copies precede any retry timeout, preserve packet identity and are deduplicated at D. Test suppression when B and C can hear each other. No guarantee of branch diversity or quantified reliability improvement." }, { "id": "F10-GN", "feature": "F10", "stack": "GN", "status": "N", "reason": "Normal payload dispatch removes one queue entry and passes its envelope to one selected connection. It does not fan out proactive copies of that item across the ready connections. Reliable-channel retries and repeated control messages are recovery mechanisms, not the proactive diverse-path duplication tested here.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "src/cadet/gnunet-service-cadet_tunnels.c: try_send_normal_payload and trigger_transmissions; src/cadet/gnunet-service-cadet_channel.c: retry_data_task", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F10-ND", "feature": "F10", "stack": "ND", "status": "N", "reason": "The stock NFD 24.07 default is BestRoute: a new Interest selects one eligible next hop. Its alternative-hop branch handles retransmission, not proactive copies. A separately configured multicast strategy is not silently selected.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "NFD 24.07 BestRoute strategy", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/best-route-strategy.cpp", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [], "qualification": "" }, { "id": "F10-AX", "feature": "F10", "stack": "AX", "status": "N", "reason": "The routing algorithm queues a frame on the selected route; alternate routes follow crosslink failure. It does not proactively copy the frame onto distinct paths.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F10-BA", "feature": "F10", "stack": "BA", "status": "Y", "reason": "The native broadcast path clones a frame onto eligible interfaces before any loss report. In a wired A-B-D / A-C-D diamond, B and C forward the same originator/sequence-number item towards D; D suppresses duplicates using its originator broadcast window. This gives redundant paths to the same receiver, not merely delivery to different recipients. Use Ethernet broadcast, gateway mode off, no common bridged backbone and an already converged mesh. Do not credit repeated transmissions on one wireless link or network coding. The claim is broadcast-specific and does not turn ordinary unicast into redundant transmission.", "method": "Pinned primary-source inspection and bounded configuration/topology inference; no execution", "source_label": "Linux v6.12 source; NET/ROM 1.3 manual where indicated", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/soft-interface.c" ], "editorial_references": [], "qualification": "Capture the initial A-B-D and A-C-D copies with matching originator/sequence fields before any retry. Verify one delivery at D and repeat with either branch blocked. Fix broadcast suppression/topology; no guaranteed diversity in arbitrary meshes." }, { "id": "F10-BL", "feature": "F10", "stack": "BL", "status": "N", "reason": "The selected IPv6/Babel service selects routes but defines no proactive user-datagram replication and deduplication mechanism across distinct paths. Alternate route availability, routing updates and failover do not provide that service.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F10-RI", "feature": "F10", "stack": "RI", "status": "N", "reason": "OF0 normally sends upward traffic through the preferred parent and uses a backup feasible successor when that path fails. This selected mechanism is failover, not proactive duplication over distinct paths.", "method": "Selected-profile semantic review; no runtime execution", "source_label": "RPL non-storing mode, OF0 and DTLS 1.3 specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc6552.html" ], "editorial_references": [ "round257-sources.json", "round244.html" ], "qualification": "Neither the selected DTLS profile nor its handshake retransmission supplies proactive redundant application-data forwarding. No replication extension is selected." }, { "id": "F10-HP", "feature": "F10", "stack": "HP", "status": "N", "reason": "The selected HIP/ESP mobility composition has no proactive application-data replication policy over distinct paths. UPDATE retransmission and new-address verification maintain reachability; they are not redundant copies of useful payload sent before loss.", "method": "Selected-profile documentary review; no mobility experiment", "source_label": "HIP host mobility and DTLS 1.3 primary specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-3.2.1" ], "editorial_references": [ "round261-sources.json" ], "qualification": "This verdict concerns the unchanged mobility-only profile, not every possible HIP extension. ESP replay checking alone does not create a replicated-path transmission mechanism." }, { "id": "F10-CX", "feature": "F10", "stack": "CX", "status": "Y", "reason": "Athena supplies an active proactive replication path: a FIB prefix maps to a set of links, _processInterest sends the Interest to that entire set, and the adapter iterates all send-ready links without a loss timer. With two distinct UDP branches holding the same signed object, both replicas can return payload before any loss is detected. The first matching response consumes the PIT entry, suppressing later responses for that satisfied request at the convergence point.", "method": "Bounded documentary composition and source-path analysis; no runtime execution", "source_label": "Primary RPL/6LoWPAN RFCs and pinned Athena source", "sources": [ "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_FIB.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_TransportLinkAdapter.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_PIT.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_TransportLinkModuleUDP.c" ], "editorial_references": [ "round275-sources.json" ], "qualification": "Bounded content-retrieval witness: use a local cache miss, two independently reachable replica branches, adequate hop limit and identical immutable signed bytes selected by a known object-hash restriction. Request replication alone is not payload replication; both replicas must respond before any loss-driven retry. Different faces alone do not prove physical diversity. This source-backed capability does not certify runtime timing, resource costs, end-to-end signature implementation or corruption resistance; E03/F21 remain separate. It is request-driven redundant retrieval, not unsolicited publisher push or a universal default policy." }, { "id": "F10-LI", "feature": "F10", "stack": "LI", "status": "N", "reason": "Unicast RLOC selection chooses a forwarding destination using priority/weight and flow hashing. Neither this selection nor reachability probes specify proactive copies of the same useful data over distinct paths. Multicast extensions are not selected.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F10-IL", "feature": "F10", "stack": "IL", "status": "N", "reason": "Locator Updates and multihoming enable attachment changes and path choice. The selected ordinary ILNP-adapted TCP does not define proactive transmission of duplicate useful data over distinct paths; loss-driven TCP retransmission is different.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F10-TS", "feature": "F10", "stack": "TS", "status": "Y", "reason": "The sender can proactively transmit a packet through both its previously selected UDP endpoint and DERP when path trust expires. The DERP send is not conditional on a UDP send failure or an observed packet loss.", "method": "Pinned source inspection and official purpose statement; no runtime experiment", "source_label": "Tailscale magicsock and packet filter, official privacy statement", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/filter/filter.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/magicsock.go", "https://tailscale.com/blog/tailscale-privacy-anonymity", "https://tailscale.com/security" ], "editorial_references": [ "round589.html", "round589-sources.json" ], "qualification": "Source witness: addrForSendLocked and endpoint.send. Automatic, condition-triggered redundancy; not arbitrary client-requested duplication or guaranteed delivery of both copies." }, { "id": "F10-RA", "feature": "F10", "stack": "RA", "status": "Y", "reason": "The explicitly selected static redundant-path mode sends copies before any loss. Static routing retains distinct destination/QoS/next-hop entries; default PDUFT generation passes them to the kernel, default PFF merges their output ports under the same destination/QoS, and RMT clones the PDU for each output. Configure loop-free paths converging on the same receiver.", "method": "Pinned source call-chain inspection with explicit native policy selection; no execution", "source_label": "IRATI static routing, forwarding-table generator, default PFF and RMT", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/static-routing-ps.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/resource-allocator-ps.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/pff-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/dtp.c" ], "editorial_references": [ "round664.html" ], "qualification": "Yes is a source-supported capability, not a runtime reliability result. At the branch, two native static parameters such as destination 9 with values 1-1-2 and 1-1-3 select QoS 1 through distinct neighbors 2 and 3. Neighbor flows and downstream routes must already exist. This is intentional replication, not ECMP or retransmission; avoid routing loops and account for extra bandwidth." }, { "id": "F11-PN", "feature": "F11", "stack": "PN", "status": "Y", "reason": "Relationship Retention sections 2–5 and 9–10 define bounded retention of complete reliable E2E items across path loss and delayed contact, with immutable item identity, expiry, safe reprotection and duplicate-delivery prevention. This is documented protocol capability. General authenticated policy activation remains unassigned under RET-001; no working wire-v4 activation or eventual-delivery guarantee is claimed.", "method": "Architectural documentary analysis", "source_label": "PRP semantic specification / architectural privacy model", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "RET-001: authenticated retention-policy activation encoding and confirmation remain unassigned. Do not claim operational activation." }, { "id": "F11-PI", "feature": "F11", "stack": "PI", "status": "Y", "reason": "Relationship Retention sections 2–5 and 9–10 define bounded retention of complete reliable E2E items across path loss and delayed contact, with immutable item identity, expiry, safe reprotection and duplicate-delivery prevention. This is documented protocol capability. General authenticated policy activation remains unassigned under RET-001; no working wire-v4 activation or eventual-delivery guarantee is claimed.", "method": "Architectural documentary analysis", "source_label": "PRP semantic specification / architectural privacy model", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "RET-001: authenticated retention-policy activation encoding and confirmation remain unassigned. Do not claim operational activation." }, { "id": "F11-IP", "feature": "F11", "stack": "IP", "status": "N", "reason": "The selected datagram service defines neither proactive multipath copies nor retained delivery across disconnection/non-overlapping contacts.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-BP", "feature": "F11", "stack": "BP", "status": "Y", "reason": "RFC 9171 defines bundle retention constraints and pending forwarding/delivery procedures, with bundle lifetime and deletion rules. A BPA can retain a bundle while communication or application delivery is unavailable, independently of transient TCP retransmission buffers. This is deferred-delivery capability, not guaranteed eventual delivery, unlimited retention, mandatory disk durability or a promise to survive every restart.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification and explicit selected-stack analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5", "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.11" ], "editorial_references": [], "qualification": "" }, { "id": "F11-CG", "feature": "F11", "stack": "CG", "status": "Y", "reason": "Bundles may be retained for later forwarding within their lifetime, rather than only buffered for an active transport connection.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "F11-LT", "feature": "F11", "stack": "LT", "status": "Y", "reason": "BP retains admitted bundles for later forwarding within lifetime and storage constraints, independently of a currently usable complete path.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F11-LP", "feature": "F11", "stack": "LP", "status": "N", "reason": "QUIC streams belong to a connection; the selected stack has no deferred message store across terminated connections. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-10" ], "editorial_references": [], "qualification": "" }, { "id": "F11-TO", "feature": "F11", "stack": "TO", "status": "N", "reason": "The selected Tor service carries live streams through circuits; its relay stream protocol does not define a durable deferred-message store across disconnection. An application mailbox would add a layer absent from this composition. Scope inference from the specified stream service.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-I2", "feature": "F11", "stack": "I2", "status": "N", "reason": "I2NP messages have expiration and use current tunnel delivery. This selected destination/tunnel layer defines no retained application-item service bridging expired paths and later contacts. Deferred messaging applications are not included. Scope inference, not a claim about all I2P software.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/i2np/" ], "editorial_references": [], "qualification": "" }, { "id": "F11-YG", "feature": "F11", "stack": "YG", "status": "N", "reason": "UDP forwarding supplies no deferred application-message store. Route recovery and transient buffers do not meet this criterion. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-CJ", "feature": "F11", "stack": "CJ", "status": "N", "reason": "UDP forwarding supplies no deferred application-message store. Route recovery and transient buffers do not meet this criterion. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-MQ", "feature": "F11", "stack": "MQ", "status": "N", "reason": "QUIC streams belong to a connection; the selected stack has no deferred message store across terminated connections. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-10" ], "editorial_references": [], "qualification": "" }, { "id": "F11-SC", "feature": "F11", "stack": "SC", "status": "N", "reason": "UDP forwarding supplies no deferred application-message store. Route recovery and transient buffers do not meet this criterion. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-RT", "feature": "F11", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link tears down after its stale/keepalive timeout; it does not define a deferred message store surviving that lifecycle. The selected stack excludes LXMF, whose propagation nodes provide an additional store-and-forward service.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [], "qualification": "" }, { "id": "F11-NS", "feature": "F11", "stack": "NS", "status": "Y", "reason": "Relays store regular events for later queries; indefinite retention or guaranteed delivery is not claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F11-MT", "feature": "F11", "stack": "MT", "status": "N", "reason": "Store-and-forward is explicitly disabled in this composition. The selected routing path retains packets for bounded retransmission and then releases them; it is not a deferred delivery store across disconnection. This is a profile-specific negative, not a claim that the optional module does not exist.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [], "qualification": "" }, { "id": "F11-GN", "feature": "F11", "stack": "GN", "status": "N", "reason": "The selected CADET channel supplies connection-bound reliability, not an offline mailbox; no file-sharing/store service is selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-ND", "feature": "F11", "stack": "ND", "status": "Y", "reason": "With cache admission and serving enabled, NFD stores returned Data and can satisfy a later Interest while the producer is disconnected. The object must still be cached and acceptable under freshness/trust rules. This is best-effort deferred retrieval, not custody, disk durability or guaranteed delivery.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "NFD 24.07 forwarding pipeline", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [], "qualification": "Prime an enabled CS with signed Data, disconnect its producer, and fetch the same accepted Data later. Test eviction, freshness expiry and restart separately; no disk durability claim." }, { "id": "F11-AX", "feature": "F11", "stack": "AX", "status": "N", "reason": "The selected classic circuit service has transient transmit queues and retries, not an offline message-retention service. Its routing flowchart discards a frame when no destination entry exists or all attempted next-hop crosslinks fail. Queueing while an active route is available is not a promise to retain an admitted message for later delivery after disconnection; a BBS mailbox is outside this profile.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "The NET/ROM Protocol, pp. 1–3 and routing flowchart p. 7 (visually inspected)", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F11-BA", "feature": "F11", "stack": "BA", "status": "N", "reason": "When next-hop lookup fails, batadv_send_skb_to_orig frees the packet. Its optional network-coding buffer is transient forwarding state, not a deferred message store across disconnection.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "Linux v6.12 batman-adv next-hop transmission", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c" ], "editorial_references": [], "qualification": "" }, { "id": "F11-BL", "feature": "F11", "stack": "BL", "status": "N", "reason": "The selected datagram/routing stack has no deferred delivery store. Ordinary queues and route reconvergence do not preserve messages across disconnection.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-RI", "feature": "F11", "stack": "RI", "status": "N", "reason": "DTLS preserves unreliable application-datagram delivery. Its handshake reliability and temporary record buffers do not define deferred application-message storage after disconnection.", "method": "Selected-profile semantic review; no runtime execution", "source_label": "RPL non-storing mode, OF0 and DTLS 1.3 specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round257-sources.json", "round244.html" ], "qualification": "The selected stack contains no application queue, mailbox or DTN layer. Sleep and re-establishment are separately assessed in F24." }, { "id": "F11-HP", "feature": "F11", "stack": "HP", "status": "N", "reason": "The selected ESP/UDP data path protects host-to-host packets but defines no deferred application-message storage service. HIP control-message retransmission and temporary packet queues are not retention for delivery after disconnection.", "method": "Selected-composition semantic review; no runtime execution", "source_label": "Primary HIP/ESP/mobility and CCNx specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html" ], "editorial_references": [ "round255-sources.json", "round245.html" ], "qualification": "A later locator update or re-established association does not itself retain previously sent application messages. No application queue or DTN layer is selected." }, { "id": "F11-CX", "feature": "F11", "stack": "CX", "status": "Y", "reason": "An enabled CCNx Content Store can retain an admitted signed Content Object and satisfy a later matching Interest after the producer disconnects. RFC 8569 sections 2.4.3, 2.4.5 and 4 define admission, lookup and expiration independently of a live producer connection.", "method": "Documentary bounded witness; no runtime or API test", "source_label": "RFC 8569 CCNx Content Store, cache control and signature semantics", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.3" ], "editorial_references": [ "round259-sources.json", "round259.html" ], "qualification": "Capability requires positive cache capacity, admission and serving enabled, retention through the bounded interval, and valid content. The optional cache has no custody commitment or restart-durability guarantee. Execute retrieval with the producer disconnected and negative tests for expiry and eviction." }, { "id": "F11-LI", "feature": "F11", "stack": "LI", "status": "N", "reason": "The selected data plane forwards IP datagrams over contemporaneously available routes. Map-Caches store mappings, not endpoint messages for delivery after disconnection.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-IL", "feature": "F11", "stack": "IL", "status": "N", "reason": "ILNP communication-cache entries hold identifiers and locators. They do not retain application messages for later delivery after disconnection; TCP retransmission buffers are outside this deferred-storage criterion.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F11-TS", "feature": "F11", "stack": "TS", "status": "N", "reason": "DERP drops packets for an unavailable destination and drains queued packets when a client disconnects. These are live forwarding queues, not storage for deferred delivery.", "method": "Official documentation and pinned source inspection; no runtime test", "source_label": "Tailscale control plane and DERP source 566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go", "https://tailscale.com/docs/concepts/control-data-planes", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round586.html", "round586-sources.json" ], "qualification": "Source witness: handleFrameSendPacket and stopWriter. No additional messaging application is selected." }, { "id": "F11-RA", "feature": "F11", "stack": "RA", "status": "N", "reason": "The selected service buffers SDUs within transport flows, with bounded retransmission policies. DTP teardown destroys its queued data; RMT discards a PDU when no next hop is available. No deferred-delivery message store with a lifecycle independent of that transport is selected. These transient queues do not meet F11.", "method": "Pinned forwarding, queue-lifecycle and routing-source inspection with selected-policy documentation", "source_label": "IRATI RMT, DTP and link-state routing source; normal-DIF configuration", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/dtp.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://raw.githubusercontent.com/wiki/IRATI/stack/Flow-Allocation.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/default.dif", "https://arxiv.org/abs/2510.27325" ], "editorial_references": [ "round659.html" ], "qualification": "No for the selected normal-DIF IRATI flow and routing composition, including its mobility mode. No assertion that every possible RINA policy lacks this capability. Retransmission queues and make-before-break continuity do not establish DTN storage. Source inspection and documentation only; no runtime experiment." }, { "id": "F12-PN", "feature": "F12", "stack": "PN", "status": "Y", "reason": "Multicast/Groupcast Reference Model section 5 explicitly allows aggregators to replicate an already authorized encrypted unit, without acquiring content or membership authority. This satisfies architectural network-forwarder replication. Genesis/event serialization and complete wire admission remain unfinished under sections 1 and 12; no interoperable deployment is claimed.", "method": "Architectural documentary analysis", "source_label": "PRP semantic specification / architectural privacy model", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Canonical multicast genesis/event serialization and admission to the selected wire version remain unfinished." }, { "id": "F12-PI", "feature": "F12", "stack": "PI", "status": "Y", "reason": "Multicast/Groupcast Reference Model section 5 explicitly allows aggregators to replicate an already authorized encrypted unit, without acquiring content or membership authority. This satisfies architectural network-forwarder replication. Genesis/event serialization and complete wire admission remain unfinished under sections 1 and 12; no interoperable deployment is claimed.", "method": "Architectural documentary analysis", "source_label": "PRP semantic specification / architectural privacy model", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Canonical multicast genesis/event serialization and admission to the selected wire version remain unfinished." }, { "id": "F12-IP", "feature": "F12", "stack": "IP", "status": "Y", "reason": "The explicit multicast control composition uses IP group addressing, IGMP/MLD membership and PIM-SM router trees to replicate packets at network forwarders. This credits available network multicast, not universal ISP deployment.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc7761.html" ], "editorial_references": [], "qualification": "" }, { "id": "F12-BP", "feature": "F12", "stack": "BP", "status": "Y", "reason": "Non-singleton dtn endpoints and section 5.4 intermediate fanout support network multicast. This profile selects static group forwarding; ipn remains the node/bootstrap scheme. Collective addressing alone was insufficient evidence.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1.1" ], "editorial_references": [], "qualification": "Pin an implementation and forwarding configuration; test concurrency, route diversity, duplicate handling and group delivery. No execution performed." }, { "id": "F12-CG", "feature": "F12", "stack": "CG", "status": "N", "reason": "SABR section 2.2 restricts routing to singleton endpoints. Alternate copies to the same destination are not multicast delivery to multiple recipients.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F12-LT", "feature": "F12", "stack": "LT", "status": "N", "reason": "The selected SABR procedures route to singleton endpoints, without multicast forwarding to multiple recipients.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F12-LP", "feature": "F12", "stack": "LP", "status": "N", "reason": "Topic distribution requires a pubsub module, explicitly absent here. This does not characterize the whole libp2p ecosystem.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://libp2p.io/docs/pubsub/" ], "editorial_references": [], "qualification": "" }, { "id": "F12-TO", "feature": "F12", "stack": "TO", "status": "N", "reason": "Tor relay streams connect a client and an end node; the selected relay protocol supplies no network-forwarder one-to-many replication. Multiple streams or application fanout are different compositions.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [], "qualification": "" }, { "id": "F12-I2", "feature": "F12", "stack": "I2", "status": "N", "reason": "Tunnel fragment delivery selects a local endpoint, router or tunnel. This supplies neither network multicast branching nor a distributed multiple-sender group contract in the selected tunnel layer. Bundling different messages is not replication of one item to a group.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/tunnel-message/" ], "editorial_references": [], "qualification": "" }, { "id": "F12-YG", "feature": "F12", "stack": "YG", "status": "N", "reason": "Yggdrasil v0.5.14 writePC accepts its node/subnet ranges and maps a destination to one public key; IPv6 multicast destinations are rejected. Link-local peer discovery is not routed content multicast. Address-range checks are in src/address/address.go at the same tag.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/v0.5.14/src/ipv6rwc/ipv6rwc.go" ], "editorial_references": [], "qualification": "" }, { "id": "F12-CJ", "feature": "F12", "stack": "CJ", "status": "N", "reason": "The selected cjdns forwarding architecture selects one next node and switch egress for a packet. It supplies no collective branching or distributed group-authority contract. Scope inference for the documented IPv6/application-UDP composition; additional group overlays are excluded.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#the-router" ], "editorial_references": [], "qualification": "" }, { "id": "F12-MQ", "feature": "F12", "stack": "MQ", "status": "N", "reason": "Multiple QUIC paths join the same two endpoints; they add neither multi-recipient forwarding nor group governance. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21#section-1" ], "editorial_references": [], "qualification": "" }, { "id": "F12-SC", "feature": "F12", "stack": "SC", "status": "N", "reason": "The pinned UDP/IP router resolves a service destination through svc.Any after stripping the multicast flag, selecting one backend. The SVC multicast bit alone therefore does not demonstrate replication. The selected host-addressed UDP composition supplies no multicast forwarding tree; this does not classify every proposed SCION extension.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/scionproto/scion/blob/67012de509c89ceedb29c388c01991edfaa5949c/router/underlayproviders/udpip/udpip.go#L949" ], "editorial_references": [], "qualification": "" }, { "id": "F12-RT", "feature": "F12", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Transport.outbound excludes GROUP from routed path lookup, and packet_filter rejects GROUP packets with more than one hop. The selected Link has no network multicast replication service; indirect group delivery requires a different composition. This resolves the ambiguous prose using the pinned implementation.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [], "qualification": "" }, { "id": "F12-NS", "feature": "F12", "stack": "NS", "status": "N", "reason": "Application-relay fanout is neither network multicast nor PRP-equivalent distributed groupcast. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F12-MT", "feature": "F12", "stack": "MT", "status": "N", "reason": "The selected mechanism is broadcast flooding rather than group-addressed multicast routing: the broadcast destination is common, while the channel field identifies decryption context. Forwarding does not maintain multicast member/group routes; a private channel filters readers, not a recipient-specific forwarding tree. Network relays do replicate packets, but that broadcast capability alone does not meet the row's multicast distinction. This negative does not deny one-to-many delivery, nor require a particular multicast tree algorithm.", "method": "Read-only code analysis and explicit topology inference", "source_label": "Pinned Meshtastic firmware: forwarding, authenticated receive and client serialization", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp#L243" ], "editorial_references": [], "qualification": "" }, { "id": "F12-GN", "feature": "F12", "stack": "GN", "status": "N", "reason": "The selected CADET service sends through channels to individual destination peers. Multiple connections to that peer do not supply network replication to multiple recipients; no multicast service is selected.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F12-ND", "feature": "F12", "stack": "ND", "status": "Y", "reason": "NFD sends matching Data to pending downstream faces recorded in the PIT. Multiple consumers can therefore receive network-forwarder replicas of one incoming Data packet. This is request-driven named-data distribution, not unsolicited group push. See onIncomingData and Strategy::afterReceiveData.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "NFD 24.07 forwarding pipeline", "sources": [ "https://docs.named-data.net/NFD/24.07/doxygen/forwarder_8cpp_source.html" ], "editorial_references": [], "qualification": "Run NFD 24.07 with two downstream Ethernet faces requesting the same Data before its arrival. Capture one upstream response and both downstream deliveries; check expiry and duplicate handling. No packet capture or execution performed." }, { "id": "F12-AX", "feature": "F12", "stack": "AX", "status": "N", "reason": "User information follows a destination-node circuit. NODES broadcasts exchange routing information, not replicated user content.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F12-BA", "feature": "F12", "stack": "BA", "status": "N", "reason": "Linux 6.12 has multicast tracker replication, but multicast mode selection admits IPv4/IPv6 payloads; other EtherTypes use classic broadcast flooding. The selected native non-IP application profile therefore lacks the qualified group-selective path. An explicit IPv4/IPv6 composition could receive a different decision.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "Linux v6.12 multicast mode selection", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/multicast.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/multicast_forw.c" ], "editorial_references": [], "qualification": "" }, { "id": "F12-BL", "feature": "F12", "stack": "BL", "status": "N", "reason": "Babel multicast Hellos distribute link-local routing control. They do not install a routed multicast data distribution service. The selected IPv6/Babel stack includes no multicast-routing extension such as PIM.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F12-RI", "feature": "F12", "stack": "RI", "status": "N", "reason": "RFC 6550 section 16.3.2 excludes its basic multicast mechanism from the selected non-storing mode. That mechanism belongs to the optional storing-mode multicast composition instead.", "method": "Selected-profile semantic review; no runtime execution", "source_label": "RPL non-storing mode, OF0 and DTLS 1.3 specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html" ], "editorial_references": [ "round257-sources.json", "round244.html" ], "qualification": "Link-local multicast control messages and one-to-many application transmissions do not satisfy routed payload replication. This is not a claim that every RPL profile lacks multicast." }, { "id": "F12-HP", "feature": "F12", "stack": "HP", "status": "N", "reason": "The selected protected HIP data service establishes pairwise host-to-host ESP associations. It does not define a network multicast tree and group security association that replicate one protected payload to multiple final hosts.", "method": "Documentary bounded-witness and state inventory; no runtime execution", "source_label": "Primary forwarding, mobility and state specifications; selected-profile witnesses", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html#section-3" ], "editorial_references": [ "round265-sources.json" ], "qualification": "IPv4 underlay capability alone does not add group delivery to the selected HIP/ESP service. Multiple separately encrypted unicast sends are not network-forwarder fanout. No multicast security extension is selected." }, { "id": "F12-CX", "feature": "F12", "stack": "CX", "status": "Y", "reason": "RFC 8569 sections 2.4.2 and 2.4.5 require a returned Content Object to satisfy all matching pending Interests. Forwarders send copies toward the different requesting previous hops: replication occurs in the forwarding plane.", "method": "Selected-profile documentary review; no runtime test", "source_label": "CCNx 1.0 semantics and selected UDP/CRC32C Interest profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.5", "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round258-sources.json" ], "qualification": "Interest suppression is optional; satisfying all matching pending Interests is still required. This is demand-driven fanout, not unsolicited broadcast or distributed group authority." }, { "id": "F12-LI", "feature": "F12", "stack": "LI", "status": "N", "reason": "The selected base LISP composition does not select multicast distribution. RFC 9300 section 14 delegates distribution details to RFC 6831 or RFC 8378; multicast address fields alone do not provide a forwarding tree.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-14", "https://www.rfc-editor.org/rfc/rfc9301.html#section-5.4" ], "editorial_references": [], "qualification": "Profile-scoped No, not absence of multicast in the LISP family. Adding a specified LISP multicast mode and its underlay/control dependencies would require an explicit composition update." }, { "id": "F12-IL", "feature": "F12", "stack": "IL", "status": "N", "reason": "RFC 6740 section 3.7 preserves IPv6 multicast rather than defining a new ILNP group service. The selected TCP composition supplies pairwise communication and does not select multicast membership/routing. Native IPv6 multicast potential is not a demonstrated replication path for this selected service.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-3.7", "https://www.rfc-editor.org/rfc/rfc9293.html#section-2.2" ], "editorial_references": [], "qualification": "Profile-scoped No. ILNP is compatible with IPv6 multicast; an explicitly selected multicast transport and router-control composition could be assessed separately. This does not imply that ILNP forbids multicast." }, { "id": "F12-TS", "feature": "F12", "stack": "TS", "status": "N", "reason": "The selected Tailscale packet filter explicitly drops multicast destinations, and its peer delivery path sends to an identified peer rather than a multicast forwarding group.", "method": "Pinned source inspection and official purpose statement; no runtime experiment", "source_label": "Tailscale magicsock and packet filter, official privacy statement", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/filter/filter.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/filter/filter.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/magicsock.go", "https://tailscale.com/blog/tailscale-privacy-anonymity", "https://tailscale.com/security" ], "editorial_references": [ "round589.html", "round589-sources.json" ], "qualification": "Applies to the selected TUN service. An added application fanout or multicast tunneling system is outside this profile; layer 3 alone is not the reason for No." }, { "id": "F12-RA", "feature": "F12", "stack": "RA", "status": "N", "reason": "The selected IRATI flow allocator resolves one remote application and creates a connection to it. Static redundant forwarding clones that connection PDU onto several next hops while retaining its destination address and destination CEP. At reception, RMT checks the local destination address and passes the destination CEP to EFCP, which looks up one connection instance and discards the PDU if no such instance exists. These paths converge on the same receiver; they do not establish delivery to multiple final participants.", "method": "Pinned flow allocation, forwarding and receiver demultiplexing source inspection", "source_label": "IRATI RMT and EFCP delivery path", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/efcp.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/namespace-manager.cc" ], "editorial_references": [ "round664.html", "round670.html", "round671.html" ], "qualification": "No for multicast in the declared IRATI composition. The selected policies provide redundant paths to one receiver, not a multicast group address, receiver connection mapping or destination-rewriting policy for a distribution tree. A shared DAF name selects one member during discovery. This does not rule out a different RINA policy or implementation supporting multicast. F09/F10 redundancy and F22 shared-reference discovery remain Yes. Pinned source analysis, not a runtime test." }, { "id": "F13-PN", "feature": "F13", "stack": "PN", "status": "Y", "reason": "The comparative whitepaper capability table explicitly composes a group from one authorized multicast channel per sender, preserving each sender’s strong-identity authority. The groupcast semantic specification sections 6–9 provides distributed administration, membership and continuity after creator departure. Together these establish architectural multiple-sender group distribution, not merely a membership object. Application-specific publishing rights and reliable multipoint delivery are not inferred.", "method": "Architectural documentary analysis", "source_label": "Project comparative whitepaper plus groupcast semantic specification", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Bind the per-sender multicast composition, membership events and genesis serialization to the wire profile. Reliable multipoint delivery is not established by unreliable fanout." }, { "id": "F13-PI", "feature": "F13", "stack": "PI", "status": "Y", "reason": "The comparative whitepaper capability table explicitly composes a group from one authorized multicast channel per sender, preserving each sender’s strong-identity authority. The groupcast semantic specification sections 6–9 provides distributed administration, membership and continuity after creator departure. Together these establish architectural multiple-sender group distribution, not merely a membership object. Application-specific publishing rights and reliable multipoint delivery are not inferred.", "method": "Architectural documentary analysis", "source_label": "Project comparative whitepaper plus groupcast semantic specification", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Bind the per-sender multicast composition, membership events and genesis serialization to the wire profile. Reliable multipoint delivery is not established by unreliable fanout." }, { "id": "F13-IP", "feature": "F13", "stack": "IP", "status": "N", "reason": "PIM-SM supplies multicast delivery trees; it does not provide distributed group membership authority and authorization with group continuity across sessions. Multicast tree state alone does not establish these behaviors.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc7761.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-BP", "feature": "F13", "stack": "BP", "status": "N", "reason": "BP registration state is local and the protocol does not distribute it. The selected static collective fanout supplies multicast, but no distributed group-authority and continuity contract for multiple senders. BPSec local policy does not add that contract. An added group protocol would change the selected stack.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9171#section-3.1" ], "editorial_references": [], "qualification": "" }, { "id": "F13-CG", "feature": "F13", "stack": "CG", "status": "N", "reason": "The selected singleton routing composition adds no distributed multi-sender group authority or continuity mechanism.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F13-LT", "feature": "F13", "stack": "LT", "status": "N", "reason": "Singleton bundle routing does not implement the selected criterion’s distributed multi-sender group authority and continuity.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F13-LP", "feature": "F13", "stack": "LP", "status": "N", "reason": "Topic distribution requires a pubsub module, explicitly absent here. This does not characterize the whole libp2p ecosystem.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://libp2p.io/docs/pubsub/" ], "editorial_references": [], "qualification": "" }, { "id": "F13-TO", "feature": "F13", "stack": "TO", "status": "N", "reason": "The selected Tor stream/onion-service composition has no distributed group authority plus per-sender multicast distribution. An application could add a group, but that layer is absent here. Scope inference, not a limitation on applications using Tor.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-I2", "feature": "F13", "stack": "I2", "status": "N", "reason": "Tunnel fragment delivery selects a local endpoint, router or tunnel. This supplies neither network multicast branching nor a distributed multiple-sender group contract in the selected tunnel layer. Bundling different messages is not replication of one item to a group.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/tunnel-message/" ], "editorial_references": [], "qualification": "" }, { "id": "F13-YG", "feature": "F13", "stack": "YG", "status": "N", "reason": "The selected Yggdrasil IPv6/application-UDP composition has individual key-addressed delivery, not distributed group authority and multiple-sender group continuity. Link-local discovery and a shared group password do not supply that contract. Scope inference, not a claim about possible application overlays.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/v0.5.14/src/ipv6rwc/ipv6rwc.go" ], "editorial_references": [], "qualification": "" }, { "id": "F13-CJ", "feature": "F13", "stack": "CJ", "status": "N", "reason": "The selected cjdns forwarding architecture selects one next node and switch egress for a packet. It supplies no collective branching or distributed group-authority contract. Scope inference for the documented IPv6/application-UDP composition; additional group overlays are excluded.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#the-router" ], "editorial_references": [], "qualification": "" }, { "id": "F13-MQ", "feature": "F13", "stack": "MQ", "status": "N", "reason": "Multiple QUIC paths join the same two endpoints; they add neither multi-recipient forwarding nor group governance. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21#section-1" ], "editorial_references": [], "qualification": "" }, { "id": "F13-SC", "feature": "F13", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP stack forwards to an individual destination using packet-carried paths. It contains no multiple-sender group membership, distributed group authority and continuity contract. An application group protocol would be an additional layer. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-RT", "feature": "F13", "stack": "RT", "status": "N", "reason": "The selected Link is a channel to one SINGLE destination, not a multiple-sender group with distributed authority and continuity. Reticulum GROUP destinations and application group services must be evaluated as different compositions.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-NS", "feature": "F13", "stack": "NS", "status": "N", "reason": "The selected NIP-01 relay/event composition distributes messages but does not specify distributed group membership authority and group continuity across sessions. Application-relay fanout alone does not establish these behaviors. Scope inference for the selected stack, not the entire Nostr ecosystem.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F13-MT", "feature": "F13", "stack": "MT", "status": "N", "reason": "The selected shared-key channels and multi-sender flooding support broadcasting, but do not specify distributed group membership authority and group continuity across sessions. Possession of a common channel key alone does not establish these behaviors. Selected-profile inference.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp" ], "editorial_references": [], "qualification": "" }, { "id": "F13-GN", "feature": "F13", "stack": "GN", "status": "N", "reason": "Pairwise channels and routing do not supply distributed group membership/authority semantics. No group application is selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-ND", "feature": "F13", "stack": "ND", "status": "N", "reason": "Named-data fanout supplies distribution, but the selected NFD profile has no multi-sender group membership, distributed authority and group continuity service. The profile explicitly excludes an application sync/group protocol.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "NFD 24.07 module and forwarding architecture", "sources": [ "https://docs.named-data.net/NFD/24.07/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-AX", "feature": "F13", "stack": "AX", "status": "N", "reason": "Pairwise transport circuits and routing announcements provide no distributed multi-sender group authority or continuity.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F13-BA", "feature": "F13", "stack": "BA", "status": "N", "reason": "The virtual Ethernet switch distributes frames without providing cryptographic multi-sender group authority and continuity. Adding a higher-layer group protocol would change the selected composition.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-BL", "feature": "F13", "stack": "BL", "status": "N", "reason": "The selected IPv6/Babel service routes datagrams; it does not define multi-sender group authority, membership and continuity. Routing-neighbor discovery is not that group service.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-RI", "feature": "F13", "stack": "RI", "status": "N", "reason": "The selected pairwise DTLS associations authenticate two endpoints. They define no distributed multi-sender group authority or group continuity independent of those associations.", "method": "Selected-profile semantic review; no runtime execution", "source_label": "RPL non-storing mode, OF0 and DTLS 1.3 specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round257-sources.json", "round244.html" ], "qualification": "The RPL routing topology and separately configured pairwise keys do not supply a group-membership protocol. No group communication extension is selected." }, { "id": "F13-HP", "feature": "F13", "stack": "HP", "status": "N", "reason": "The selected HIP base exchange establishes pairwise host associations and ESP SAs. These do not define distributed group membership, multi-sender group authorization or group continuity across separate associations.", "method": "Selected-composition semantic review; no runtime execution", "source_label": "Primary HIP/ESP/mobility and CCNx specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html" ], "editorial_references": [ "round255-sources.json", "round245.html" ], "qualification": "Multiple simultaneous pairwise associations are not the group authority required by F13. No multicast/group-key or application group extension is selected." }, { "id": "F13-CX", "feature": "F13", "stack": "CX", "status": "N", "reason": "The selected CCNx layer defines Interests, Content Objects and their validation and forwarding. Shared names, multiple producers or multiple consumers do not supply a distributed group membership and authorization lifecycle.", "method": "Selected-composition semantic review; no runtime execution", "source_label": "Primary HIP/ESP/mobility and CCNx specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round255-sources.json", "round245.html" ], "qualification": "The selected per-object producer trust can authenticate content without establishing the F13 group. Application synchronization and group-membership protocols are not included." }, { "id": "F13-LI", "feature": "F13", "stack": "LI", "status": "N", "reason": "The selected mapping and encapsulation protocols do not define a distributed authorized-sender group with membership and continuity across sessions. Multicast address handling alone would not supply those properties.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-IL", "feature": "F13", "stack": "IL", "status": "N", "reason": "ILNP inherits IP multicast semantics but does not thereby define a persistent group of authorized senders with distributed group authority. The declared ILNPv6/TCP composition selects no such group protocol.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F13-TS", "feature": "F13", "stack": "TS", "status": "N", "reason": "The managed tailnet uses centrally maintained membership, discovery and access policy. Multiple communicating nodes do not supply the distributed group authority required by this criterion.", "method": "Official documentation and pinned source inspection; no runtime test", "source_label": "Tailscale control plane and DERP source 566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/concepts/control-data-planes", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round586.html", "round586-sources.json" ], "qualification": "Tailnet Lock adds participant signatures for node admission; it does not replace the managed group policy and discovery service with distributed groupcast authority." }, { "id": "F13-RA", "feature": "F13", "stack": "RA", "status": "N", "reason": "The selected service registers application names and allocates peer-to-peer flows. It supplies no selected multi-sender group service with distributed group authority and membership continuity across application sessions. DIF membership organizes transport providers; it does not by itself supply that application-visible group contract.", "method": "Primary API, forwarding-policy documentation and pinned source assessment; no execution", "source_label": "IRATI application API and selected forwarding behavior", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Application-API.md", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md" ], "editorial_references": [ "round660.html" ], "qualification": "No for the selected flow service, not a claim that group applications cannot run over RINA. A separate group-management layer or policy must specify the sender set, distributed authority and continuity before it can be credited. Multicast forwarding alone would not settle F13." }, { "id": "F14-PN", "feature": "F14", "stack": "PN", "status": "Y", "reason": "The routing whitepaper security/privacy section explicitly aims to keep final-peer and full-path knowledge unnecessary for a provider or aggregation context, using opaque payloads and local labels. F14 asks for an explicit location-hiding goal and mechanism, not proof that every control exchange achieves it. Final-identity disclosure in the concrete profile remains separately open in C02.", "method": "Architectural documentary analysis", "source_label": "PRP semantic specification / architectural privacy model", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "" }, { "id": "F14-PI", "feature": "F14", "stack": "PI", "status": "Y", "reason": "The routing whitepaper security/privacy section explicitly aims to keep final-peer and full-path knowledge unnecessary for a provider or aggregation context, using opaque payloads and local labels. F14 asks for an explicit location-hiding goal and mechanism, not proof that every control exchange achieves it. Final-identity disclosure in the concrete profile remains separately open in C02.", "method": "Architectural documentary analysis", "source_label": "PRP semantic specification / architectural privacy model", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "" }, { "id": "F14-IP", "feature": "F14", "stack": "IP", "status": "N", "reason": "Ordinary selected IP headers expose routable source/destination addresses and forwarding metadata. This baseline supplies no endpoint-location or established-control concealment.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-BP", "feature": "F14", "stack": "BP", "status": "N", "reason": "The selected BP/TCPCL/BPSec composition protects content and transport but includes no endpoint-location-hiding routing construction. BPSec does not hide the fact of protected communication or automatically conceal routing metadata. Known EIDs and gateway forwarding are not an anonymity system.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9172.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-CG", "feature": "F14", "stack": "CG", "status": "N", "reason": "Scheduled routing, TLS and BPSec in this profile provide no endpoint-location-hiding construction. No anonymity overlay is included.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-LT", "feature": "F14", "stack": "LT", "status": "N", "reason": "This composition has no explicit endpoint-location-hiding construction. Payload security is not an anonymity overlay.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-LP", "feature": "F14", "stack": "LP", "status": "N", "reason": "The selected known-peer QUIC composition directly dials transport addresses and provides secure peer communication, without a location-hiding relay construction. Peer IDs separate identity from addresses but do not conceal those addresses from transport counterparts. Optional relay or anonymity layers are not selected.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://libp2p.io/docs/listen-and-dial/" ], "editorial_references": [], "qualification": "" }, { "id": "F14-TO", "feature": "F14", "stack": "TO", "status": "Y", "reason": "Introduction and rendezvous circuits deliberately let clients reach an onion service without learning its hosting address through the service protocol. This credits a location-hiding construction, not protection against endpoint leaks, compromised guards, collusion or global traffic correlation.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-I2", "feature": "F14", "stack": "I2", "status": "Y", "reason": "Destination references and inbound/outbound tunnels separate application communication from direct disclosure of the hosting router's transport address to the counterpart. The selected multi-hop profile has an explicit anonymity purpose. Neighbor observations, router metadata and correlation remain limitations; not every router address is hidden.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.i2p.net/en/docs/overview/tech-intro/" ], "editorial_references": [], "qualification": "" }, { "id": "F14-YG", "feature": "F14", "stack": "YG", "status": "N", "reason": "Yggdrasil explicitly excludes anonymity as a project goal; direct Internet peers observe IP addresses, and topology information may be visible. End-to-end encryption and key-derived node addresses do not constitute a location-hiding construction.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://yggdrasil-network.github.io/faq.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-CJ", "feature": "F14", "stack": "CJ", "status": "N", "reason": "The selected cjdns routing/CryptoAuth stack encrypts traffic and authenticates nodes but adds no onion-service-style location-hiding protocol. Neighbor peering and route discovery remain observable roles. This is a selected-mechanism inference, not a claim that every remote observer can recover every node's physical location.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [], "qualification": "" }, { "id": "F14-MQ", "feature": "F14", "stack": "MQ", "status": "N", "reason": "QUIC encryption and migration do not hide endpoint network addresses from the transport counterpart. Multiple paths and packet padding do not by themselves add a location-hiding relay system; none is present in the selected composition.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-SC", "feature": "F14", "stack": "SC", "status": "N", "reason": "The selected SCION header carries endpoint addressing and path information for forwarding. The application-UDP profile adds no location-hiding construction. Path choice and infrastructure trust do not imply that endpoint network location is concealed.", "method": "Individual review of inherited classification; no protocol execution", "source_label": "Primary specification / explicit endpoint and observer scope", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-RT", "feature": "F14", "stack": "RT", "status": "Y", "reason": "Reticulum explicitly targets initiator anonymity: Link creation supplies ephemeral key material and a link ID without an origin address. In a multi-hop Link, a remote responder or nonadjacent transit observer is not given the initiator's global network locator. Credit is initiator-side only; the first attachment, hop count, destination announcements and correlation remain visible or inferable.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://reticulum.network/manual/understanding.html#link-establishment" ], "editorial_references": [], "qualification": "Capture a multi-hop Link from a previously unannounced initiator, without identify() or reused application identity. Inventory each observer's state and distinguish the first local attachment from the remote origin locator. No global-correlation or destination-location guarantee." }, { "id": "F14-NS", "feature": "F14", "stack": "NS", "status": "N", "reason": "This basic stack includes no mechanism hiding connection location from relays. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F14-MT", "feature": "F14", "stack": "MT", "status": "N", "reason": "The selected packet model exposes sender and destination node numbers to relays and radio observers; it does not supply an endpoint-location-hiding construction. Disabling position reports avoids explicit coordinates but does not turn radio forwarding into location concealment.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [], "qualification": "" }, { "id": "F14-GN", "feature": "F14", "stack": "GN", "status": "N", "reason": "The selected TRANSPORT/CORE/CADET/R5N stack protects end-to-end payload confidentiality and authenticates peers, but provides no selected endpoint-location-hiding mechanism. In GNUnet 0.20.0, ConnectionCreate carries the full ordered peer-identity path from origin to destination; forwarding peers process it after adjacent CORE decryption. Thus encrypted payloads do not hide the endpoint identity position in that overlay path. This does not assert that every relay learns the endpoint physical address or geographic location. Anonymous file sharing and other GNUnet subsystems are not part of this composition, and their goals are not inherited by CADET.", "method": "Versioned architecture and pinned GNUnet 0.20.0 connection-format analysis", "source_label": "CADET confidentiality scope and ConnectionCreate path format", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [], "qualification": "" }, { "id": "F14-ND", "feature": "F14", "stack": "ND", "status": "N", "reason": "Named-data addressing decouples content names from locations, but this selected plain Interest/Data profile supplies no endpoint-location concealment mechanism. Local faces, requested names and routing information remain observable; name-based retrieval alone is not an anonymity mechanism.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "NFD 24.07 module and forwarding architecture", "sources": [ "https://docs.named-data.net/NFD/24.07/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-AX", "feature": "F14", "stack": "AX", "status": "N", "reason": "The selected classic stack exposes originating and destination node callsigns and next-hop routing information; it supplies no endpoint-location concealment mechanism. Radio direction finding is a separate exposure.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F14-BA", "feature": "F14", "stack": "BA", "status": "N", "reason": "Virtual-switch adjacency hides physical hop count from upper-layer addressing, but supplies no endpoint-location concealment mechanism against network observers. Destination originator and client identifiers remain available.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "Linux v6.12 batman-adv packet formats", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h" ], "editorial_references": [], "qualification": "" }, { "id": "F14-BL", "feature": "F14", "stack": "BL", "status": "N", "reason": "The selected IPv6/Babel stack routes visible addresses without an endpoint-location concealment mechanism. Private ULA allocation removes a public-allocation dependency, not the routing attachment information visible to intermediaries.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F14-RI", "feature": "F14", "stack": "RI", "status": "N", "reason": "DTLS encrypts the application payload but leaves the selected IPv6/UDP path locators outside that protection. This composition includes no endpoint-location concealment mechanism.", "method": "Selected-profile semantic review; no runtime execution", "source_label": "RPL non-storing mode, OF0 and DTLS 1.3 specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round257-sources.json", "round244.html" ], "qualification": "Traffic encryption alone is not location anonymity. No anonymity relay, tunneling overlay or location-hiding extension is selected." }, { "id": "F14-HP", "feature": "F14", "stack": "HP", "status": "N", "reason": "The selected mobility mechanism updates the peer's usable IP locators. ESP protects user payload, but the communicating host locators remain visible in the outer routed IP packets. No location-concealing relay or anonymity mechanism is selected.", "method": "Selected-composition semantic review; no runtime execution", "source_label": "Primary HIP/ESP/mobility and CCNx specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round255-sources.json", "round245.html" ], "qualification": "Identity/locator separation and an encrypted payload are not endpoint-location concealment. This does not deny identity-protection options or mobility benefits." }, { "id": "F14-CX", "feature": "F14", "stack": "CX", "status": "N", "reason": "Named-content retrieval separates a content reference from a storage location, but the selected plain CCNx Interest/Content Object profile introduces no mechanism aimed at concealing endpoint location. Adjacent IP/UDP contacts, names and forwarding paths remain observable at their respective observation points.", "method": "Selected-composition semantic review; no runtime execution", "source_label": "Primary HIP/ESP/mobility and CCNx specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round255-sources.json", "round245.html" ], "qualification": "Caching may change which node supplies an object; it does not establish endpoint-location anonymity. Encryption and anonymity overlays are not selected." }, { "id": "F14-LI", "feature": "F14", "stack": "LI", "status": "N", "reason": "Separating an EID from a RLOC does not conceal the attachment represented by that RLOC: the selected unencrypted encapsulation exposes both inner EIDs and outer RLOCs, and mapping resolution associates them. The selected base xTR/Map-Server profile contains no endpoint-location-hiding relay or obfuscation mechanism.", "method": "Specification review; unchanged selected profile", "source_label": "rfc9300.html#section-5; rfc9300.html#section-3", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-5", "https://www.rfc-editor.org/rfc/rfc9300.html#section-3" ], "editorial_references": [], "qualification": "Other LISP extensions or privacy-oriented deployments are not classified by this base-profile verdict." }, { "id": "F14-IL", "feature": "F14", "stack": "IL", "status": "N", "reason": "ILNP explicitly discusses location privacy, but its Locator Rewriting Relay is an optional deployment mechanism. The selected direct ILNPv6/TCP profile has no such relay or locator-obfuscation component; changing a NID provides a different identity-privacy property and does not hide the current Locator.", "method": "Specification review; unchanged selected profile", "source_label": "rfc6740.html#section-10.1; rfc6748.html#section-7", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-10.1", "https://www.rfc-editor.org/rfc/rfc6748.html#section-7" ], "editorial_references": [], "qualification": "This is not a denial that the broader ILNP architecture describes location privacy. Adding the optional LRR would require declaring that composition and reassessing its dependencies." }, { "id": "F14-TS", "feature": "F14", "stack": "TS", "status": "N", "reason": "Tailscale explicitly prioritizes authenticated private connectivity rather than location anonymity. Its selected direct paths expose network locators, and the coordination service knows node addressing.", "method": "Pinned source inspection and official purpose statement; no runtime experiment", "source_label": "Tailscale magicsock and packet filter, official privacy statement", "sources": [ "https://tailscale.com/blog/tailscale-privacy-anonymity", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/filter/filter.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/magicsock.go", "https://tailscale.com/blog/tailscale-privacy-anonymity", "https://tailscale.com/security" ], "editorial_references": [ "round589.html", "round589-sources.json" ], "qualification": "No exit-node anonymity service or additional anonymity wrapper is selected. Payload confidentiality and limited packet padding do not establish an endpoint-location-hiding goal." }, { "id": "F14-RA", "feature": "F14", "stack": "RA", "status": "N", "reason": "The selected RINA composition separates application names from DIF-scoped addresses, but resolves those names to their serving IPCP addresses. The namespace manager distributes directory entries to neighboring members; flow allocation uses that mapping and carries local and remote addresses. In the routed lower DIF, these addresses identify the attachment of the endpoint-host IPCPs. Recursive scope and encryption restrict visibility to particular members, but the selected composition does not conceal endpoint network location from those routing members.", "method": "Pinned namespace distribution and flow-address source inspection", "source_label": "IRATI directory and flow allocation", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/namespace-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc" ], "editorial_references": [ "round667.html", "round672.html" ], "qualification": "No for an explicit endpoint-location-hiding mechanism in this selected composition. The observer is an admitted member of the routed DIF carrying the endpoint-host flow, not an arbitrary outside listener or necessarily the first physical access point. Location means network attachment within that scope, not GPS, a street address or civil identity. Stable names, mobility and encrypted payloads remain supported; this verdict does not deny scope isolation or claim every RINA design must expose the same information." }, { "id": "F15-PN", "feature": "F15", "stack": "PN", "status": "Y", "reason": "PRP admission separates public control requests from admitted HS2 processing. In the pinned runtime, configured peer policy, challenge/proof verification and replay consumption precede run_hs2_admitted. The proof-of-work admission policy raises requester cost. Pending/reassembly state has global and per-peer caps, a byte budget and expiry; authenticated relationship policy supplies the separate authorization boundary. Together these provide admission and bounded pre-admission state, satisfying the architectural criterion.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [], "editorial_references": [ "round445.html", "round235.html", "round235-sources.json", "round063.html", "round445-sources.json", "round446.html" ], "qualification": "Credit the configured admission policy, not the existence of a separate control-plane label alone. Receiving, parsing, challenge replies and proof reassembly still consume resources; peer-context creation and fair scheduling need separate qualification. The retained 0x0202 fixture does not prove every carrier integration or a minimum legitimate throughput. Work factor and budgets are local policy, not universal constants. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-PI", "feature": "F15", "stack": "PI", "status": "Y", "reason": "The PRP admission and relationship mechanisms also apply to the selected IP-carried composition: proof/policy checks gate admitted HS2 work, with bounded pending, replay and reassembly state. This is a scoped architectural Yes for that PRP boundary, using the same rule as PN and the other stacks.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [], "editorial_references": [ "round445.html", "round235.html", "round235-sources.json", "round237.html", "round236-result.json", "round445-sources.json", "round446.html" ], "qualification": "The UDP provider finding remains: its 256 shared endpoint slots can be allocated from new tuples before PRP validation, without receive-path rollback on downstream rejection in the inspected version. Thus the protected PRP boundary does not establish protection of outer endpoint admission. Source-derived allocation concern, not an executed outage. Preserve round237 and test cleanup, new arrivals and existing sessions separately; no defect is erased by this change of criterion. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-IP", "feature": "F15", "stack": "IP", "status": "N", "reason": "Bare IP forwards addressed datagrams without a protocol-native admission proof or authenticated authorization gate for allocating forwarding/delivery work. Header validity, TTL/hop limits and finite queues do not supply the required combination. The selected profile excludes added transport admission and stateful firewalls.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round445.html", "round145.html", "round445-sources.json", "round446.html" ], "qualification": "No is scoped to bare IP. It does not deny that IP deployments can add ACLs, policing, SYN cookies, QUIC, scrubbing or other defenses; those mechanisms belong to additional selected layers or policies. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-BP", "feature": "F15", "stack": "BP", "status": "Y", "reason": "The selected TCPCL/TLS composition requires certificate NODE-ID validation before completing session establishment; failed or missing required identity terminates the session. For the subsequent BP acquisition boundary, pinned ION provides configurable aggregate inbound ZCO heap/file occupancy limits. bpContinueAcq reserves space before appending an extent; unavailable space causes waiting or a congestive/discard path. This documents peer admission combined with bounded accounted bundle-storage allocation.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 9174 NODE-ID admission and pinned ION inbound ZCO reservation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4.3", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/library/ion.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod5/ionrc.pod" ], "editorial_references": [ "round549.html", "round549-sources.json" ], "qualification": "Require TLS, local certificate trust and authenticated NODE-ID, with certificates issued only to accepted neighbors; configure finite inbound heap/file budgets. These quotas cover accounted inbound ZCO storage, not all process memory, pending reservation metadata, sockets, concurrent TLS handshakes or CPU. maxAcqInHeap alone merely selects heap versus file and is not the aggregate bound. An authenticated relay may carry unauthorized final sources or exhaust the shared quota. BPSec remains a separate origin/content check. Evidence combines TCPCL normative ordering with ION storage-source behavior; no complete adapter integration, executable composition or overload service guarantee is claimed. No new protocol layer or external limiter is added." }, { "id": "F15-CG", "feature": "F15", "stack": "CG", "status": "Y", "reason": "The selected TCPCL/TLS composition requires certificate NODE-ID validation before completing session establishment; failed or missing required identity terminates the session. For the subsequent BP acquisition boundary, pinned ION provides configurable aggregate inbound ZCO heap/file occupancy limits. bpContinueAcq reserves space before appending an extent; unavailable space causes waiting or a congestive/discard path. This documents peer admission combined with bounded accounted bundle-storage allocation. The same ingress/storage boundary applies before CGR routing; contact-volume prediction is not used as authorization.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 9174 NODE-ID admission and pinned ION inbound ZCO reservation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4.3", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/library/ion.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod5/ionrc.pod" ], "editorial_references": [ "round549.html", "round549-sources.json" ], "qualification": "Require TLS, local certificate trust and authenticated NODE-ID, with certificates issued only to accepted neighbors; configure finite inbound heap/file budgets. These quotas cover accounted inbound ZCO storage, not all process memory, pending reservation metadata, sockets, concurrent TLS handshakes or CPU. maxAcqInHeap alone merely selects heap versus file and is not the aggregate bound. An authenticated relay may carry unauthorized final sources or exhaust the shared quota. BPSec remains a separate origin/content check. Evidence combines TCPCL normative ordering with ION storage-source behavior; no complete adapter integration, executable composition or overload service guarantee is claimed. No new protocol layer or external limiter is added." }, { "id": "F15-LT", "feature": "F15", "stack": "LT", "status": "N", "reason": "The selected LTP/Encapsulation/AOS composition has no selected segment-authentication extension or link-security admission. LTP maintains reception state for incoming segments before the upper-layer bundle can be verified by BPSec. RFC 5326 explicitly identifies queue flooding and storage exhaustion and lists the authentication extension among mitigations. Contact scheduling, engine mapping, retransmission limits and replay handling do not supply the missing authorization gate. The selected ingress therefore does not establish F15 protection before LTP reception/reassembly work.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 5326 receiver state and security considerations; selected LTP/AOS composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html#section-9.1", "https://www.rfc-editor.org/rfc/rfc5326.html#section-8.2", "https://www.rfc-editor.org/rfc/rfc5326.html#section-9.2" ], "editorial_references": [ "round548.html", "round548-sources.json" ], "qualification": "This verdict concerns the declared composition, not every LTP deployment. LTP authentication extensions and secured links exist but are not silently added. BPSec and the separate final-delivery policy remain credited for their bundle/application boundaries; they do not authenticate incoming LTP control or data segments before their processing. No claim that LTP lacks resource limits, nor that a hostile transmitter can access every mission link, is made. No attack, executable AOS binding or whole-stack resource-budget test was run. TCPCL/TLS-based BP and CGR columns are evaluated separately." }, { "id": "F15-LP", "feature": "F15", "stack": "LP", "status": "Y", "reason": "The selected libp2p QUIC transport retains QUIC Retry/address validation and pre-validation expenditure containment. These protect transport admission before libp2p stream/application work. The already documented ConnectionGater supplies an additional authenticated Peer-ID policy boundary; it is not treated as a zero-cost pre-handshake filter.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-8", "https://raw.githubusercontent.com/libp2p/go-libp2p/master/core/connmgr/gater.go" ], "editorial_references": [ "round445.html", "round445-sources.json", "round446.html" ], "qualification": "Credit the native QUIC Retry configuration at the transport boundary, not a new resource-manager deployment. Full-process quotas, protocol handler work and admission of many reachable peers require separate assessment. QUIC reachability validation does not establish Peer-ID authorization. No external firewall or new transport layer is added. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-TO", "feature": "F15", "stack": "TO", "status": "Y", "reason": "The onion-service introduction protocol provides DOS_PARAMS: an explicit token bucket limiting INTRODUCE2 delivery before service-side introduction decryption and rendezvous work. Configure every active introduction circuit with nonzero rate r and burst b, with b at least r, on HSIntro=5 relays. For a fixed set of k compliant introduction circuits, admitted requests over interval t are bounded by the sum of their burst and refill allowances. This is native early admission with bounded admitted work rate, not merely encryption or a response-byte cap.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Tor DOS_PARAMS introduction admission and token-bucket limits", "sources": [ "https://spec.torproject.org/rend-spec/introduction-protocol.html" ], "editorial_references": [ "round540.html", "round540-sources.json" ], "qualification": "Credit is conditional on enabled limits at all active introduction points, including overlap during circuit rotation. Token checking and upstream circuit processing still consume resources; a malicious introduction relay can disregard the policy. The bound does not establish total memory, CPU availability, network-wide protection or fairness to authorized clients. Client authorization remains separate. No PoW extension is selected, no default-on assumption is made, and no runtime or service-floor measurement was performed." }, { "id": "F15-I2", "feature": "F15", "stack": "I2", "status": "Y", "reason": "The pinned Java I2P router checks backlog age and a previous-hop request throttle before queueing participating tunnel-build requests and before expensive build-record decryption. Its LinkedBlockingQueue has a computed capacity clamped between 18 and 192 entries; failed offers drop the request. The worker also drops stale requests or requests observed under excessive job lag before handleRequest reaches cryptographic processing. This provides native early rejection and a bounded pending-work queue at the tunnel-build admission boundary.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned Java I2P BuildHandler admission, bounded queue and RequestThrottler", "sources": [ "https://raw.githubusercontent.com/i2p/i2p.i2p/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/tunnel/pool/BuildHandler.java", "https://raw.githubusercontent.com/i2p/i2p.i2p/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/tunnel/pool/RequestThrottler.java" ], "editorial_references": [ "round541.html", "round541-sources.json" ], "qualification": "Use normal non-test operation with RequestThrottler enabled. Pre-admission parsing, hashing, counters, transport processing and logging still cost resources. The queue bound counts waiting entries, not bytes, executing jobs, every router queue or total process memory. The per-hop counter map is cleared periodically but is not credited as a global identity/state bound; changing identities can undermine per-peer throttling. These checks do not authorize final application users or guarantee service under attack. No NTCP2 handshake protection, whole-router budget, i2pd post-quantum implementation equivalence or runtime throughput result is inferred. The selected NTCP2 composition is retained; no SSU cookie mechanism is imported." }, { "id": "F15-YG", "feature": "F15", "stack": "YG", "status": "N", "reason": "The selected TCP/TLS listener starts a goroutine for every accepted connection and installs per-connection link state before the metadata handshake and peer-key admission. Metadata decoding verifies a signature and then the handler checks pinned keys or the incoming-key allowlist before HandleConn. However, this listener path has no aggregate cap on concurrent pre-admission handlers or link entries. Its six-second I/O deadline and 16-bit metadata length bound each exchange, not the number of simultaneous attempts. The examined composition therefore lacks the combined admission and aggregate pending-state/work bound required for this F15 verdict.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned Yggdrasil listener, metadata admission and TLS link", "sources": [ "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/link.go", "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/version.go", "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/link_tls.go" ], "editorial_references": [ "round545.html", "round545-sources.json" ], "qualification": "This does not deny peer authorization: failed metadata/key admission prevents entry into Ironwood routing and failed connections are closed and removed. Incoming allowlist enforcement is conditional and excludes local links; an empty allowlist is permissive. Signature generation, TLS, parsing, signature verification and connection bookkeeping already cost resources. The deadline is cleared before key-policy checks and is not a whole-handler CPU budget. Remote address/port changes can create distinct link entries; duplicate-link suppression is not a global admission quota. No external firewall, proxy connection limiter or new kernel policy is added. This is a source-level negative for the selected path, not a demonstrated outage, a measured attack threshold or a claim about every Yggdrasil deployment." }, { "id": "F15-CJ", "feature": "F15", "stack": "CJ", "status": "Y", "reason": "In the selected private-peering deployment, InterfaceController requires authenticated incoming handshakes and only installs a returned session as a switch peer. Failed handshakes return no admitted peer. SwitchCore stores interfaces in a fixed array bounded by NumberCompress_INTERFACES and rejects insertion when full; InterfaceController then frees the candidate peer. Authentication failures and non-established transit-directed messages are also rejected before switch dispatch. This combines admission with bounded interface-slot state at the local peer-to-switch boundary.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned cjdns private-peer admission and fixed switch interface array", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/InterfaceController.c", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/SwitchCore.c", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/NumberCompress.h", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/crypto/crypto_auth.rs", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/crypto/crypto_noise.rs", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/rffi/crypto.rs" ], "editorial_references": [ "round544.html", "round544-sources.json" ], "qualification": "Retain private credentials and no public beacon advertisement. This is a bound on switch slots, not on total peer/session memory or handshake CPU. The legacy CryptoAuth branch creates a temporary session before authentication, scans the configured user list, and only rejects a missing/unrecognized authenticator before shared-secret work; a matching authenticator is not yet proof of the secret. The Noise branch performs handshake cryptography before enforcing user authorization. Neither branch is credited as cost-free admission, and no Noise-only cookie defense is needed for this verdict. Lower receive buffers, concurrent attempts, routing discovery and the separate route server are outside the bound. Credential holders may still exhaust capacity. No runtime or availability guarantee." }, { "id": "F15-MQ", "feature": "F15", "stack": "MQ", "status": "Y", "reason": "QUIC supplies address validation with Retry tokens, allowing a server to defer connection state, plus a pre-validation response-byte cap. It also defines bounded cryptographic buffering and stream/data limits. Configured Retry therefore provides an admission gate and expenditure containment at the QUIC setup boundary; multipath does not remove that base mechanism.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-8", "https://www.rfc-editor.org/rfc/rfc9000.html#section-7.5" ], "editorial_references": [ "round445.html", "round445-sources.json", "round446.html" ], "qualification": "Retry must be enabled for the stateless-admission witness. Address validation proves return reachability, not final-peer identity authorization; the selected TLS policy remains separate. The amplification cap alone is not a CPU or global-memory guarantee. Multiple path states, UDP ingress and authorized connection floods remain separate assessment targets. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-SC", "feature": "F15", "stack": "SC", "status": "Y", "reason": "The selected base SCION router validates hop expiry, ingress and the hop-field MAC before normal forwarding. The pinned implementation also preallocates its packet-buffer pool and finite processor, slow-path and forwarding queues. Queue admission uses nonblocking sends that discard packets and return buffers when the relevant queue is full. Invalid hop MACs enter the bounded slow path rather than normal forwarding. Together these provide path-authority rejection and bounded packet-holding state at the border-router dataplane boundary.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "SCION v0.12.0 dataplane admission, packet pool and processing queues", "sources": [ "https://raw.githubusercontent.com/scionproto/scion/v0.12.0/router/dataplane.go" ], "editorial_references": [ "round543.html", "round543-sources.json" ], "qualification": "This closes the earlier documentary gap with explicit pool and queue bounds, not with path validity alone. For I configured interfaces, batch size B, P processors, S slow-path processors and processor queue capacity Q, the pool has 3*I*B+(P+S)*(Q+1) packet buffers of 9000 bytes, plus packet structures and other overhead. These are configured implementation bounds, not a total-process memory ceiling. Parsing, hashing, hop-MAC checking, metrics and possible SCMP response generation still cost CPU; kernel socket queues, control-plane state and logging are outside this bound. Path authority is reusable and does not authenticate an individual sender or authorize the destination application. Valid-path floods can consume all processing capacity. No EPIC, COLIBRI, extra policing, service-floor guarantee or runtime test is credited." }, { "id": "F15-RT", "feature": "F15", "stack": "RT", "status": "Y", "reason": "The selected secret-IFAC gate precedes normal transport processing. InboundQueues.put rejects entries at configured per-class limits; the default queued mode bounds pending transport work. Together these provide early admission rejection and bounded queue state under the revised architectural F15.", "method": "Pinned source ordering and native admission-boundary analysis; no execution", "source_label": "Reticulum 1.5.5 Transport.py: InboundQueues, queue initialization and preprocess_inbound", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round447-sources.json", "round447.html" ], "qualification": "Credit the queued configuration with finite limits. Parsing/authentication still cost CPU before queue insertion, and preprocessing dictionaries are not all bounded by these queues. No whole-process memory bound, scheduling guarantee or minimum service under attack is established. Earlier serial experiments retain their original scope." }, { "id": "F15-NS", "feature": "F15", "stack": "NS", "status": "Y", "reason": "The selected nostr-rs-relay has a configurable author whitelist that rejects unauthorized events before repository writes and broadcast. Its persistence channel has a configured finite event capacity and applies backpressure when full. Select a finite whitelist, disable pay-to-relay, and set positive EVENT/WebSocket size limits and event_persist_buffer. This combines authorization before storage work with a bounded waiting channel at the event-persistence boundary.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned nostr-rs-relay author admission and bounded persistence queue", "sources": [ "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/db.rs", "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/server.rs", "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/config.toml" ], "editorial_references": [ "round542.html", "round542-sources.json" ], "qualification": "Apply these settings to both selected relays. Signature validation and parsing precede whitelist rejection and still consume CPU. A full channel suspends senders; pending sends and per-connection state are outside the channel-capacity bound. This is not a bound on total relay memory, connection count, subscription/query work or TLS cost. Admitted authors can still exhaust resources. Keep the selected in-memory repository and no-retention settings. No NIP-42, payment service, extra proxy defense or runtime availability result is credited." }, { "id": "F15-MT", "feature": "F15", "stack": "MT", "status": "Y", "reason": "The selected firmware bounds fromRadioQueue to four packets; overflow discards and releases the oldest. Before stateful routing filters and local dispatch, passesRoutingAuthGate rejects signature-policy failures. STRICT rejects unsigned non-PKI packets and invalid signatures. This combines bounded waiting-state with rejection before retry/history updates and decoded local delivery.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned Meshtastic Router receive queue and signature-policy gate", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp" ], "editorial_references": [ "round546.html", "round546-sources.json" ], "qualification": "Credit the receive queue, not total memory: Portduino uses a dynamic packet pool. Decryption, signature verification, key lookup and bootstrap checks precede rejection and cost CPU. PKI packets follow their authenticated-decryption path without requiring an additional signature. First-contact NodeInfo can bootstrap trust; STRICT is not an authorized-person whitelist. Ordinary CLIENT/ALL still relays eligible opaque traffic, including unknown channels; that path is not claimed to reject every unauthorized sender. Do not substitute the separate KNOWN_ONLY witness. Flooding can displace legitimate queued packets and saturate processing or airtime. No fairness, service-floor, whole-device memory bound or runtime result is asserted." }, { "id": "F15-GN", "feature": "F15", "stack": "GN", "status": "Y", "reason": "In the selected GNUnet 0.20.0 legacy UDP composition, reassembly retains at most 128 sender-address contexts with three message contexts each, evicting old contexts when limits are reached. Message length is represented by a 16-bit field and checked before allocation. CORE rejects data unless its key exchange is established, checks the HMAC before payload decryption, and rejects duplicate/old messages before service dispatch. These native mechanisms combine bounded unauthenticated reassembly state with cryptographic admission to downstream processing.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "GNUnet 0.20.0 UDP defragmentation limits and CORE authentication gate", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round550.html", "round550-sources.json" ], "qualification": "The limits describe retained reassembly state, not an exact process-memory ceiling: allocation precedes eviction, so temporary extra contexts exist. Fragment handling, acknowledgments, session/key-exchange work, HMAC verification, logging and other queues remain outside this bound. CORE authentication identifies a cryptographic neighbor; it is not a final CADET application allowlist. An admitted neighbor can generate valid traffic, and changing sender addresses can evict legitimate partial messages. No fairness, service-floor or CPU-rate guarantee is asserted. Keep legacy UDP and the pinned release; no TNG, external limiter, complete deployment test or final-receiver policy is imported." }, { "id": "F15-ND", "feature": "F15", "stack": "ND", "status": "N", "reason": "In the selected NFD 24.07 forwarding path, a well-formed Interest with a fresh name/nonce passes hop-limit, localhost-scope and duplicate checks and reaches PIT insertion before content-store lookup and strategy handling. The pinned Pit::findOrInsert creates a name-tree/PIT entry without an admission proof or a configured aggregate allocation quota on that path. Data signature verification at the consumer does not protect this request-state boundary. The selected composition therefore lacks the F15 combination of admission/early rejection with bounded pre-admission state or work.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "NFD PIT allocation ordering and RFC 8966 base-Babel neighbor admission", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/forwarder.cpp", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/table/pit.cpp" ], "editorial_references": [ "round538.html", "round538-sources.json" ], "qualification": "The No concerns the declared direct-Ethernet NFD composition and its normal-interest processing, not every NDN research defense or alternative implementation. Duplicate suppression, scope validation, packet-size constraints, timers and finite hardware are useful but do not bound the aggregate creation of distinct pending requests before downstream strategy decisions. The selected multicast strategy is not a pre-PIT authorization gate. No signed-consumer policy, resource-admission extension or external firewall is added. This source trace does not measure attack throughput, prove a successful service outage or claim that every arriving Interest is forwarded. Network-capacity authorization remains F26. No runtime experiment." }, { "id": "F15-AX", "feature": "F15", "stack": "AX", "status": "N", "reason": "The selected classic AX.25/NET/ROM circuits and announcements use callsigns and protocol state without an authenticated admission or work-proof gate. Window/retry controls and packet length checks are not authorization-based containment of unsolicited circuit/routing work.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round445.html", "round145.html", "round443.html", "round445-sources.json", "round446.html" ], "qualification": "No applies to the declared native composition. Administrative port setup and radio licensing are not proof carried by incoming requests; no added link security, IP firewall or BBS login is credited. The external parser security review in E02 remains Yes. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-BA", "feature": "F15", "stack": "BA", "status": "N", "reason": "The selected BATMAN_IV native Ethernet service has no authenticated admission or work-proof boundary for incoming mesh participants. Protocol duplicate suppression, hop limits and queue bounds do not alone provide the required admission-plus-containment mechanism.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [ "https://www.open-mesh.org/projects/batman-adv/wiki" ], "editorial_references": [ "round445.html", "round145.html", "round118.html", "round445-sources.json", "round446.html" ], "qualification": "No applies to the profile without WPA, MACsec, VPN admission or IP filtering. It does not classify a deployment that adds those layers, nor claim that every malformed frame consumes unlimited memory. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-BL", "feature": "F15", "stack": "BL", "status": "N", "reason": "The selected IPv6/Babel composition has no Babel-MAC or Babel-DTLS admission layer. RFC 8966 requires creation of neighbor state after a Hello from a previously unknown neighbor, while its security section explains that base Babel trusts unauthenticated UDP information. Link-local scope limits remote injection but does not establish admission or a resource budget against on-link senders. The selected prefix filters constrain accepted routes, not the preceding per-neighbor control work; ordinary IP datagrams also lack an added admission layer.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "NFD PIT allocation ordering and RFC 8966 base-Babel neighbor admission", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.4", "https://www.rfc-editor.org/rfc/rfc8966.html#section-6", "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-C" ], "editorial_references": [ "round538.html", "round538-sources.json" ], "qualification": "This No is scoped to the declared base-Babel profile, including its configured route filters. It does not deny malformed-packet rejection, loop prevention, timers or output pacing. Those mechanisms do not provide the required combined protected boundary for unauthorized input. An access-controlled or quota-enforced implementation needs its own explicit selected policy and bounds. RFC 8967/8968 authentication extensions could change the composition but are deliberately excluded here; no claim is made that authentication alone would settle resource protection. Neither exploitability nor a quantitative service floor was tested. F26 remains separate." }, { "id": "F15-RI", "feature": "F15", "stack": "RI", "status": "Y", "reason": "The selected DTLS 1.3 layer supplies a native stateless-cookie admission mechanism. Configure the receiving leaf's DTLS server to issue HelloRetryRequest and retain no pending handshake state until the returned cookie verifies. Cookie authentication binds the client's address and a compact transcript representation under a server secret. This defers persistent handshake allocation and subsequent handshake/application processing until return-routability admission, satisfying F15 at that identified boundary.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "DTLS 1.3 stateless-cookie handshake admission and TLS transcript cookie", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html#section-5.1", "https://www.rfc-editor.org/rfc/rfc9147.html#section-11", "https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.2" ], "editorial_references": [ "round539.html", "round539-sources.json" ], "qualification": "This is an explicit cookie-enabled architectural witness, not a claim about every DTLS default or a qualified integrated leaf executable. Parsing, transcript hashing and a bounded-size keyed cookie operation still occur before admission; restrained cookie processing is required by RFC 9147 section 11. No per-request pending-handshake table is credited before validation. Fragment reassembly, lower-layer queues and 6LoWPAN/RPL processing are outside this protected boundary and require their own limits. Cookies do not establish PSK authorization and do not stop attacks from valid reachable addresses. The selected external-PSK handshake and final-peer policy remain necessary after admission. No CPU service floor, radio-capacity protection, full-process quota, runtime result or D01 implementation qualification is inferred." }, { "id": "F15-HP", "feature": "F15", "stack": "HP", "status": "Y", "reason": "HIPv2 defines responder puzzles, precomputable R1 replies and delayed association-state creation. Puzzle verification precedes expensive continuation of the base exchange; responder policy can reject requests. This directly addresses unsolicited setup work and state at the HIP responder boundary.", "method": "Primary specification and source analysis; experiments are complementary", "source_label": "Selected-profile primary sources and retained source traces; owner-approved F15 reformulation", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round445.html", "round445-sources.json", "round446.html" ], "qualification": "Credit RFC 7401 sections 4.1.1–4.1.5 and 6.6 ordering, with a nontrivial puzzle policy when used for work admission. Initial reception and R1 replies have costs; solved puzzles are not application authorization. No complete HIPv2 build, protection of all IP ingress, or measured availability is inferred. Quantitative service preservation under bounded attacks is complementary validation, not a prerequisite for this architectural criterion. Historical round145 and later experimental records retain their original scope; they are not new pass/fail results under this definition. F15 now assesses CPU/state protection only. Network-capacity authorization is separate in F26; a response-byte cap by itself does not establish this F15 result." }, { "id": "F15-CX", "feature": "F15", "stack": "CX", "status": "N", "reason": "The selected CCNx composition uses CRC32C Interests without authenticated requester admission. Athena checks hop limit and its content store, then calls athenaPIT_AddInterest before FIB forwarding. The PIT has a capacity check and expiration cleanup, but these do not distinguish authorized requests: syntactically valid new Interests can consume available entries. Content signatures verified by consumers do not protect this Interest-admission boundary. The selected path therefore does not establish the combined authorization/rejection and bounded-state protection required by F15.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned Athena Interest processing and pending-Interest capacity checks", "sources": [ "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena.c", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_PIT.c" ], "editorial_references": [ "round547.html", "round547-sources.json" ], "qualification": "Credit the existing capacity mechanism as resource management, not absent functionality. Key construction and table lookup precede its capacity check. A ContentObjectHashRestriction can add a second nameless entry after the single check; existing entries can extend expiration or aggregate ingress state. Thus the nominal entry capacity is not claimed as an exact whole-PIT byte bound. Hop limits, expiry and duplicate aggregation are useful but do not authorize consumers. No Interest-authentication extension, access-control wrapper or external rate limiter is added. This documentary negative does not demonstrate an outage or measure attack cost." }, { "id": "F15-LI", "feature": "F15", "stack": "LI", "status": "Y", "reason": "RFC 9301 requires authenticated Map-Register processing and acceptance only of prefixes configured for the registering ETR. A bounded registration configuration uses a fixed set of ETR credentials and exact EID prefixes, ordinary replacement registrations and no merge requests. Each record has an eight-bit Locator Count. This provides a documentary bound on admitted prefix/locator records together with rejection of unauthorized registrations before mapping publication. The bound is a configuration inference, not a measured implementation property.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 9301 authenticated Map-Register and configured prefix admission", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.2", "https://www.rfc-editor.org/rfc/rfc9301.html#section-5.6" ], "editorial_references": [ "round551.html", "round551-sources.json" ], "qualification": "Credit only registered mapping records in this configuration. Do not infer a bound on total server memory, parsing/HMAC cost, replay-tracking metadata, request queues or logs. Retain fixed credential/xTR provisioning; dynamic enrollment and merge registrations are outside the witness. A valid credential holder can still consume processing or replay-state resources. Open Map-Requests and data-plane traffic are not protected by registration authentication. Rate limits elsewhere in RFC 9301 are not used as a global CPU ceiling. No LISP-SEC, external firewall, runtime test or public-Internet deployment qualification is imported." }, { "id": "F15-IL", "feature": "F15", "stack": "IL", "status": "Y", "reason": "For existing ILNPv6 sessions, RFC 6743 requires the correct Nonce Destination Option before a Locator Update is accepted and passed to ICMP processing. An accepted update replaces the correspondent's previous locator set. The nonzero eight-bit locator count bounds each replacement list to 255 entries. This supplies early rejection of forged off-path updates and a bounded replacement-state effect; repeated updates do not append successive advertised lists indefinitely.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 6743 nonce admission and replacement of bounded locator-update lists", "sources": [ "https://www.rfc-editor.org/rfc/rfc6743.html#section-6", "https://www.rfc-editor.org/rfc/rfc6743.html#section-2", "https://www.rfc-editor.org/rfc/rfc6743.html#section-4", "https://www.rfc-editor.org/rfc/rfc6741.html#section-11" ], "editorial_references": [ "round552.html", "round552-sources.json" ], "qualification": "Credit only the Locator Update boundary for an existing correspondent and unpredictable established nonce. This is not an aggregate ILCC, TCP backlog or whole-process memory bound. Parsing, nonce lookup and optional logging still consume resources; temporary old/new lists and other locator-learning paths are not measured. The nonce is visible to an on-path observer and does not provide strong peer identity. A party knowing it can issue repeated valid updates. Initial session admission, SYN floods, on-path attackers and rate guarantees are outside this Yes. No IPsec, CGA, external limiter or runtime qualification is imported." }, { "id": "F15-TS", "feature": "F15", "stack": "TS", "status": "Y", "reason": "The selected WireGuard receiver validates MAC1 and, under load, checks source-bound cookies and applies an IP rate limit before consuming the handshake. Unknown peers do not create authorized sessions.", "method": "Pinned dependency/source inspection and official documentation; no runtime test", "source_label": "Tailscale go.mod and selected wireguard-go dependency", "sources": [ "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/constants.go" ], "editorial_references": [ "round587.html", "round587-sources.json" ], "qualification": "Credits the WireGuard handshake boundary. Receiving, parsing and MAC work remain; an under-load cookie reply has a cost. It does not protect the incoming link or certify the coordinator, DERP TLS admission, or a service floor against authorized attackers." }, { "id": "F15-RA", "feature": "F15", "stack": "RA", "status": "?", "reason": "The selected AuthSSH2 responder decodes authentication options and allocates an SSH2SecurityContext before completing peer authentication. It loads pinned keys, generates DH keys and computes the shared secret before the challenge-response completes. Missing peer keys reject unknown names, but an asserted known name is not yet proof of possession. This locates pre-authentication CPU and state costs; it does not establish the rate or number of attempts that can reach this boundary through the selected lower DIFs.", "method": "Pinned responder authentication ordering; lower admission bounds unresolved", "source_label": "IRATI AuthSSH2 responder", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc" ], "editorial_references": [ "round669.html", "round672.html" ], "qualification": "Trace lower-flow admission, concurrent enrollment/context limits, queues and cleanup for attempts claiming a configured peer name. Identify a selected policy that bounds pre-authentication CPU/state or defers expensive work until admission. Per-session duplicate-context rejection and missing-key rejection alone do not establish an aggregate bound. Do not infer vulnerability or protection from this source ordering alone." }, { "id": "F16-PN", "feature": "F16", "stack": "PN", "status": "Y", "reason": "For the final-peer access task, authenticated relationship policy is the native authority. Lifecycle sections 4–5 invalidate exclusively derived objects on revocation and forbid reusing the revoked epoch; sections 13 and 17 reject stale generations and unauthenticated mutation. This credits the specified protected relationship mechanism, not implementation conformance or protection of unrelated host services.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [], "editorial_references": [ "index.html#round063" ], "qualification": "Bind the local final-peer allowlist to the actual selected carrier and E2E receiver; exercise denied identities, all active paths, queued-but-undelivered work, restart, stale epochs and renewed authorization. Working-draft lifecycle interoperability and full cutover execution remain unqualified." }, { "id": "F16-PI", "feature": "F16", "stack": "PI", "status": "Y", "reason": "For the final-peer access task, authenticated relationship policy is the native authority. Lifecycle sections 4–5 invalidate exclusively derived objects on revocation and forbid reusing the revoked epoch; sections 13 and 17 reject stale generations and unauthenticated mutation. This credits the specified protected relationship mechanism, not implementation conformance or protection of unrelated host services.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [], "editorial_references": [ "index.html#round063" ], "qualification": "Bind the local final-peer allowlist to the actual selected carrier and E2E receiver; exercise denied identities, all active paths, queued-but-undelivered work, restart, stale epochs and renewed authorization. Working-draft lifecycle interoperability and full cutover execution remain unqualified." }, { "id": "F16-IP", "feature": "F16", "stack": "IP", "status": "N", "reason": "The selected IP datagram/ICMP stack has no cryptographic final-peer admission mechanism. Prefix or address routing decisions cannot enforce the identity allowlist and revocation task. An external ACL/firewall or added security layer is outside this column; this is a scope-based No, not a claim that IP applications cannot authorize users.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-BP", "feature": "F16", "stack": "BP", "status": "Y", "reason": "A bounded native configuration closes the unmatched-source gap without an application filter. Enable ION BSL and install two APPOUT wildcard-source/wildcard-destination verifier rules: require BIB-HMAC-SHA2 over primary and payload, using the locally configured active pairwise key, with delete_bundle on failure. All accepted source EIDs match the policy, so inventing an unlisted source cannot bypass it. The rule creates a required security operation before any matching BIB is found; absent BIBs leave security-block number zero, whose canonical-block lookup fails. Invalid or absent results cause non-success finalization and mark the bundle insecure; ION abandons it before delivery. Query errors also return before delivery. The remote key holder is the only authorized remote sender in this witness; keys are not given to transit. Revocation is a completed cold cutover: stop receiver and consumers, retire all old delivery/fragment/storage state from the active instance, replace the key with an independently fresh secret shared only with the newly authorized sender, then resume. Old in-flight bundles fail the new key; old admitted queues and callbacks cannot survive the fresh instance. Authorized new traffic can pass the same native verifier. F16 explicitly allows administrative teardown/restart. This is a capability proof for one authorized sender at a time, not a default ION behavior, live multi-peer revocation, claimed-EID identity proof, or preservation of queued data. F21 is unchanged.", "method": "Pinned native-policy/control-flow proof and explicit administrative cutover; no ION execution", "source_label": "ION BSL APPOUT gate and BSL wildcard policy, missing-block failure, fixed local key and delete action", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bsl/bsl.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/policy_provider/SamplePolicyProvider.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/backend/PublicInterfaceImpl.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/backend/SecurityContext.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/security_context/BIB_HMAC_SHA2.c" ], "editorial_references": [ "round137-policy.json", "round137-sources.json", "round137.html" ], "qualification": "Run the supplied policy in the pinned BSL-enabled ION build with operationally generated secret keys (not test-vector mode). Verify legitimate nonempty payload delivery, absent/invalid BIBs on each target, false source EIDs without the key, malformed blocks, fragmentation, and old bundles in flight/queued during a completed cold cutover. Observe no post-cutover old callback and successful newly authorized delivery. Check fail-closed startup and ensure no retired queues, fragments or old key registry are restored. No such execution occurred in this round." }, { "id": "F16-CG", "feature": "F16", "stack": "CG", "status": "Y", "reason": "The selected pinned ION BPv7 delivery path calls BSL at APPOUT before deliverBundle, irrespective of whether ingress used TCPCL or LTP and irrespective of CGR route selection. Rechecked BSL source creates mandatory verifier operations from wildcard-source rules, treats missing/invalid required BIBs as failures, and marks delete_bundle failures insecure; ION abandons insecure bundles before delivery. Select the explicit round137 two-target policy: mandatory primary/payload BIB-HMAC-SHA2 verification with a locally fixed secret held only by one authorized final peer and the receiver. Revocation is a completed shutdown, fresh empty bundle/fragment/delivery state and independently fresh pairwise key before restart. New authorized service remains possible; old in-flight bundles fail the new key. This is a separately traced final-delivery mechanism for this column, not an inherited Secure DTN verdict.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bsl/bsl.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/policy_provider/SamplePolicyProvider.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/backend/SecurityContext.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/security_context/BIB_HMAC_SHA2.c" ], "editorial_references": [ "round137-policy.json", "round228-sources.json" ], "qualification": "Documentary capability proof with optional native BSL enabled and policy loaded before exposure. One authorized remote key holder at a time; no live multi-peer revocation, retained queued data, application filter, source-EID identity proof or DoS guarantee. F21 keeps its separate exact-source witness. BCB protection remains required. Parser/runtime tests, fail-closed startup, fragmentation, active/queued cutover and complete selected convergence-layer integration still need execution; no full-stack implementation availability is inferred." }, { "id": "F16-LT", "feature": "F16", "stack": "LT", "status": "Y", "reason": "The selected pinned ION BPv7 delivery path calls BSL at APPOUT before deliverBundle, irrespective of whether ingress used TCPCL or LTP and irrespective of CGR route selection. Rechecked BSL source creates mandatory verifier operations from wildcard-source rules, treats missing/invalid required BIBs as failures, and marks delete_bundle failures insecure; ION abandons insecure bundles before delivery. Select the explicit round137 two-target policy: mandatory primary/payload BIB-HMAC-SHA2 verification with a locally fixed secret held only by one authorized final peer and the receiver. Revocation is a completed shutdown, fresh empty bundle/fragment/delivery state and independently fresh pairwise key before restart. New authorized service remains possible; old in-flight bundles fail the new key. This is a separately traced final-delivery mechanism for this column, not an inherited Secure DTN verdict.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbpP.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bsl/bsl.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/policy_provider/SamplePolicyProvider.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/backend/SecurityContext.c", "https://github.com/NASA-AMMOS/BSL/blob/468db9ba29ad4b3ca90bf77ef0879c1ecc85121d/src/security_context/BIB_HMAC_SHA2.c" ], "editorial_references": [ "round137-policy.json", "round228-sources.json" ], "qualification": "Documentary capability proof with optional native BSL enabled and policy loaded before exposure. One authorized remote key holder at a time; no live multi-peer revocation, retained queued data, application filter, source-EID identity proof or DoS guarantee. F21 keeps its separate exact-source witness. BCB protection remains required. Parser/runtime tests, fail-closed startup, fragmentation, active/queued cutover and complete selected convergence-layer integration still need execution; no full-stack implementation availability is inferred." }, { "id": "F16-LP", "feature": "F16", "stack": "LP", "status": "Y", "reason": "A configured ConnectionGater rejects authenticated Peer IDs through InterceptSecured before admission. A coordinated cutover first changes the allowlist, then closes all connections to the revoked Peer ID; the declared no-resumption profile prevents bypass through old tickets. Gate-only updates are insufficient. This is a composition of native policy and connection APIs, not an application login protocol.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://raw.githubusercontent.com/libp2p/go-libp2p/master/core/connmgr/gater.go", "https://raw.githubusercontent.com/libp2p/go-libp2p/master/core/network/network.go" ], "editorial_references": [], "qualification": "Pin and test the chosen go-libp2p QUIC binding: serialize policy change and teardown with concurrent inbound/outbound dials, cancel pending deliveries, enumerate every connection, and verify reconnect rejection after cutover." }, { "id": "F16-TO", "feature": "F16", "stack": "TO", "status": "Y", "reason": "The declared onion-v3 client-authorization profile restricts access using client keys. The Tor Project documents revocation by removing the client authorization file and restarting Tor. The task permits this interruption; editing a file without restart is not credited. Keep authorization enabled by retaining at least one valid entry, or disable the service when the allowlist is empty.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://community.torproject.org/onion-services/advanced/client-auth/" ], "editorial_references": [], "qualification": "Test the documented restart cutover with cached descriptors and old circuits, verify authorized-client recovery and denied-client failure, and test the empty-allowlist case without accidentally making the service public." }, { "id": "F16-I2", "feature": "F16", "stack": "I2", "status": "N", "reason": "The declared destination/tunnel profile does not include a final-sender allowlist enforced for all delivered payload. I2CP authenticates local client access to a router, not the remote sender reaching the Destination. Streaming access lists or application authentication would change the selected composition.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://www.i2p.net/en/docs/specs/i2cp/" ], "editorial_references": [], "qualification": "" }, { "id": "F16-YG", "feature": "F16", "stack": "YG", "status": "N", "reason": "Reassessed under the final-peer task in round 063: the native IPv6 endpoint remains reachable from routed peers; direct-peering restrictions do not enforce a final-source allowlist. The official FAQ recommends a host IPv6 firewall for incoming access. No application-operation policy is being tested.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/faq.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-CJ", "feature": "F16", "stack": "CJ", "status": "N", "reason": "The selected ordinary cjdns IPv6 profile authenticates network identities and can restrict direct peer connections. Direct peering credentials do not enforce a final-source allowlist for packets routed through an authorized neighbor to the host. No final-host packet filter is selected; end-to-end identity binding alone is not authorization.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md", "https://github.com/cjdelisle/cjdns/blob/master/doc/security_specification.md" ], "editorial_references": [], "qualification": "" }, { "id": "F16-MQ", "feature": "F16", "stack": "MQ", "status": "Y", "reason": "The existing conditional Yes is supplemented by a native TLS callback witness: a final public-key pin gates the unchanged OpenSSL verifier; a valid fixture certificate outside that pin is rejected with access_denied. Revoking the allowed key and explicitly closing both active connections stops subsequent transport delivery to the test application; a fresh handshake with that revoked key is denied.", "method": "Simulated two-connection revocation and exact TLS rejection controls", "source_label": "Pinned picoquic/Picotls libraries and executed editorial policy harness", "sources": [ "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquic/tls_api.c" ], "editorial_references": [ "round296-runtime.json", "round296-sources.json", "round296_policy.c" ], "qualification": "A retained policy and application integration are required; QUIC does not automatically supply a final-key policy manager. The witness covers two connections of one identity in separate contexts over simulated links. It does not show selective multi-identity revocation, thread safety or cancellation of work already queued inside an application. No new public implementation or security certification is claimed." }, { "id": "F16-SC", "feature": "F16", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP profile has no authenticated final-client admission layer. Hop-field MACs authorize forwarding paths, not the receiving service's participant allowlist. AS path policy cannot substitute for final-peer authorization and revocation.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-RT", "feature": "F16", "stack": "RT", "status": "N", "reason": "In Reticulum 1.5.5, Link.identify provides verified identity and request handlers can enforce an allowed identity list. The ordinary Link packet branch nevertheless dispatches decrypted data to its callback without that request-handler allowlist. The selected profile therefore lacks a native gate covering all payload delivery; adding application packet filtering is outside this F16 task. Shared IFAC credentials do not fix the final-peer boundary.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [], "qualification": "" }, { "id": "F16-NS", "feature": "F16", "stack": "NS", "status": "N", "reason": "Basic NIP-01 authenticates event authorship but does not authenticate every reader or live publishing client to the relay. It cannot enforce the complete final-peer read/write access task from event signatures alone. NIP-42 is an additional client-authentication extension expressly excluded from this column.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/42.md", "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F16-MT", "feature": "F16", "stack": "MT", "status": "Y", "reason": "Select a headless CLIENT with KNOWN_ONLY and STRICT, a clean locally provisioned database containing only authorized User records and confirmed full public keys, trusted local serial administration, no remote administrative grants to ordinary peers, and store-forward disabled. KNOWN_ONLY rejects an unknown sender before decrypt/first-contact learning; STRICT then requires a valid signature or authenticated PKI payload for admitted records. Thus a known node number alone is insufficient: an impostor must pass the retained full-key check. For bounded revocation, persist the revoked node number in ignore_incoming while retaining its key binding, verify saved policy, then restart before declaring cutover. Ignore checks precede admission; restart discards volatile radio, deferred-dispatch and phone queues, and surviving authorized records remain usable. A new sender number still fails KNOWN_ONLY. This uses native controls and the restart allowed by F16, not an external firewall or added application authentication. It is not the default ALL policy, zero-interruption revocation, a generic arbitrary-NodeDB allowlist, or revocation of data already delivered.", "method": "Pinned control-flow and bounded administrative composition analysis; no firmware execution", "source_label": "Meshtastic 8e6a88d Router, NodeDB, MeshService and AdminModule", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NodeDB.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/MeshService.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/AdminModule.cpp" ], "editorial_references": [ "round122-sources.json" ], "qualification": "Execute with two authorized peers and one unlisted peer on the pinned headless build. Verify full-key provisioning and effective KNOWN_ONLY/STRICT; test forged known numbers, changed keys, unknown self-signed NodeInfo and valid authorized payload. Queue a revoked-peer packet, persist/read back ignore_incoming, restart, then prove no old queued or new revoked payload is delivered while the surviving peer succeeds. Exclude display/message-history modules and remote administration from this witness; store-forward stays off. Failed persistence or incomplete restart is not a completed cutover. No runtime qualification performed." }, { "id": "F16-GN", "feature": "F16", "stack": "GN", "status": "Y", "reason": "A constructive native configuration resolves F16 without treating an application message validator as an admission gate. The dedicated receiver opens no CADET listening port and creates bidirectional channels only toward locally authorized peer public keys. channel_create passes the exact destination to the service; the channel belongs to that destination tunnel, whose key derivation includes its public identity. Validated plaintext is looked up in the channel map of that tunnel, not a global channel-number namespace. Unsolicited incoming channels at unopened ports remain unbound; the native plaintext-data handler drops data when neither local owner nor destination client exists. Thus an authorized remote peer can send payload on the locally initiated channel, while another peer cannot acquire the same local delivery path merely by choosing the same port or channel number. For revocation, stop the consuming clients and local CADET service, wait for termination, discard the old volatile delivery/channel state, and restart with no listening ports and channels only to the revised authorized set. This completed cutover removes active and queued delivery authority; authorized communication resumes on new channels. F16 permits administrative restart and does not require remote initiation or uninterrupted availability. This does not establish a general incoming-server allowlist, live channel-revocation safety or a tested GNUnet deployment. The earlier connect-callback lifetime and optional MQ-validator limitations remain valid but are not used by this witness.", "method": "Constructive native configuration and pinned source-path review; no daemon/security execution", "source_label": "GNUnet 0.20.0 release: cadet_api.c, service channel/tunnel/client implementation and channel header", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [ "round141-sources.json", "round141-policy.json", "round141.html" ], "qualification": "Run an isolated pinned GNUnet deployment with two authorized and one unauthorized remote peer through a relay. Verify reverse-direction delivery over locally initiated channels, unopened-port denial, tunnel-local channel-number isolation, pre-cutover queued traffic, complete consumer/service restart, denial of the removed peer and restored service from the remaining peer. No daemon, cryptographic attack, IPC race, restart or end-to-end delivery experiment was executed in this round." }, { "id": "F16-ND", "feature": "F16", "stack": "ND", "status": "N", "reason": "The selected ordinary Interest path accepts unsigned requests: onIncomingInterest checks scope, hop limit and loops, then dispatches to the CS or forwarding strategy. It has no authenticated final-consumer allowlist before forwarding payload to a producer application. Data-signature validation authenticates returned objects, not requesting consumers. Management authorization and optional application Signed Interest policies do not supply the selected native final-peer admission/revocation contract.", "method": "Pinned source and specification analysis; no execution", "source_label": "NFD 24.07 forwarding pipeline and NDN v0.3 Interest format", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp", "https://docs.named-data.net/NDN-packet-spec/0.3/interest.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-AX", "feature": "F16", "stack": "AX", "status": "N", "reason": "Callsign-based circuit acceptance lacks cryptographic final-peer credentials; disconnecting a circuit cannot supply the required final-key admission policy.", "method": "Primary-document analysis and bounded architectural inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F16-BA", "feature": "F16", "stack": "BA", "status": "N", "reason": "Native Ethernet identifiers are not cryptographic final-peer credentials. The selected batman-adv service cannot enforce the required final-key admission and revocation; additional MACsec, endpoint security and application authentication are excluded.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-BL", "feature": "F16", "stack": "BL", "status": "N", "reason": "This profile has no cryptographically authenticated final-peer admission primitive. Babel neighbor trust and route selection cannot implement the required final-key allowlist and revocation; IPsec and application authentication are excluded.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-RI", "feature": "F16", "stack": "RI", "status": "Y", "reason": "The selected DTLS profile uses distinct external PSKs for final peers, no tickets and no early data. A local accepted-PSK policy gates establishment. A controlled stop, removal of the revoked peer's PSK and disposal of all live association state can enforce revocation before the service admits traffic again.", "method": "Documentary native-policy composition; no cutover or isolation experiment", "source_label": "HIP policy and ESP teardown; DTLS/TLS external-PSK and closure specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html#section-5.10", "https://www.rfc-editor.org/rfc/rfc8446.html#section-6.1" ], "editorial_references": [ "round268-sources.json" ], "qualification": "The cutover must stop delivery and discard pending handshakes, traffic keys, CID mappings and queued undelivered plaintext, then restart from the updated credential store. Merely deleting the PSK or sending a write-side close_notify does not invalidate every established receive path. This is a native-policy administrative witness, not a default immediate-revocation guarantee or an executed test." }, { "id": "F16-HP", "feature": "F16", "stack": "HP", "status": "Y", "reason": "A selected-peer HIP ACL can gate authenticated association admission before ESP user-data delivery. Revocation can replace that policy and drop every HIP association for the revoked HI; RFC 7402 section 6.7 requires dropping the associated ESP SAs.", "method": "Documentary native-policy composition; no cutover or isolation experiment", "source_label": "HIP policy and ESP teardown; DTLS/TLS external-PSK and closure specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html#section-6.7" ], "editorial_references": [ "round268-sources.json" ], "qualification": "Completed-cutover witness: pause admission/delivery, remove the HI from allowed peers, discard active and pending HIP/ESP state and queued undelivered data, then reopen under the new policy. An ACL edit alone is insufficient. A controlled restart must clear installed SAs too, not merely restart a control daemon. No runtime race audit was executed." }, { "id": "F16-CX", "feature": "F16", "stack": "CX", "status": "N", "reason": "The selected CRC32C Interests do not authenticate the requester. ECDSA-signed Content Objects authenticate their producer, not the consumers allowed to retrieve them; the selected profile therefore cannot enforce the criterion of cryptographic final-peer admission and revocation.", "method": "Selected-profile documentary review; no runtime test", "source_label": "CCNx 1.0 semantics and selected UDP/CRC32C Interest profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-8", "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round258-sources.json" ], "qualification": "CCNx can carry other validation mechanisms, but no authenticated-consumer policy is selected here. Name restrictions and producer KeyId restrictions are not requester authorization." }, { "id": "F16-LI", "feature": "F16", "stack": "LI", "status": "N", "reason": "Mapping-registration authentication admits mapping updates, not cryptographic final peers at the receiving application. EID/RLOC checks and segmentation cannot meet this criterion without the absent final-peer identity/admission mechanism.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-IL", "feature": "F16", "stack": "IL", "status": "N", "reason": "Session nonces resist off-path injection but do not authenticate and authorize cryptographic final peers. The profile excludes IPsec and application authentication, so the required cryptographic admission and revocation policy is unavailable.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F16-TS", "feature": "F16", "stack": "TS", "status": "Y", "reason": "Selected network grants constrain peer access and are applied by the Tailscale clients. An external perimeter firewall is not required for this policy enforcement.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/features/access-control" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "F16-RA", "feature": "F16", "stack": "RA", "status": "Y", "reason": "The selected two-host upper DIF authenticates remote endpoint-host IPCPs against locally pinned keys. AuthSSH2 fails when the asserted peer has no configured public key. Revocation can use a completed administrative stop and restart: remove the revoked peer key, close affected application flows and stop the old endpoint IPCPs before restoring service with the remaining key set. The normal IPCP destructor removes EFCP connections, RMT forwarding and SDU protection; KFA flow destruction destroys the queued receive SDUs. New sessions must authenticate under the updated key set.", "method": "Pinned key admission and administrative endpoint/flow teardown source trace", "source_label": "IRATI AuthSSH2, normal IPCP destruction and KFA receive queue cleanup", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/ipcps/normal-ipcp.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/kfa.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcm/addons/console.cc" ], "editorial_references": [ "round676.html" ], "qualification": "Yes at endpoint-host IPCP identity granularity, using administrative teardown/restart rather than a demonstrated seamless live-revocation command. The completed cutover requires all old affected flow descriptors, in-flight operations and endpoint contexts to be quiesced and destroyed before service resumes; a key-file edit or an isolated destroy-ipcp success message is not itself that boundary. Authorized peers can reconnect with retained keys after restart. Applications must use this protected upper DIF without a parallel unprotected bypass. Application roles, name-to-credential exposure (F21), already delivered data and DoS isolation are separate. Source-supported procedure, not an executed revocation/concurrency test." }, { "id": "F17-PN", "feature": "F17", "stack": "PN", "status": "Y", "reason": "Architecture 5.6 and Bootstrap Reachability sections 3.1 and 7.1 permit local carrier candidates with expected identities and HS2, without DNS. The selected realization uses locally known identities and native link candidates or numeric IPv4 peers. Optional DNS references are excluded. No arbitrary remote discovery, protected referral or cold-start Internet reachability is claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F17-PI", "feature": "F17", "stack": "PI", "status": "Y", "reason": "Architecture 5.6 and Bootstrap Reachability sections 3.1 and 7.1 permit local carrier candidates with expected identities and HS2, without DNS. The selected realization uses locally known identities and native link candidates or numeric IPv4 peers. Optional DNS references are excluded. No arbitrary remote discovery, protected referral or cold-start Internet reachability is claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "F17-IP", "feature": "F17", "stack": "IP", "status": "Y", "reason": "The numeric-address profile uses provisioned addresses and routing configuration; DNS is not a prerequisite for packet forwarding or startup.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-BP", "feature": "F17", "stack": "BP", "status": "Y", "reason": "The profile fixes ipn bootstrap, numeric neighbors, NODE-ID certificates and local trust, without SNI virtual hosting.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2" ], "editorial_references": [], "qualification": "" }, { "id": "F17-CG", "feature": "F17", "stack": "CG", "status": "Y", "reason": "Numeric peers, known ipn identifiers and locally supplied trust/plans avoid DNS; TCPCL supports certificate NODE-ID validation without DNS names.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9174, TCPCLv4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "F17-LT", "feature": "F17", "stack": "LT", "status": "Y", "reason": "Supplied numeric identifiers, channel mappings, plans and keys permit operation without DNS; no online IP-based bootstrap is selected.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "LTP specification, RFC 5326", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F17-LP", "feature": "F17", "stack": "LP", "status": "Y", "reason": "Known numeric peer addresses and Peer IDs avoid DNS discovery in the selected profile, not in every libp2p application.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://libp2p.io/docs/peers/" ], "editorial_references": [], "qualification": "" }, { "id": "F17-TO", "feature": "F17", "stack": "TO", "status": "Y", "reason": "Tor directory bootstrap supports built-in numeric fallback addresses and identity fingerprints; onion-v3 names encode service keys rather than requiring DNS resolution. This credits the selected onion-service use, with reachable directory infrastructure. It does not remove directory authorities or cover ordinary DNS-named websites accessed through exits.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://torproject.gitlab.io/torspec/dir-list-spec.html" ], "editorial_references": [], "qualification": "Pin a Tor build with usable numeric fallbacks and bootstrap with an empty DNS cache and DNS disabled. Confirm onion-v3 access; no runtime test was executed. Onion address encoding: https://spec.torproject.org/rend-spec/encoding-onion-addresses.html" }, { "id": "F17-I2", "feature": "F17", "stack": "I2", "status": "Y", "reason": "The selected profile now starts from a locally supplied fresh RouterInfo bundle with reachable numeric NTCP2 contacts, known destination keys and a correct local clock. Official file reseeding avoids an online reseed service; no external DNS naming or time service is selected. This is not cold discovery from zero information or a claim about default online reseeding.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/blog/2020/06/07/help-your-friends-join-i2p-by-sharing-reseed-bundles/" ], "editorial_references": [], "qualification": "Pin a router build and file bootstrap configuration, disable DNS/online reseed and external time queries, and verify fresh RouterInfo admission plus NTCP2 tunnel establishment. Test stale/unreachable contacts separately. No runtime test was executed." }, { "id": "F17-YG", "feature": "F17", "stack": "YG", "status": "Y", "reason": "The selected Yggdrasil profile uses documented numeric TLS peer URLs with pinned peer public keys and no DNS-based application naming. Local key generation and numeric peering remove external DNS from bootstrap and traffic; this does not claim reachability without configured peers or underlay connectivity.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-CJ", "feature": "F17", "stack": "CJ", "status": "Y", "reason": "The selected cjdns UDP profile uses numeric peer addresses, known public keys and locally exchanged peering credentials. Its generated overlay IPv6 addresses can be used directly by the application. No DNS lookup is required in this composition; hostname-based services would be a different choice.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md" ], "editorial_references": [], "qualification": "" }, { "id": "F17-MQ", "feature": "F17", "stack": "MQ", "status": "Y", "reason": "The profile uses numeric peers, directly provisioned certificate trust and no SNI requirement or online certificate service. QUIC authentication is retained without a DNS lookup. This scoped inference does not apply to arbitrary hostname-based Internet services.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9001#section-4.4" ], "editorial_references": [], "qualification": "" }, { "id": "F17-SC", "feature": "F17", "stack": "SC", "status": "Y", "reason": "The profile selects numeric topology, daemon and service addresses, locally provisioned trust and a correct local clock. SCION configuration supports IP literals for routers, control and discovery services; no external DNS lookup is needed in this composition.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://docs.scion.org/en/latest/manuals/common.html#topology-json" ], "editorial_references": [], "qualification": "Shared F17/C05: pin all control/daemon components, bootstrap with DNS disabled and locally provisioned trust/time, then send to a numeric endpoint. Check certificate retrieval, telemetry and optional configuration introduce no hidden DNS dependency." }, { "id": "F17-RT", "feature": "F17", "stack": "RT", "status": "Y", "reason": "The serial profile uses hashes and announcements without DNS or local TCP sharing.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html#public-key-announcements" ], "editorial_references": [], "qualification": "" }, { "id": "F17-NS", "feature": "F17", "stack": "NS", "status": "N", "reason": "The selected WSS hostname profile requires DNS; numeric addresses and suitable certificate validation would need another profile.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F17-MT", "feature": "F17", "stack": "MT", "status": "Y", "reason": "Known radio peers and locally provisioned keys communicate without a DNS resolver. No network bridge, remote name service or online certificate lookup is selected.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/introduction/" ], "editorial_references": [], "qualification": "" }, { "id": "F17-GN", "feature": "F17", "stack": "GN", "status": "Y", "reason": "This numeric-contact profile excludes online hostlists, DNS and NAT helpers; transport peers are supplied locally.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet TRANSPORT handbook, v0.20.x; current introductory sections only", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html" ], "editorial_references": [], "qualification": "Audit UDP-only configuration, HELLO/DHT bootstrap and all helper processes in an isolated DNS-disabled deployment." }, { "id": "F17-ND", "feature": "F17", "stack": "ND", "status": "Y", "reason": "Explicit Ethernet faces, local names/routes and provisioned trust avoid DNS resolution and public hub discovery.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 face management", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-AX", "feature": "F17", "stack": "AX", "status": "Y", "reason": "Known callsigns and NET/ROM routing announcements provide the selected operation without DNS.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux AX.25 HOWTO: NET/ROM port configuration", "sources": [ "https://tldp.org/HOWTO/AX25-HOWTO/x1218.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-BA", "feature": "F17", "stack": "BA", "status": "Y", "reason": "Locally attached Ethernet interfaces and numeric MAC destinations do not require DNS.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-BL", "feature": "F17", "stack": "BL", "status": "Y", "reason": "Numeric destinations and local Babel exchanges operate without DNS in this composition.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-RI", "feature": "F17", "stack": "RI", "status": "Y", "reason": "Numeric peer addresses and locally provisioned external PSKs allow the selected DTLS sessions without DNS. The selected RPL/6LoWPAN control and local prefix provisioning add no DNS service.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "Maintain the declared numeric-peer and local-key profile; no certificate lookup, hostname-based broker or external time/name service is implicitly added." }, { "id": "F17-HP", "feature": "F17", "stack": "HP", "status": "Y", "reason": "Initial locators are numeric and peer identities are pinned locally. The HIP base exchange does not require the optional DNS identity lookup in this configuration.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Known-peer deployment; this is not automatic discovery of an unknown mobile peer or a DNS-free rendezvous system." }, { "id": "F17-CX", "feature": "F17", "stack": "CX", "status": "Y", "reason": "The selected CCNx messages use supplied content names, configured name routes and numeric UDP peers. Producer validation uses locally supplied keys without DNS or certificate retrieval.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "A CCNx content name is not itself a DNS lookup. This does not prove global namespace resolution or credit an unspecified routing protocol." }, { "id": "F17-LI", "feature": "F17", "stack": "LI", "status": "Y", "reason": "The declared profile uses numeric endpoint and mapping-service addresses. Map-Request/Reply lookups resolve EID-to-RLOC mappings directly; DNS name-to-EID resolution is not mandatory for already supplied numeric EIDs.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html#section-3; rfc9301.html#section-4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-3", "https://www.rfc-editor.org/rfc/rfc9301.html#section-4" ], "editorial_references": [], "qualification": "Verify the complete selected deployment with DNS disabled; implementation defaults or management tools may introduce additional dependencies." }, { "id": "F17-IL", "feature": "F17", "stack": "IL", "status": "N", "reason": "This profile explicitly selects DNS NID/L64 discovery for initial peers. The architecture permits other initial-contact arrangements, but they are not the selected composition.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html#section-4.4; rfc6742.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc6742.html" ], "editorial_references": [], "qualification": "" }, { "id": "F17-TS", "feature": "F17", "stack": "TS", "status": "N", "reason": "The managed service uses named control and relay infrastructure. Its fallback sends a hostname query to a bootstrap-DNS service over HTTPS; avoiding the local resolver does not eliminate name resolution from the selected stack.", "method": "Primary documentation, pinned source and explicit whole-stack inference", "source_label": "Tailscale bootstrap DNS, infrastructure requirements and RFC 4271", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/net/dnsfallback/dnsfallback.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/net/dnsfallback/dnsfallback.go", "https://tailscale.com/docs/reference/faq/firewall-ports", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2" ], "editorial_references": [ "round590.html", "round590-sources.json" ], "qualification": "MagicDNS may be optional for peer traffic. This verdict concerns the complete managed lifecycle, not whether an already connected peer can be addressed numerically." }, { "id": "F17-RA", "feature": "F17", "stack": "RA", "status": "Y", "reason": "The documented Ethernet deployment uses local configuration, DIF enrollment and an application-name directory, not DNS. Its management console is reached through a Unix socket. This supplies a DNS-free operating path for the selected local composition.", "method": "Primary deployment documentation and architectural dependency inference; no execution", "source_label": "IRATI Ethernet tutorial and software architecture documentation", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round651.html" ], "qualification": "Documentary dependency trace, not a packet-capture test. Installation downloads and optional IP shims are outside this operating path. RINA naming and directory functions are still required; DNS-free does not mean directory-free." }, { "id": "F18-PN", "feature": "F18", "stack": "PN", "status": "Y", "reason": "Architectural composition: Relationship Retention sections 6 and 10 define intermediary replicas and later forwarding while paths are unavailable; the comparative whitepaper continuity model explicitly permits non-contemporaneous connectivity. Applies to admitted reliable items with viable relationship and cryptographic state. General activation remains unavailable under RET-001.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "dtn.html#prp" ], "qualification": "Assign and implement RET-001 activation, then exercise staged contacts with no simultaneous end-to-end path. Verify retained-item reprotection, expiry, duplicate suppression and feedback. No cold first-contact or eventual-delivery guarantee is credited." }, { "id": "F18-PI", "feature": "F18", "stack": "PI", "status": "Y", "reason": "Architectural composition: Relationship Retention sections 6 and 10 define intermediary replicas and later forwarding while paths are unavailable; the comparative whitepaper continuity model explicitly permits non-contemporaneous connectivity. Applies to admitted reliable items with viable relationship and cryptographic state. General activation remains unavailable under RET-001.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "dtn.html#prp" ], "qualification": "Assign and implement RET-001 activation, then exercise staged contacts with no simultaneous end-to-end path. Verify retained-item reprotection, expiry, duplicate suppression and feedback. No cold first-contact or eventual-delivery guarantee is credited." }, { "id": "F18-IP", "feature": "F18", "stack": "IP", "status": "N", "reason": "The selected datagram service defines neither proactive multipath copies nor retained delivery across disconnection/non-overlapping contacts.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-BP", "feature": "F18", "stack": "BP", "status": "Y", "reason": "RFC 9171 defines store-carry-forward delivery through scheduled or opportunistic contacts without simultaneous sender/receiver presence. TCPCL requires a live TCP contact per hop, not a simultaneous end-to-end TCP connection. Route selection and delivery opportunities remain necessary.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-1" ], "editorial_references": [], "qualification": "" }, { "id": "F18-CG", "feature": "F18", "stack": "CG", "status": "Y", "reason": "Stored bundles can traverse successive scheduled contacts without a contemporaneous end-to-end path; contact feasibility and bundle expiry still constrain delivery.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "F18-LT", "feature": "F18", "stack": "LT", "status": "Y", "reason": "Intermediate BP storage and scheduled forwarding allow a bundle to traverse successive non-overlapping contacts; expiry and feasible contact volume still apply.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "F18-LP", "feature": "F18", "stack": "LP", "status": "N", "reason": "The selected QUIC-based transport has no intermediary retained-item forwarding service across staged contacts. Migration and retransmission do not supply one. An added store-and-forward application would change the compared stack. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-TO", "feature": "F18", "stack": "TO", "status": "N", "reason": "The selected onion-service stream protocol has no intermediate deferred-message forwarding across discontinuous contacts. Mail services above Tor are outside this stack.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-I2", "feature": "F18", "stack": "I2", "status": "N", "reason": "I2NP messages have expiration and use current tunnel delivery. This selected destination/tunnel layer defines no retained application-item service bridging expired paths and later contacts. Deferred messaging applications are not included. Scope inference, not a claim about all I2P software.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/i2np/" ], "editorial_references": [], "qualification": "" }, { "id": "F18-YG", "feature": "F18", "stack": "YG", "status": "N", "reason": "These selected routed application-UDP stacks forward live datagrams, without a retained-item contact-chain service. Route recovery and transient queues do not meet this criterion. Scope inference; an added DTN layer must appear in the compared stack.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "dtn.html#datagrams" ], "qualification": "" }, { "id": "F18-CJ", "feature": "F18", "stack": "CJ", "status": "N", "reason": "These selected routed application-UDP stacks forward live datagrams, without a retained-item contact-chain service. Route recovery and transient queues do not meet this criterion. Scope inference; an added DTN layer must appear in the compared stack.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "dtn.html#datagrams" ], "qualification": "" }, { "id": "F18-MQ", "feature": "F18", "stack": "MQ", "status": "N", "reason": "The selected QUIC-based transport has no intermediary retained-item forwarding service across staged contacts. Migration and retransmission do not supply one. An added store-and-forward application would change the compared stack. Scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-SC", "feature": "F18", "stack": "SC", "status": "N", "reason": "These selected routed application-UDP stacks forward live datagrams, without a retained-item contact-chain service. Route recovery and transient queues do not meet this criterion. Scope inference; an added DTN layer must appear in the compared stack.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "dtn.html#datagrams" ], "qualification": "" }, { "id": "F18-RT", "feature": "F18", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link tears down after its stale/keepalive timeout; it does not define a deferred message store surviving that lifecycle. The selected stack excludes LXMF, whose propagation nodes provide an additional store-and-forward service.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [], "qualification": "" }, { "id": "F18-NS", "feature": "F18", "stack": "NS", "status": "N", "reason": "NIP-01 defines client publication and retrieval of relay-stored events, not relay-to-relay DTN forwarding through staged contacts. F11 remains positive for mailbox-style deferred retrieval.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F18-MT", "feature": "F18", "stack": "MT", "status": "N", "reason": "With the optional retention module disabled, forwarding and bounded retries require reachable contacts during the transmission/retry window. No retained admitted-item transfer across separated contacts is supplied by this profile.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [], "qualification": "" }, { "id": "F18-GN", "feature": "F18", "stack": "GN", "status": "N", "reason": "The selected CADET channel provides connected end-to-end delivery and optional retransmission. It does not define intermediate retained-item transfer across non-overlapping contacts. Offline storage applications are outside this composition.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "GNUnet CADET handbook, v0.20.x documentary baseline", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-ND", "feature": "F18", "stack": "ND", "status": "Y", "reason": "A bounded staged-pull witness carries the same named signed Data from producer A through caches B and C to final requester D. First, a local requester at B solicits the item from A; B admits the returning Data. Disconnect A-B. During B-C contact, a local requester at C asks for the same name; B serves its CS and C admits the returned Data. Disconnect B-C. D subsequently requests it from C. There is never an A-to-D path. Forwarder lookup, cache-hit response and solicited-Data insertion compose this relay-to-relay transfer without an application mailbox or new wire protocol. This is demand-triggered cache forwarding, not autonomous push, custody transfer or guaranteed delivery. Keep both caches alive, provision the name/trust/active faces, ensure capacity and bounded freshness, and use new Interest nonces. Cache eviction, absent requests or restart can defeat the witness.", "method": "Primary-source control-flow analysis and bounded composition inference; no protocol execution", "source_label": "NFD 24.07 forwarding source and CS controls; NDN Data format", "sources": [ "https://docs.named-data.net/NFD/24.07/doxygen/forwarder_8cpp_source.html", "https://docs.named-data.net/NFD/24.07/manpages/nfdc-cs.html", "https://docs.named-data.net/NDN-packet-spec/current/data.html", "https://docs.named-data.net/NFD/24.07/doxygen/strategy_8cpp_source.html" ], "editorial_references": [], "qualification": "Execute the three non-overlapping contact stages in round120.html. Capture identical signed Data at B, C and D; inspect CS hits/admission and verify D signature with preprovisioned trust. Demonstrate no simultaneous A-D path, and negative cases for eviction, stale MustBeFresh lookup and missing pull. No runtime experiment performed." }, { "id": "F18-AX", "feature": "F18", "stack": "AX", "status": "N", "reason": "The routing flowchart queues a frame after selecting or establishing an active next-hop route, and discards it when the available attempts are exhausted. It specifies no retained item awaiting a future contact after that failure. Transport retransmission across a live circuit does not supply the tested staged-contact DTN forwarding; no mailbox or DTN extension is selected.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "The NET/ROM Protocol, routing flowchart p. 7 (visually inspected)", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F18-BA", "feature": "F18", "stack": "BA", "status": "N", "reason": "The selected service does not retain an unroutable unicast item for a later non-overlapping contact: missing originator/next-hop paths discard it. Ordinary coding/fragmentation buffers do not provide DTN forwarding.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "Linux v6.12 batman-adv next-hop transmission", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c" ], "editorial_references": [], "qualification": "" }, { "id": "F18-BL", "feature": "F18", "stack": "BL", "status": "N", "reason": "No intermediate retained-item transfer across non-overlapping contacts is selected. Reestablishing an IPv6 route does not itself supply DTN forwarding.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-RI", "feature": "F18", "stack": "RI", "status": "N", "reason": "The selected RPL route construction and repair forward IP packets along available paths; they do not define retention of an admitted application item across non-overlapping contacts.", "method": "Selected-profile semantic review; no runtime execution", "source_label": "RPL non-storing mode, OF0 and DTLS 1.3 specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html" ], "editorial_references": [ "round257-sources.json", "round244.html" ], "qualification": "Non-storing describes downward routing-state placement, not absence of every buffer. Neither a repaired route nor transient queues establish DTN forwarding, and no DTN extension is selected." }, { "id": "F18-HP", "feature": "F18", "stack": "HP", "status": "N", "reason": "The selected host-mobility procedure repairs reachability to a host through a usable locator. It does not equip intermediate routers to accept a message, retain it through an outage, and forward it during a later non-overlapping contact.", "method": "Selected-composition semantic review; no runtime execution", "source_label": "Primary HIP/ESP/mobility and CCNx specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round255-sources.json", "round245.html" ], "qualification": "The selected IP/ESP/UDP composition has no store-carry-forward layer. A restored end-to-end path and ordinary buffering do not satisfy F18; no claim is made about HIP composed with a separate DTN protocol." }, { "id": "F18-CX", "feature": "F18", "stack": "CX", "status": "Y", "reason": "A bounded staged-pull witness uses the same signed Content Object through A-B, then B-C, then C-D contacts, never an A-D path. Local requesters at B and C solicit the object; each forwarder admits the matching response into its Content Store. After the upstream contact ends, the next requester triggers cache forwarding. No application mailbox or additional wire protocol is required.", "method": "Documentary bounded witness; no runtime or API test", "source_label": "RFC 8569 CCNx Content Store, cache control and signature semantics", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.5" ], "editorial_references": [ "round259-sources.json", "round259.html" ], "qualification": "Documentary composition, not an executed test. Enable cache admission/serving with enough capacity at B and C; preconfigure names, routes and trusted producer keys. Complete before expiration and eviction, keep caches alive, and validate the original signature. Native pulls are required: no autonomous push, guaranteed custody or delivery is claimed." }, { "id": "F18-LI", "feature": "F18", "stack": "LI", "status": "N", "reason": "RFC 9300 packet forwarding and RFC 9301 mapping lookup do not provide custody or deferred intermediate storage across non-overlapping contacts. Temporary buffering while a mapping is resolved is not DTN forwarding.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-IL", "feature": "F18", "stack": "IL", "status": "N", "reason": "Transit routers forward by Locator using IP routing. ILCC state and endpoint TCP buffering do not supply intermediate retention and later forwarding across non-overlapping contacts.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F18-TS", "feature": "F18", "stack": "TS", "status": "N", "reason": "The DERP forwarding path requires a connected destination or an available regional forwarder. It discards undeliverable packets rather than carrying admitted items across non-overlapping contacts.", "method": "Official documentation and pinned source inspection; no runtime test", "source_label": "Tailscale control plane and DERP source 566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go", "https://tailscale.com/docs/concepts/control-data-planes", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round586.html", "round586-sources.json" ], "qualification": "This is a source-based service-boundary decision. Ordinary buffering during a live connection does not establish DTN custody." }, { "id": "F18-RA", "feature": "F18", "stack": "RA", "status": "N", "reason": "In the selected RMT forwarding path, failure to obtain a next hop or an empty next-hop list destroys the PDU rather than retaining it for a later contact. The composition supplies no intermediary store-and-forward item lifecycle across non-overlapping contacts. Endpoint retries or a later repaired route do not establish F18.", "method": "Pinned forwarding, queue-lifecycle and routing-source inspection with selected-policy documentation", "source_label": "IRATI RMT, DTP and link-state routing source; normal-DIF configuration", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://raw.githubusercontent.com/wiki/IRATI/stack/Flow-Allocation.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/default.dif", "https://arxiv.org/abs/2510.27325" ], "editorial_references": [ "round659.html" ], "qualification": "No for the selected normal-DIF IRATI flow and routing composition, including its mobility mode. No assertion that every possible RINA policy lacks this capability. Retransmission queues and make-before-break continuity do not establish DTN storage. Source inspection and documentation only; no runtime experiment." }, { "id": "F20-PN", "feature": "F20", "stack": "PN", "status": "Y", "reason": "Asked whether independent final relationships may share a transit forwarding entry or each must have its own, the PRP owner clarified that the client autonomously chooses. Shared forwarding state is therefore an architectural option; a separate entry per final relationship is not mandatory. F20 tests whether transit can forward without mandatory per-end-to-end-flow or circuit state, not whether every client selects that mode.", "method": "Architectural capability clarification; no implementation execution", "source_label": "Direct PRP owner clarification, editorial conversation, 2026-10-16; existing architecture/state decomposition", "sources": [], "editorial_references": [ "round359-review.json", "round347-sources.json", "round359-review.json" ], "qualification": "Architectural owner clarification, not a runtime or scalability result. Clients may choose separate state. Neighbor sessions, aggregate routes and endpoint relationship/session state remain permitted and are not claimed to disappear. The clarification does not specify allocator keys, reference counting or teardown behavior; these remain implementation/documentation details to verify, without inferring that closing one relationship disrupts or preserves another in an existing build. No security, global-capacity or constant-memory claim follows." }, { "id": "F20-PI", "feature": "F20", "stack": "PI", "status": "Y", "reason": "Asked whether independent final relationships may share a transit forwarding entry or each must have its own, the PRP owner clarified that the client autonomously chooses. Shared forwarding state is therefore an architectural option; a separate entry per final relationship is not mandatory. F20 tests whether transit can forward without mandatory per-end-to-end-flow or circuit state, not whether every client selects that mode.", "method": "Architectural capability clarification; no implementation execution", "source_label": "Direct PRP owner clarification, editorial conversation, 2026-10-16; existing architecture/state decomposition", "sources": [], "editorial_references": [ "round359-review.json", "round347-sources.json", "round359-review.json" ], "qualification": "Architectural owner clarification, not a runtime or scalability result. Clients may choose separate state. Neighbor sessions, aggregate routes and endpoint relationship/session state remain permitted and are not claimed to disappear. The clarification does not specify allocator keys, reference counting or teardown behavior; these remain implementation/documentation details to verify, without inferring that closing one relationship disrupts or preserves another in an existing build. No security, global-capacity or constant-memory claim follows." }, { "id": "F20-IP", "feature": "F20", "stack": "IP", "status": "Y", "reason": "For the selected direct IP forwarding composition, transit routers need routes and neighbor state, not an end-to-end connection entry per application flow. QUIC endpoint connection state is outside the transit role. No NAT, connection-tracking firewall or application relay is introduced by this credit; optional flow caches are not mandatory forwarding state.", "method": "Documentary analysis", "source_label": "Primary specification / selected endpoint and transit roles", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "F20-BP", "feature": "F20", "stack": "BP", "status": "Y", "reason": "For the selected aggregate-gateway profile, BPv7 selects next nodes from each bundle's destination EID using shared forwarding information and convergence-layer services. No entry for each final flow or circuit is required. Per-bundle queues/retention and neighbor TCPCL sessions remain; this is an architectural inference, not a claim of zero state or measured memory efficiency. F21 authenticated application identity remains a separate pending question.", "method": "Documentary analysis and architectural inference", "source_label": "RFC 9171 section 5.4 / selected aggregate gateway profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [], "qualification": "" }, { "id": "F20-CG", "feature": "F20", "stack": "CG", "status": "Y", "reason": "SABR selects routes by destination and contact plan. Forwarding retains bundles and adjacent transfer state, but does not require an entry keyed by each final-to-final flow or circuit. Per-bundle storage remains real state and must be counted in capacity analysis.", "method": "Documentary architectural inference; no executable qualification", "source_label": "Primary specifications; selected-profile analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "Validate the declared complete composition and local management in an executable deployment; this decision is not measured scale, conformance or interoperability." }, { "id": "F20-LT", "feature": "F20", "stack": "LT", "status": "Y", "reason": "SABR selects routes by destination and contact plan. Forwarding retains bundles and adjacent transfer state, but does not require an entry keyed by each final-to-final flow or circuit. Per-bundle storage remains real state and must be counted in capacity analysis.", "method": "Documentary architectural inference; no executable qualification", "source_label": "Primary specifications; selected-profile analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [], "qualification": "Validate the declared complete composition and local management in an executable deployment; this decision is not measured scale, conformance or interoperability." }, { "id": "F20-LP", "feature": "F20", "stack": "LP", "status": "Y", "reason": "For the selected direct IP forwarding composition, transit routers need routes and neighbor state, not an end-to-end connection entry per application flow. QUIC endpoint connection state is outside the transit role. No NAT, connection-tracking firewall or application relay is introduced by this credit; optional flow caches are not mandatory forwarding state.", "method": "Documentary analysis", "source_label": "Primary specification / selected endpoint and transit roles", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "F20-TO", "feature": "F20", "stack": "TO", "status": "N", "reason": "Tor relays process cells using circuit-specific cryptographic and forwarding state. Multiplexing streams within a circuit does not eliminate that per-circuit transit state; the criterion excludes both flow and circuit state for end-to-end communications.", "method": "Documentary analysis", "source_label": "Primary specification / selected endpoint and transit roles", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [], "qualification": "" }, { "id": "F20-I2", "feature": "F20", "stack": "I2", "status": "N", "reason": "The selected multi-hop I2P profile requires tunnel-specific transit configuration: receive/next Tunnel IDs, next peer and layer/IV keys. This is circuit state, rather than only shared destination routes or NTCP2 neighbor sessions. A tunnel pool can carry multiple application messages and flows; No does not mean a separate tunnel is required per application connection. F20 explicitly includes mandatory circuit state.", "method": "Documentary analysis", "source_label": "Official I2P tunnel specification", "sources": [ "https://www.i2p.net/en/docs/specs/tunnel-implementation/" ], "editorial_references": [], "qualification": "" }, { "id": "F20-YG", "feature": "F20", "stack": "YG", "status": "Y", "reason": "In the pinned Ironwood transit path, router.handleTraffic selects the next peer from the packet path/watermark using shared router topology and peer state. Path-notification transit forwards before endpoint path-cache updates; destination sessions and originating path caches are distinct from transit forwarding. No final-flow/circuit entry is required at each intermediate node. Queues, topology and adjacency state remain.", "method": "Read-only code analysis", "source_label": "Pinned Ironwood forwarding code", "sources": [ "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go" ], "editorial_references": [], "qualification": "" }, { "id": "F20-CJ", "feature": "F20", "stack": "CJ", "status": "Y", "reason": "At the pinned cjdns revision, SwitchCore.receiveMessage decodes the destination interface from the packet label, checks the shared interface slot, rewrites the remaining/reverse label and forwards. It installs no per-final-flow circuit entry for this transit operation. Neighbor CryptoAuth sessions and endpoint sessions remain; route discovery and shared interface state are not zero-state forwarding.", "method": "Read-only code analysis", "source_label": "Pinned cjdns SwitchCore receiveMessage", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/SwitchCore.c" ], "editorial_references": [], "qualification": "" }, { "id": "F20-MQ", "feature": "F20", "stack": "MQ", "status": "Y", "reason": "For the selected direct IP forwarding composition, transit routers need routes and neighbor state, not an end-to-end connection entry per application flow. QUIC endpoint connection state is outside the transit role. No NAT, connection-tracking firewall or application relay is introduced by this credit; optional flow caches are not mandatory forwarding state.", "method": "Documentary analysis", "source_label": "Primary specification / selected endpoint and transit roles", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "F20-SC", "feature": "F20", "stack": "SC", "status": "Y", "reason": "The selected SCION data plane carries forwarding paths and hop fields in each packet. Transit routers use those fields with local interface/topology and cryptographic validation state; they need not install a separate entry for each final application flow. Control-plane path segments and local underlay routing remain, and this does not assert absence of all router state.", "method": "Documentary/code analysis", "source_label": "Primary routing specification / pinned transport code", "sources": [ "https://docs.scion.org/en/latest/overview.html#routing" ], "editorial_references": [], "qualification": "" }, { "id": "F20-RT", "feature": "F20", "stack": "RT", "status": "N", "reason": "The selected Reticulum Link profile uses transit link_table entries keyed by Link ID. Transport creates these entries while forwarding Link requests, stores ingress/egress interfaces and hop/proof state, and uses them for subsequent Link traffic until expiry. This is end-to-end Link-specific forwarding state, distinct from shared destination routes and adjacency state.", "method": "Documentary/code analysis", "source_label": "Primary routing specification / pinned transport code", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [], "qualification": "" }, { "id": "F20-NS", "feature": "F20", "stack": "NS", "status": "Y", "reason": "NIP-01 relay subscriptions can aggregate multiple authors and kinds through one connection-scoped filter set. Event delivery does not require a distinct circuit or forwarding entry for every author-reader flow; the relay can match each event against aggregate subscriptions. WebSocket neighbor sessions, subscriber/filter state and stored events remain. This credits absence of mandatory per-final-flow state, not absence of relay state or network-layer multicast.", "method": "Documentary analysis and architectural inference", "source_label": "NIP-01 subscription/filter semantics", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F20-MT", "feature": "F20", "stack": "MT", "status": "Y", "reason": "Ordinary forwarding uses destination/neighbor route hints and recent-packet duplicate/retry records, not an allocated entry for each final transport flow or circuit. This is not stateless forwarding: packet history and destination routes still consume resources.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/PacketHistory.cpp" ], "editorial_references": [], "qualification": "Measure packet-history, retry and destination-cache state as flows and packet rate increase; no memory bound is certified." }, { "id": "F20-GN", "feature": "F20", "stack": "GN", "status": "N", "reason": "A transit CADET relay allocates a CadetRoute keyed by the connection identifier, with previous/next directions, activity and queue bookkeeping. handle_connection_create inserts that entry in the routes map and subsequent traffic uses it. Multiple channels can share a tunnel, but the selected overlay still requires per-end-to-end connection/circuit transit state; stateless IPv4 forwarding underneath does not remove it.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "src/cadet/gnunet-service-cadet_core.c: CadetRoute, handle_connection_create, routes map", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "F20-ND", "feature": "F20", "stack": "ND", "status": "Y", "reason": "NFD transit has mandatory pending-request state, but not a mandatory end-to-end flow or circuit entry. Pit::findOrInsert indexes Interests by name and matching selectors; Entry::canMatch compares Name, CanBePrefix and MustBeFresh, not a consumer-producer connection identifier. Matching requests can share an entry with per-neighbor in/out records. Entries expire or are satisfied independently of an application session. Faces represent local adjacencies. This meets the existing flow/circuit-specific criterion, not a stronger stateless-forwarding criterion: PIT occupancy still grows with outstanding distinct requests and can be resource-sensitive.", "method": "Pinned forwarding-state inventory; no runtime execution", "source_label": "NFD 24.07 PIT lookup, matching and face records", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/table/pit.cpp", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/table/pit-entry.cpp", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/table/pit-entry.hpp", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [], "qualification": "Capture two consumers requesting the same name/selectors and separate names; inspect PIT aggregation, per-face records, expiry and satisfaction. Confirm no end-to-end circuit setup. Measure PIT occupancy separately; this Yes does not establish resource isolation." }, { "id": "F20-AX", "feature": "F20", "stack": "AX", "status": "Y", "reason": "Transit consults destination/neighbor routes. The destination node invokes its Circuit Manager; intermediate forwarding need not allocate a final-circuit entry. Neighbor AX.25 link state remains.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "Verify intermediate versus destination circuit allocation in a pinned implementation with several final circuits sharing a transit node; no execution performed." }, { "id": "F20-BA", "feature": "F20", "stack": "BA", "status": "Y", "reason": "batadv_route_unicast_packet looks up the destination originator, then batadv_send_skb_to_orig selects a neighbor. This forwarding path requires no final-flow or circuit entry. Originator, neighbor and client translation state remains; packet buffers are not zero state.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "Linux v6.12 batman-adv unicast forwarding", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c" ], "editorial_references": [], "qualification": "Trace multiple final conversations through Linux 6.12 unicast forwarding and inventory originator, neighbor, translation and packet-buffer state. Check that no per-final-flow/circuit entry is required. No kernel execution performed." }, { "id": "F20-BL", "feature": "F20", "stack": "BL", "status": "Y", "reason": "Forwarding uses destination-prefix routes; Babel neighbor/source/route tables do not allocate one entry per final flow.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F20-RI", "feature": "F20", "stack": "RI", "status": "Y", "reason": "Selected RPL non-storing routing maintains topology, parent and destination information, with downward source routes generated by the root. DTLS association state terminates only at the final peers. These transit roles need no mandatory entry per end-to-end DTLS connection or application flow.", "method": "Documentary role/state inventory; no runtime test", "source_label": "Primary protocol specifications and unchanged selected compositions", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.2", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round260-sources.json" ], "qualification": "The root still stores destination/topology state, and routers retain neighbor/control state. 6LoWPAN reassembly may buffer fragments per datagram; that is not persistent state for an end-to-end flow. This does not establish memory bounds at global scale." }, { "id": "F20-HP", "feature": "F20", "stack": "HP", "status": "Y", "reason": "HIP association state and ESP security associations reside at the communicating hosts. The selected direct IPv4/IPv6 transit forwards outer IP locators without mandatory per-HIP-association or application-flow entries. RFC 7402 section 3.2 places HIT/IP translation and ESP processing at the endpoints.", "method": "Documentary role/state inventory; no runtime test", "source_label": "Primary protocol specifications and unchanged selected compositions", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc9147.html", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [ "round260-sources.json" ], "qualification": "This does not mean endpoints are stateless. No NAT, HIP proxy or stateful traversal relay is selected; optional middleboxes can add state. No routing-scale or runtime qualification follows." }, { "id": "F20-CX", "feature": "F20", "stack": "CX", "status": "Y", "reason": "CCNx pending-Interest state is keyed by name and matching restrictions, with previous-hop records and request lifetimes. Similar requests can share an entry; satisfaction or expiry removes request state independently of any consumer-producer session. No end-to-end circuit entry is mandatory.", "method": "Documentary mechanism review; no active probing or runtime test", "source_label": "CCNx request-state semantics and HIP/DTLS handshake specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.2" ], "editorial_references": [ "round266-sources.json" ], "qualification": "Applies the existing NDN boundary consistently: this is not stateless forwarding. Distinct outstanding requests consume PIT resources, and adjacency/FIB state remains. No occupancy bound, DoS resistance or runtime verification follows." }, { "id": "F20-LI", "feature": "F20", "stack": "LI", "status": "Y", "reason": "Forwarding uses IP routes and an EID-prefix Map-Cache. Flow hashing for RLOC selection does not require a stored forwarding entry for every end-to-end flow; endpoint and registration state have different scope.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html#section-6; rfc9300.html#section-12", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-6", "https://www.rfc-editor.org/rfc/rfc9300.html#section-12" ], "editorial_references": [], "qualification": "Architectural state-placement result only; does not bound cache size or prove global capacity." }, { "id": "F20-IL", "feature": "F20", "stack": "IL", "status": "Y", "reason": "Transit routers forward on destination Locators using IP routing. The per-correspondent ILCC and TCP connection state reside at endpoints, not as compulsory per-end-to-end-flow forwarding entries in each transit router.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html#section-4.4; rfc6741.html#section-5", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc6741.html#section-5" ], "editorial_references": [], "qualification": "No claim about the size of routing tables or quantitative global capacity." }, { "id": "F20-TS", "feature": "F20", "stack": "TS", "status": "Y", "reason": "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.", "method": "Pinned forwarding-code and state-key inventory; no runtime test", "source_label": "DERP lookupDest, handleFrameSendPacket, sendPacket, noteSendFromSrc and peer-departure watchers", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round593.html", "round593-sources.json" ], "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." }, { "id": "F20-RA", "feature": "F20", "stack": "RA", "status": "Y", "reason": "The documented IRATI RMT relays between underlying flows using a forwarding table keyed by destination address and QoS identifier. Multiple upper-layer connections share underlying neighbor flows. This provides a transit-forwarding mechanism without a mandatory entry for each upper end-to-end flow.", "method": "Primary architecture documentation and transit/endpoint state inventory; no runtime test", "source_label": "IRATI software architecture: Resource Allocator, PDUFT and RMT", "sources": [ "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round654.html" ], "qualification": "Architectural Yes for the selected normal-DIF composition. Endpoint EFCP connections, neighbor-flow state and routing tables remain necessary and are allowed by F20. This is not stateless networking or an executable state/memory measurement; optional policies are not exhaustively qualified." }, { "id": "F21-PN", "feature": "F21", "stack": "PN", "status": "Y", "reason": "Wire-v4 HS2 authenticates both endpoint identities. The endpoint API exposes a provenance-bearing peer descriptor: Strong ID, public key, relationship/session references and transcript binding, only for an open relationship with established session. Application I/O is attached to that relationship. This supports reusing the authenticated final-peer identity without an application login/token exchange; it supplies neither civil identity nor application permissions.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [], "editorial_references": [ "index.html#round053" ], "qualification": "Endpoint API/code review at c6bdd443ab031c55f5ed25c3c2d2615d9227d5a3, not executed end-to-end qualification. Bind the selected carrier to the final E2E relationship; test wrong-key rejection, reference mismatch, receive provenance, close/rekey and stale identity caching. Descriptor flags explicitly do not assert a remote identity generation. No universal application integration or transit-anonymity certification." }, { "id": "F21-PI", "feature": "F21", "stack": "PI", "status": "Y", "reason": "Wire-v4 HS2 authenticates both endpoint identities. The endpoint API exposes a provenance-bearing peer descriptor: Strong ID, public key, relationship/session references and transcript binding, only for an open relationship with established session. Application I/O is attached to that relationship. This supports reusing the authenticated final-peer identity without an application login/token exchange; it supplies neither civil identity nor application permissions.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [], "editorial_references": [ "index.html#round053" ], "qualification": "Endpoint API/code review at c6bdd443ab031c55f5ed25c3c2d2615d9227d5a3, not executed end-to-end qualification. Bind the selected carrier to the final E2E relationship; test wrong-key rejection, reference mismatch, receive provenance, close/rekey and stale identity caching. Descriptor flags explicitly do not assert a remote identity generation. No universal application integration or transit-anonymity certification." }, { "id": "F21-IP", "feature": "F21", "stack": "IP", "status": "N", "reason": "The selected IP datagram baseline exposes network addresses, not authenticated final-participant identity. IPsec or an authenticated transport/application protocol would add a composition absent here.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-BP", "feature": "F21", "stack": "BP", "status": "Y", "reason": "The newer pinned ION API returns bundleSourceEid, primaryIntegrityVerified and payloadAuthVerified together with the ADU. Native BIB verification sets the indicators after successful processing of the corresponding target; receiver rules select keys using the bundle source EID. With exact source-specific rules and distinct sender/receiver-only keys, protected primary and payload, and the application using the source as authenticated only when both indicators are true, this supplies native final-source provenance without another authentication exchange. Unlike F16, F21 does not require all unauthenticated payloads to be stopped before the API. The previous mandatory-delivery-gate blocker conflated those criteria. Unflagged deliveries remain unauthenticated. This is shared-key peer authentication, not civil identity, nonrepudiation or replay prevention.", "method": "Pinned implementation/API analysis; no protocol experiment", "source_label": "ION native BPSec verifier, source-key policy selection and BpDelivery API", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/include/bp.h", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/ext/bpsec/bib.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bpsec/policy/bpsec_policy_rule.c" ], "editorial_references": [ "round130-sources.json" ], "qualification": "Exercise valid, absent, corrupted, wrong-key and source-substitution cases through bp_receive; verify paired flags and source/ADU association, including restart. Use only the declared exact-origin keys and primary-inclusive payload coverage. No execution, complete TCPCL deployment, or interoperability certification is claimed." }, { "id": "F21-CG", "feature": "F21", "stack": "CG", "status": "Y", "reason": "Pinned ION BpDelivery associates bundleSourceEid, primaryIntegrityVerified and payloadAuthVerified with the delivered ADU. Receiver policy selection includes the bundle source; successful BIB target verification sets the corresponding flags. With exact-origin policies, distinct sender/receiver-only keys and primary-plus-payload coverage, the application may treat the source as authenticated only when both flags are true. This supplies final-peer provenance without another application authentication exchange; unflagged delivery is not authenticated.", "method": "Independent scope review of the pinned API witness used in Secure DTN; no inherited verdict or experiment", "source_label": "Pinned native BP delivery and BPSec receiver-policy code", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/include/bp.h", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/ext/bpsec/bib.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bpsec/policy/bpsec_policy_rule.c" ], "editorial_references": [ "round193-sources.json" ], "qualification": "Pin complete security/convergence-layer integration and exercise valid, missing, corrupted, wrong-key and source-substitution bundles through bp_receive. Verify both flags and source/ADU association after restart; do not treat waypoint-only keys, one flag, or an address alone as final-peer proof. This is shared-key authentication, not nonrepudiation or replay protection." }, { "id": "F21-LT", "feature": "F21", "stack": "LT", "status": "Y", "reason": "Pinned ION BpDelivery associates bundleSourceEid, primaryIntegrityVerified and payloadAuthVerified with the delivered ADU. Receiver policy selection includes the bundle source; successful BIB target verification sets the corresponding flags. With exact-origin policies, distinct sender/receiver-only keys and primary-plus-payload coverage, the application may treat the source as authenticated only when both flags are true. This supplies final-peer provenance without another application authentication exchange; unflagged delivery is not authenticated.", "method": "Independent scope review of the pinned API witness used in Secure DTN; no inherited verdict or experiment", "source_label": "Pinned native BP delivery and BPSec receiver-policy code", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/include/bp.h", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/ext/bpsec/bib.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bpsec/policy/bpsec_policy_rule.c" ], "editorial_references": [ "round193-sources.json" ], "qualification": "Pin complete security/convergence-layer integration and exercise valid, missing, corrupted, wrong-key and source-substitution bundles through bp_receive. Verify both flags and source/ADU association after restart; do not treat waypoint-only keys, one flag, or an address alone as final-peer proof. This is shared-key authentication, not nonrepudiation or replay protection." }, { "id": "F21-LP", "feature": "F21", "stack": "LP", "status": "Y", "reason": "The selected secure libp2p connection authenticates peer keys in its TLS handshake and exposes RemotePeer/RemotePublicKey through ConnSecurity. A stream's connection identifies its authenticated peer without adding application authentication. This is the direct final-peer composition, not an identity inferred from a relay address.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [ "https://pkg.go.dev/github.com/libp2p/go-libp2p/core/network#ConnSecurity" ], "editorial_references": [], "qualification": "" }, { "id": "F21-TO", "feature": "F21", "stack": "TO", "status": "N", "reason": "For client-to-onion-service delivery, the selected filesystem client authorization is restricted descriptor discovery. It does not expose the authorized client's authenticated identity to the receiving service. Optional HAProxy export supplies a circuit identifier, not that identity. The specified introduction-phase Ed25519 user authentication is explicitly unimplemented and is not part of this selected stack. The reverse direction still authenticates the onion service.", "method": "Documentary/code analysis", "source_label": "Primary specification and receiving implementation", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-I2", "feature": "F21", "stack": "I2", "status": "N", "reason": "The selected base I2P destination/tunnel composition does not include an authenticated datagram or Streaming protocol. I2P's official API guide states that the base message is raw and lacks a From address. Authenticated Datagram1/2 add a signed sender/payload format above I2CP. That is a viable explicit alternative stack, but is not silently added to this column.", "method": "Documentary analysis", "source_label": "Official I2P API guide / selected stack boundary", "sources": [ "https://i2p.net/en/docs/api/datagrams/" ], "editorial_references": [], "qualification": "" }, { "id": "F21-YG", "feature": "F21", "stack": "YG", "status": "Y", "reason": "For applications on the Yggdrasil node itself, the native IPv6 source represents a cryptographic node identity. Ironwood authenticates session keys and decrypts traffic before returning the source key; ipv6rwc checks the IPv6 source against the address derived from that key before delivery. The application receives this checked address through ordinary UDP receive metadata. No application login is required for node identity.", "method": "Documentary/code analysis", "source_label": "Primary specification and receiving implementation", "sources": [ "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/src/ipv6rwc/ipv6rwc.go" ], "editorial_references": [], "qualification": "Code trace with Ironwood d50055b11f5ec5b56ee4e56ba9a75261461821dc, not executed socket qualification. Test source mismatch, invalid handshake/traffic, rekey, restart and receive-interface provenance. The routed subnet alternative authenticates its owning router, not individual devices behind it. A process/user on the node is not separately identified; trusted local OS and interface isolation are assumed." }, { "id": "F21-CJ", "feature": "F21", "stack": "CJ", "status": "Y", "reason": "In the selected native cjdns application path, SessionManager drops failed decryptions and builds received RouteHeader identity from the final CryptoAuth session. UpperDistributor passes native IP payloads to TUNAdapter, which reconstructs the IPv6 source from that session-derived address. UDP receive metadata therefore exposes a checked cryptographic node identifier without application authentication; this is not merely outer-neighbor authentication.", "method": "Documentary/code analysis", "source_label": "Primary specification and receiving implementation", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c" ], "editorial_references": [], "qualification": "Documentary/code trace at f5902acab6dd2f1a68bf6e4c89e352ed71f93698. Execute invalid ciphertext, wrong key/address, session expiry/rekey and socket provenance tests. Restrict credit to applications on the final native node; imported IP tunnels, custom handlers, local packet injection and delegated endpoints require separate trust analysis. The node address does not identify a particular process or human." }, { "id": "F21-MQ", "feature": "F21", "stack": "MQ", "status": "Y", "reason": "The selected profile already requires mutually authenticated TLS with locally trusted certificates. QUIC connection state exposes TLS peer certificate state for application use. No JWT/login is necessary to obtain that authenticated endpoint key/certificate identity; certificate-to-account mapping remains application policy. This credits the API pattern, not execution of the selected multipath draft.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [ "https://pkg.go.dev/github.com/quic-go/quic-go#ConnectionState" ], "editorial_references": [], "qualification": "" }, { "id": "F21-SC", "feature": "F21", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP profile authenticates routing infrastructure and paths, not the final application participant. No end-to-end participant authentication layer is selected.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-RT", "feature": "F21", "stack": "RT", "status": "Y", "reason": "With native Link.identify explicitly enabled, the initiator signs the Link identifier and its public key inside the encrypted Link. Reticulum 1.5.5 validates that proof before assigning the remote identity and invoking the identified callback. The receiving application can use get_remote_identity on that same Link without a separate application authentication protocol. Identification is optional, not automatic.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [], "qualification": "Documentary/code evidence only. Test invalid proofs, unidentified data before identification, callback ordering, teardown and stale identity references. Applications must gate identity-dependent actions until identification; ordinary Link data callbacks do not enforce that policy. This is not a claim of universal transit anonymity." }, { "id": "F21-NS", "feature": "F21", "stack": "NS", "status": "Y", "reason": "For the explicitly selected event-author-to-reader role, NIP-01 binds the author public key to the signed event content; nostr-tools verifyEvent checks the canonical event hash and Schnorr signature. The verified event supplies its author identity to the receiving application. This authenticates the communication item's author, not the current relay, WebSocket publisher or reader, and does not establish freshness or live possession.", "method": "Documentary/code analysis", "source_label": "Primary specification and application API", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "API reviewed at nostr-tools master/pure.ts as consulted on 2026-10-14; pin a commit before executable qualification. Verify fresh wire objects, retain immutable verified values, and test signature/key/content changes. verifyEvent caches its result on the object; mutation followed by reuse of that cache is not revalidation. No live publisher authentication or replay protection credited." }, { "id": "F21-MT", "feature": "F21", "stack": "MT", "status": "Y", "reason": "For confirmed-key direct messages, Router verifies AEAD and sets pki_encrypted plus the validated full sender public_key on the decoded MeshPacket. RoutingModule passes local delivery to MeshService; handleFromRadio copies the whole packet into the phone queue. PhoneAPI copies that packet into FromRadio and serializes it, preserving the identity and payload binding without another application authentication exchange. Credit concerns PKI direct messages and the trusted local API, not arbitrary channel traffic, cached NodeInfo or civil identity.", "method": "Read-only code analysis and explicit topology inference", "source_label": "Pinned Meshtastic firmware: forwarding, authenticated receive and client serialization", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/PhoneAPI.cpp#L1073" ], "editorial_references": [], "qualification": "Exercise the serial API with valid, forged, changed-key and non-PKI messages. Confirm identity fields stay bound to each item through queuing and serialization; no client UI or hardware test performed." }, { "id": "F21-GN", "feature": "F21", "stack": "GN", "status": "Y", "reason": "The CADET API exposes the initiating PeerIdentity to the incoming-channel callback and the destination identity to the caller creating an outgoing channel. Tunnel key derivation incorporates the expected peer long-term public key; authenticated decryption precedes dispatch of channel messages. This makes the cryptographic final-peer identity available without an application JWT layer. It does not assert a civil identity or application authorization policy.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "src/include/gnunet_cadet_service.h: GNUNET_CADET_ConnectEventHandler; src/cadet/cadet_api.c: incoming callback; src/cadet/gnunet-service-cadet_tunnels.c: update_ax_by_kx, GCT_handle_kx_auth, GCT_handle_encrypted", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Connect known-key peers over a relay, compare callback identity with the expected key, and inject a mismatched-key peer. Verify authentication failure and no payload callback; no cryptographic or runtime audit performed." }, { "id": "F21-ND", "feature": "F21", "stack": "ND", "status": "Y", "reason": "For the selected producer-to-consumer role, ECDSA Data validation binds the producer key to the content. ndn-cxx passes the validated Data to the success callback; its KeyLocator identifies the key under the configured trust model. This credits authenticated item authorship, as for Nostr, not a live producer, serving cache or authenticated consumer.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "ndn-cxx 0.9.0 Data validation state", "sources": [ "https://raw.githubusercontent.com/named-data/ndn-cxx/ndn-cxx-0.9.0/ndn-cxx/security/validation-state.cpp", "https://docs.named-data.net/NDN-packet-spec/0.3/signature.html", "https://docs.named-data.net/ndn-cxx/0.9.0/doxygen/classndn_1_1Data.html", "https://raw.githubusercontent.com/named-data/ndn-cxx/ndn-cxx-0.9.0/ndn-cxx/security/validator.hpp" ], "editorial_references": [], "qualification": "Use a validator policy requiring the selected ECDSA producer key under local trust anchors. Success callbacks alone are insufficient: bypassValidation also invokes them. Verify altered content/key/signature rejection; resolve and retain the validated key binding, avoid treating an unchecked KeyLocator or a mutable key name as proof, and keep accepted Data immutable. No execution or freshness guarantee." }, { "id": "F21-AX", "feature": "F21", "stack": "AX", "status": "N", "reason": "The receiving circuit identifies a claimed user/node callsign, not a cryptographically authenticated final peer.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F21-BA", "feature": "F21", "stack": "BA", "status": "N", "reason": "Native frame delivery exposes Ethernet identifiers without cryptographic final-peer proof. An authenticated application or secure adjacent carrier would be a different composition.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-BL", "feature": "F21", "stack": "BL", "status": "N", "reason": "The application receives a source address, not a cryptographically authenticated final identity; no authentication extension is selected.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-RI", "feature": "F21", "stack": "RI", "status": "Y", "reason": "The pinned DTLS 1.3 implementation exposes the selected external-PSK identity on the same WOLFSSL object used for protected application records. The server checks the PSK binder and peer Finished before handshake completion. A receiver can therefore map that authenticated identity to its distinct pairwise credential without another application authentication exchange.", "method": "Source/API provenance and bounded documentary witness; no execution", "source_label": "Pinned wolfSSL source and DTLS 1.3 specification", "sources": [ "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/ssl.c", "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/tls13.c", "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/wolfssl/ssl.h", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round271-sources.json" ], "qualification": "Use one external PSK candidate per connection, unique bounded non-NUL identity strings and distinct pairwise secrets. Call KeepArrays before the handshake; only after successful accept/connect copy get_psk_identity into connection-owned metadata, then FreeArrays. Reject failure, null or unexpected identity; never trust the lookup callback alone. No early data/tickets. Keep metadata bound to that object and discard it at close; a new handshake requires fresh validation. No civil identity, third-party proof, full RPL integration or runtime test is credited." }, { "id": "F21-HP", "feature": "F21", "stack": "HP", "status": "Y", "reason": "The HIP native socket contract exposes the peer HIT with received data: RFC 6317 section 4.1.1 specifies sockaddr_hip returns for recvfrom, and section 4.3 specifies peer-HIT queries. With HIP-only admission and the selected pinned HI/HIT authentication, the receiving application can identify the authenticated host without another login exchange.", "method": "Documentary API and source-path review; no execution", "source_label": "HIP API RFC and pinned CICN implementation source", "sources": [ "https://datatracker.ietf.org/doc/html/rfc6317#section-4.1.1", "https://www.rfc-editor.org/rfc/rfc7401.html#section-3" ], "editorial_references": [ "round272-sources.json" ], "qualification": "Use a specific local HIT or HIP_HIT_ANY, not HIP_ENDPOINT_ANY, which permits unprotected IP fallback. Compare each received peer HIT against the pinned HIPv2 identity; a resolver result or wildcard is not authentication. Keep the API binding to the protected delivery context and discard stale association metadata. RFC 6317 predates HIPv2: preserve its identity-delivery contract while using current HIPv2 HIT generation/prefix, not its historical ORCHID constants. This is a documentary API composition, not a tested final-RFC implementation or a new wire layer." }, { "id": "F21-CX", "feature": "F21", "stack": "CX", "status": "Y", "reason": "For the selected producer-to-consumer role, RFC 8569 defines signature verification and a KeyId derived from the public key. A consumer validating the signed object against its configured trusted producer key can retain that authenticated author-key binding with the content. This supplies a concrete protocol-level basis for the same item-authorship interpretation already credited to NDN and Nostr, without an additional application authentication exchange.", "method": "Documentary plausibility of producer-authorship binding; no executable qualification", "source_label": "CCNx signature semantics and retained implementation-gap review", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-8.4", "https://www.rfc-editor.org/rfc/rfc8569.html#section-8.1" ], "editorial_references": [ "round274-sources.json", "round303-sources.json" ], "qualification": "Architectural plausibility, not a qualified executable. Previously inspected schema-v1 code leaves SetSigner commented out in DictionaryEncode and lacks ECDSA in automatic suite conversion. Those integration gaps remain; this verdict does not assert that the pinned application works unchanged. No runtime, interoperability or security audit was performed. Credit authenticated content authorship only, not a live producer session, serving cache, consumer identity or civil identity. Mere KeyId matching is not verification. Require trusted-key selection, successful signature verification and retention of the validated binding; a parsed identifier alone does not qualify." }, { "id": "F21-LI", "feature": "F21", "stack": "LI", "status": "N", "reason": "An application receives ordinary IP/UDP source addressing. The Map-Server registration key is not an authenticated final-peer identity exposed and bound to the application communication.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-IL", "feature": "F21", "stack": "IL", "status": "N", "reason": "The selected transport exposes a NID, not cryptographically authenticated final-peer identity. A session nonce and checksum do not establish that proof or its application binding.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F21-TS", "feature": "F21", "stack": "TS", "status": "Y", "reason": "For traffic received through the selected Tailscale interface, a receiving application can query LocalAPI WhoIs with the remote address to obtain the authenticated node and its user or tags. No extra remote application-authentication exchange is required.", "method": "Official documentation and pinned source/declaration review; no runtime test", "source_label": "Tailscale identity documentation, LocalAPI and PATENTS grant", "sources": [ "https://tailscale.com/docs/concepts/tailscale-identity", "https://tailscale.com/docs/concepts/tailscale-identity", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/PATENTS", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/LICENSE", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/ipn/localapi/localapi.go", "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round588.html", "round588-sources.json" ], "qualification": "Requires LocalAPI read permission and binding the query to the actual received Tailscale connection. Do not trust an arbitrary user-supplied IP. No subnet or exit-node substitution is selected; this is node identity, not proof of a civil identity or a durable historical attestation." }, { "id": "F21-RA", "feature": "F21", "stack": "RA", "status": "N", "reason": "The selected AuthSSH2 mechanism authenticates IPCP peers using locally pinned keys. The application API rina_flow_accept instead returns remote_appl, the requesting application name. The flow allocator passes remote_naming_info to allocateFlowRequestArrived; its selected default security-manager acceptFlow policy accepts that name without validating a binding to an application credential. This path exposes a flow-associated name, not the authenticated IPCP identity or a verified binding from that identity to the final application name.", "method": "Pinned application API, incoming-flow notification and selected security-policy trace", "source_label": "IRATI application API and default flow security policy", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/wrap/rina-api/include/rina/api.h", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/security-manager-ps.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc" ], "editorial_references": [ "round673.html" ], "qualification": "No for authenticated final-peer identity exposed to the application in the selected composition. The two-host upper DIF can authenticate the remote host IPCP and protect its traffic, but its authenticated identity is not the identity returned by this application API path. This does not assert an exploitable impersonation attack, deny the transport authentication credited in F07, or exclude a different RINA security policy/API. Application authentication or a new identity-binding interface is not silently added. Source inspection, not a runtime or security audit." }, { "id": "F22-PN", "feature": "F22", "stack": "PN", "status": "Y", "reason": "The pinned wire-v4 discovery architecture permits a bounded candidate set under a shared weak alias. Exact discovery resolves authenticated local declarations and each selected result proves its own Strong ID. This supplies independently identified candidates without a common alias signing key or controller. Directional admission, local catalog policy and result limits still apply. This Yes uses the existing weak-alias path, not the successor canonical-text ALIAS wire admission or a claim of implementation completeness.", "method": "Architectural specification analysis; no execution", "source_label": "Pinned PRP discovery architecture §3 and exact discovery §8.1", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-discovery-architecture-v1.md", "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-exact-discovery-v1.md" ], "editorial_references": [], "qualification": "Declare the same weak alias from two independent principals in the selected wire-v4 configuration. Verify distinct bounded results and exact selected-principal authentication, revocation/staleness and policy limits. Do not substitute successor HS2 or SCIR ALIAS encodings. No runtime test performed." }, { "id": "F22-PI", "feature": "F22", "stack": "PI", "status": "Y", "reason": "The pinned wire-v4 discovery architecture permits a bounded candidate set under a shared weak alias. Exact discovery resolves authenticated local declarations and each selected result proves its own Strong ID. This supplies independently identified candidates without a common alias signing key or controller. Directional admission, local catalog policy and result limits still apply. This Yes uses the existing weak-alias path, not the successor canonical-text ALIAS wire admission or a claim of implementation completeness.", "method": "Architectural specification analysis; no execution", "source_label": "Pinned PRP discovery architecture §3 and exact discovery §8.1", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-discovery-architecture-v1.md", "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-exact-discovery-v1.md" ], "editorial_references": [], "qualification": "Declare the same weak alias from two independent principals in the selected wire-v4 configuration. Verify distinct bounded results and exact selected-principal authentication, revocation/staleness and policy limits. Do not substitute successor HS2 or SCIR ALIAS encodings. No runtime test performed." }, { "id": "F22-IP", "feature": "F22", "stack": "IP", "status": "N", "reason": "Anycast routes a packet to one interface of a shared address; multicast delivers to a set. Neither is a native operation returning independently identified participants for selection. No participant-discovery application is included in the standalone IP stack. The negative is not based on a single-owner requirement: anycast does not intrinsically require one organization.", "method": "Selected-stack scope and primary specification analysis", "source_label": "IPv6 addressing architecture §2.6–2.7", "sources": [ "https://www.rfc-editor.org/rfc/rfc4291.html#section-2.6" ], "editorial_references": [], "qualification": "" }, { "id": "F22-BP", "feature": "F22", "stack": "BP", "status": "N", "reason": "BP endpoints can contain multiple nodes under one EID, and the selected profile already credits locally agreed collective names and static forwarding fanout. However, RFC 9171 defines registrations as local state and explicitly provides no mechanism for distributing registration information. Delivery to the preconfigured collective therefore does not expose independently identified participant candidates through that shared reference. BPSec and transport authentication do not supply this missing discovery operation. A request/reply discovery application or an added membership protocol could do so, but neither is selected. This No leaves collective delivery and DTN capabilities unchanged.", "method": "Selected composition and RFC 9171 analysis; no execution", "source_label": "RFC 9171 section 3.1: bundle endpoint and registration", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.1" ], "editorial_references": [], "qualification": "" }, { "id": "F22-CG", "feature": "F22", "stack": "CG", "status": "N", "reason": "The selected singleton BP/SABR profile has supplied destination identifiers and contact plans, but no mechanism to discover independently identified participants behind one shared reference. A contact graph is not such a discovery service.", "method": "Selected-profile boundary and SABR section 2.2; no execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F22-LT", "feature": "F22", "stack": "LT", "status": "N", "reason": "The selected singleton identifiers and supplied contact mappings contain no mechanism for discovering independent participants behind one shared reference.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "CCSDS 734.3-B-1, SABR (2019)", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F22-LP", "feature": "F22", "stack": "LP", "status": "N", "reason": "The declared known-peer QUIC/libp2p composition selects no Rendezvous or provider-routing discovery module. Its known Peer IDs and secure connections do not implement shared-reference multi-peer discovery. The separately specified Rendezvous protocol registers peer records under namespaces and supports discovery, so this No is limited to the current composition, not a claim that libp2p cannot provide an analogous feature. Selecting that module would require an explicit stack revision and review of registration policy and namespace control.", "method": "Selected composition and primary discovery specification analysis", "source_label": "libp2p Rendezvous specification (module boundary)", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/rendezvous/README.md" ], "editorial_references": [], "qualification": "" }, { "id": "F22-TO", "feature": "F22", "stack": "TO", "status": "N", "reason": "A v3 onion address encodes a particular Ed25519 master public identity key. Multiple service instances reached through that address do not make it a nonexclusive discovery reference for independently declaring identities. The reference remains anchored to the service identity; an application directory could add independent participant discovery, but none is selected. This No concerns F22, not anonymity, service replication or the ability to operate independent onion services.", "method": "Primary onion-address specification analysis; no execution", "source_label": "Tor v3 onion address encoding", "sources": [ "https://spec.torproject.org/rend-spec/encoding-onion-addresses.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-I2", "feature": "F22", "stack": "I2", "status": "N", "reason": "An ordinary LeaseSet advertises tunnel entry points for one Destination. Meta LeaseSets go further: they can refer to several Destinations or nested Meta LeaseSets for a common service. However, the list is signed by the root Destination signing key or its authorized transient key. Independent participants cannot add themselves under that reference without its signing authority. Thus even this closer mechanism fails the nonexclusive-reference requirement of F22. The distributed floodfill database does not remove control of the signed record. The structure specification marks MetaLeaseSet preliminary and not fully supported; this decision does not assert deployed availability.", "method": "Primary netDb and MetaLeaseSet signature analysis; no execution", "source_label": "I2P network database: LeaseSets and Meta LeaseSets", "sources": [ "https://i2p.net/en/docs/overview/network-database/", "https://i2p.net/en/docs/specs/common-structures/#metaleaseset" ], "editorial_references": [], "qualification": "" }, { "id": "F22-YG", "feature": "F22", "stack": "YG", "status": "N", "reason": "The selected numeric-peer, pinned-key composition routes toward a specified node identity/address. Yggdrasil documents link-local multicast auto-peering separately and explicitly leaves name/service lookup outside its scope. No shared-interest discovery selector or service directory is selected here. Local auto-peering must not be credited as an arbitrary common-reference participant lookup, nor silently added to the numeric IPv4 peer profile. This No is scoped to the declared composition: it does not deny that Yggdrasil can discover adjacent peers, and it does not exclude application discovery protocols layered above it. Unlike the selected Reticulum aspect filter or Meshtastic channel NodeInfo, this profile provides no corresponding shared-reference participant-discovery witness.", "method": "Selected composition and primary architecture documentation analysis", "source_label": "Yggdrasil implementation: peering and node identification", "sources": [ "https://yggdrasil-network.github.io/implementation.html", "https://yggdrasil-network.github.io/configuration.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-CJ", "feature": "F22", "stack": "CJ", "status": "N", "reason": "The selected route-server design resolves a specified source and target address. Its gr handler looks up that target in the node inventory and returns one destination public key and routing label when a route exists. Replicating announcements and route servers distributes reachability data; it does not turn the query into discovery of independent participants declaring one shared reference. The profile uses private known-peer credentials and no public beacon advertisement. Public peering directories, DNS seeders or an application rendezvous service are not silently added. This No concerns the current composition, not a claim that cjdns cannot transport a discovery application.", "method": "Pinned selected route-server query source analysis; no execution", "source_label": "cjdns route server service.rs: gr query and destination reply", "sources": [ "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server/service.rs#L200" ], "editorial_references": [], "qualification": "" }, { "id": "F22-MQ", "feature": "F22", "stack": "MQ", "status": "N", "reason": "QUIC connection IDs and multiple paths identify or reach a connection with its peer; they do not discover several independent peers from one nonexclusive reference. The selected numeric-peer QUIC/TLS stack includes no rendezvous or service-discovery layer.", "method": "Selected-stack scope and primary specification analysis", "source_label": "QUIC connections and connection identifiers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-5" ], "editorial_references": [], "qualification": "" }, { "id": "F22-SC", "feature": "F22", "stack": "SC", "status": "N", "reason": "SCION service-address resolution uses the control_service and discovery_service instances declared in the AS topology. This reaches configured infrastructure instances rather than independently self-declared participants under a nonexclusive shared reference. The selected numeric application-UDP profile includes no participant rendezvous protocol. As a nearby comparison, SIG Discovery can return several gateways, but those gateways are declared in the AS topology; SIG is not selected here and its administered list would not establish F22 anyway. External DNS/mDNS bootstrap discovery is also not silently added to the numeric profile. Neither service anycast/multicast nor the existence of a discovery service alone meets this criterion.", "method": "Selected composition and primary router/discovery documentation analysis", "source_label": "SCION router manual: topology.json service resolution", "sources": [ "https://docs.scion.org/en/latest/manuals/router.html", "https://docs.scion.org/en/latest/sig.html", "https://docs.scion.org/en/v0.13.0/dev/design/endhost-bootstrap.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-RT", "feature": "F22", "stack": "RT", "status": "Y", "reason": "Independent identities can create SINGLE destinations with the same application/aspect name and sign their own announces. A native announce handler uses that common aspect string as its filter: Transport validates the announcement, recomputes the expected destination hash using each announced identity and passes matching identities and destinations to the callback. Collecting these callbacks yields independent candidates without an exclusive owner of the aspect name or shared identity private key. This is passive discovery from received announcements, not a network-wide query or exhaustive list. GROUP encryption is not the witness. The selected IFAC secret controls access to the transport medium, not ownership of participant identities or the aspect name.", "method": "Reticulum 1.5.5 source and native announce API analysis; no execution", "source_label": "Transport: announce validation and aspect-filter callbacks", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py", "https://reticulum.network/manual/examples.html#example-announce", "https://reticulum.network/manual/understanding.html" ], "editorial_references": [], "qualification": "Use two independently generated identities with the same aspect name and a third observer on the selected serial/IFAC mesh. Check both validated callbacks, reject a wrong-aspect or invalidly signed announcement, deduplicate by full identity and establish a Link to each discovered destination. Measure missed/stale announces separately. No execution performed." }, { "id": "F22-NS", "feature": "F22", "stack": "NS", "status": "Y", "reason": "Independent authors can sign regular events containing the same agreed single-letter tag/value. A REQ tag filter without an authors restriction returns matching events; signature verification and deduplication by author pubkey yield independent candidate identities. No shared private key or exclusive owner of that tag is required. The existing multi-relay profile permits the same reference across relays; moderation controls each relay, not global ownership of the reference. This is author discovery using selected NIP-01 primitives, not IP-style addressing, a live session, exhaustive enumeration or proof of availability. The criterion permits self-declaration and does not require simultaneous delivery.", "method": "Constructive NIP-01 specification analysis; no execution", "source_label": "NIP-01 events, signatures, single-letter tag indexes and REQ filters", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "Publish events signed by two independent keys with the same agreed tag at the two selected relays. Query by tag, validate signatures, deduplicate authors and test missing/stale events and moderation. Verify no extra NIP or shared identity key is required. No live-relay experiment performed." }, { "id": "F22-MT", "feature": "F22", "stack": "MT", "status": "Y", "reason": "The agreed channel configuration provides a shared discovery context. Independently keyed nodes broadcast NodeInfo there; the selected STRICT profile validates signed first-contact NodeInfo using its advertised public key and checks the node-number/key relation. NodeDB retains the separate keys and channel association. Thus received broadcasts yield independent participant candidates without a central membership signer. The channel PSK is a shared access/encryption credential, not a shared private identity. The full channel configuration, not its short packet hash alone, is the reference. This is bounded radio-mesh discovery, not arbitrary global alias lookup. A node number or display name alone is not a cryptographic identity; key confirmation for subsequent sensitive direct messages remains required by the selected profile.", "method": "Pinned firmware source analysis of channels, NodeInfo and signature policy; no radio execution", "source_label": "Meshtastic pinned Router.cpp: verifyFirstContactNodeInfo and checkXeddsaReceivePolicy", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/NodeInfoModule.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NodeDB.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Channels.cpp" ], "editorial_references": [], "qualification": "On the pinned PKI-capable firmware with STRICT policy, configure three nodes on the same private channel and independent endpoint keys. Confirm two signed NodeInfo broadcasts populate distinct full-key records at the observer; reject invalid/unsigned broadcasts and key substitutions. Check channel association, collision handling, stale records and airtime throttling. No hardware experiment performed." }, { "id": "F22-GN", "feature": "F22", "stack": "GN", "status": "N", "reason": "In the selected TRANSPORT/CORE/CADET/R5N composition, CADET publishes and requests LEGACY_HELLO using the peer identity padded into the lookup key; GCD_search requires a known PeerIdentity. The DHT block plugin derives LEGACY_HELLO keys from the contained peer identity and DHT_HELLO keys from its hash. These records locate a particular peer, rather than independent declarations under a shared interest reference. Generic multi-value GET/PUT support alone supplies no selected declaration format and validation semantics. The test block is not an appropriate production witness. GNUnet has a separate REGEX service-discovery subsystem, explicitly documented to return matching providers; it is not selected in this column. This No is strictly a composition boundary, not a project-wide incapability.", "method": "GNUnet 0.20.0 source archive and versioned subsystem documentation analysis; no execution", "source_label": "GNUnet 0.20.0: cadet/gnunet-service-cadet_dht.c and dht/plugin_block_dht.c", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/dht/dht.html", "https://docs.gnunet.org/v0.20.x/developers/regex/regex.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-ND", "feature": "F22", "stack": "ND", "status": "N", "reason": "The selected stock NFD/BestRoute service retrieves Data matching a name or prefix. A matching response satisfies the PIT entry and schedules its expiry; a cache may answer subsequent requests. Several possible producers or FIB next hops do not create a native operation returning a set of independent participants for selection. A discovery catalog, naming/enumeration convention or sync application could add that behavior, but none is selected. Producer-signature verification establishes authorship of the returned object, not the missing participant-discovery operation.", "method": "Pinned NFD 24.07 forwarding and packet specification analysis", "source_label": "NFD 24.07 incoming Data pipeline and NDN v0.3 Interest semantics", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp", "https://docs.named-data.net/NDN-packet-spec/0.3/interest.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-AX", "feature": "F22", "stack": "AX", "status": "N", "reason": "Classic NET/ROM node announcements and mnemonic aliases describe individual node routes. The selected circuit service has no common-reference query returning a set of independent participants; adding a bulletin board or discovery application is outside the composition.", "method": "Selected-stack scope and primary specification analysis", "source_label": "Classic NET/ROM routing and node announcements", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "F22-BA", "feature": "F22", "stack": "BA", "status": "N", "reason": "The selected batman-adv service bridges native Ethernet frames and discovers forwarding reachability. Broadcast or multicast delivery is not a shared-reference participant-discovery operation. No higher-layer discovery protocol is selected.", "method": "Selected-stack scope and primary specification analysis", "source_label": "Linux 6.12 batman-adv service boundary", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-BL", "feature": "F22", "stack": "BL", "status": "N", "reason": "Babel advertises reachable prefixes and IPv6 supplies destination routing. Multiple origins or next hops for a prefix do not constitute a shared-reference discovery operation returning independent final participants. The selected numeric datagram profile adds no discovery application.", "method": "Selected-stack scope and primary specification analysis", "source_label": "Babel prefix routing and IPv6 addressing", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-RI", "feature": "F22", "stack": "RI", "status": "N", "reason": "RPL discovers routing parents and destinations, while the selected DTLS PSKs authenticate already provisioned peers. Neither supplies a shared reference with independent declarations and identity-bound multi-candidate participant lookup.", "method": "Documentary role/state inventory; no runtime test", "source_label": "Primary protocol specifications and unchanged selected compositions", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-9", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round260-sources.json" ], "qualification": "An RPL Instance or DODAG identifier describes routing membership, not the required participant-discovery service. No CoAP discovery or application directory is selected." }, { "id": "F22-HP", "feature": "F22", "stack": "HP", "status": "N", "reason": "The selected HIP composition starts with pinned peer Host Identities/HITs and known locators. Its authenticated base exchange establishes a relationship with that peer; it does not provide shared-reference registration and lookup of multiple independent participant identities.", "method": "Documentary role/state inventory; no runtime test", "source_label": "Primary protocol specifications and unchanged selected compositions", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-4.1", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round260-sources.json" ], "qualification": "No rendezvous or discovery extension is selected. Multiple locators for one Host Identity are not multiple independently identified participants." }, { "id": "F22-CX", "feature": "F22", "stack": "CX", "status": "N", "reason": "CCNx 1.0 matches Interests to named Content Objects. Its exact-name content lookup, producer KeyId restriction and cache fanout do not enumerate independent participant identities under a shared discovery reference. RFC 8569 explicitly places content discovery above this core protocol.", "method": "Documentary role/state inventory; no runtime test", "source_label": "Primary protocol specifications and unchanged selected compositions", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-1", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round260-sources.json" ], "qualification": "Fetching an application-produced participant list would add a discovery application absent from the selected stack. Multiple caches of an object are not independently declared participant candidates." }, { "id": "F22-LI", "feature": "F22", "stack": "LI", "status": "N", "reason": "An EID-prefix mapping returns locators for a registered destination. Multiple RLOCs are not independent participant identities discovered through an unowned shared reference; prefix registration remains administratively controlled.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-IL", "feature": "F22", "stack": "IL", "status": "N", "reason": "DNS NID/L64 records are controlled by the authoritative naming domain. Multiple records do not meet the requirement for discovery without an exclusive controller of the shared reference.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "F22-TS", "feature": "F22", "stack": "TS", "status": "N", "reason": "Peer discovery is scoped by the managed tailnet registry and its authorization policy. A shared tailnet name or policy group remains under that administrative authority, rather than an independently claimed shared discovery reference.", "method": "Official documentation and pinned source inspection; no runtime test", "source_label": "Tailscale control plane and DERP source 566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/concepts/control-data-planes", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round586.html", "round586-sources.json" ], "qualification": "Inference from the declared managed composition. Independently owned node keys do not remove control of the discovery namespace." }, { "id": "F22-RA", "feature": "F22", "stack": "RA", "status": "Y", "reason": "IRATI application registration can advertise a shared DAF name while retaining separate DAP names. The namespace manager stores the particular DAP name as the instance of that DAF entry, allowing multiple participants to register the same shared reference. getDFTNextHop resolves a DAF-only request to a matching nonlocal entry and fills in its individual instance before flow allocation. No common private identity or exclusive owner of the DAF name is required by this registration path.", "method": "Pinned registration, directory-resolution and flow-allocation source inspection", "source_label": "IRATI DAF/DAP registration and shared-name lookup", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/namespace-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round670.html" ], "qualification": "Yes for shared-reference candidate discovery among admitted participants within a DIF. The default resolver returns one candidate at a time and does not guarantee enumeration, fairness or simultaneous delivery. Distinct names identify participants but do not prove legitimate group membership or authenticate final applications. DIF admission and local registration permissions remain prerequisites; this is not an open global namespace or a denial of administrative control over the DIF. Source inspection, not an interoperability or runtime result." }, { "id": "F23-PN", "feature": "F23", "stack": "PN", "status": "Y", "reason": "Relationship continuity is separated from volatile carrier locators and paths. Section 7 specifies authenticating a replacement path, binding it to the existing relationship/direction/generation, validating it, migrating eligible work and draining the old path. Connection aliases, service lanes, ordering, replay and item identities remain unchanged when handover continuity is claimed. This supports moving attachment while preserving the relationship, provided a replacement path is obtainable and authorized. Failure to prove continuity must fail or create a new epoch, not silently pretend continuity. Architectural credit does not demonstrate a carrier-specific mobility controller, automatic discovery at every access point or interruption-free operation.", "method": "Pinned relationship lifecycle specification; architectural capability, no execution", "source_label": "PRP Relationship Lifecycle sections 3 and 7, commit 9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-relationship-lifecycle-v1.md" ], "editorial_references": [], "qualification": "Move the endpoint between two attachment points with the same relationship; establish an authorized replacement path and retain ordering/replay/item state. For PRP over IP also change the UDP/IP locator. Verify remote peer continuity and no application relationship restart; measure interruption, loss and stale-path rejection. Start with make-before-break; break-before-make and simultaneous endpoint movement require separate qualification. No handover experiment performed." }, { "id": "F23-PI", "feature": "F23", "stack": "PI", "status": "Y", "reason": "Relationship continuity is separated from volatile carrier locators and paths. Section 7 specifies authenticating a replacement path, binding it to the existing relationship/direction/generation, validating it, migrating eligible work and draining the old path. Connection aliases, service lanes, ordering, replay and item identities remain unchanged when handover continuity is claimed. This supports moving attachment while preserving the relationship, provided a replacement path is obtainable and authorized. Failure to prove continuity must fail or create a new epoch, not silently pretend continuity. Architectural credit does not demonstrate a carrier-specific mobility controller, automatic discovery at every access point or interruption-free operation.", "method": "Pinned relationship lifecycle specification; architectural capability, no execution", "source_label": "PRP Relationship Lifecycle sections 3 and 7, commit 9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-relationship-lifecycle-v1.md" ], "editorial_references": [], "qualification": "Move the endpoint between two attachment points with the same relationship; establish an authorized replacement path and retain ordering/replay/item state. For PRP over IP also change the UDP/IP locator. Verify remote peer continuity and no application relationship restart; measure interruption, loss and stale-path rejection. Start with make-before-break; break-before-make and simultaneous endpoint movement require separate qualification. No handover experiment performed." }, { "id": "F23-IP", "feature": "F23", "stack": "IP", "status": "N", "reason": "The previous Yes gave the endpoint a BGP routing role and authority to advertise a retained prefix at provisioned peers. That is administrative routing-domain relocation and fails the corrected endpoint criterion. The selected IP/BGP composition does not provide an ordinary host with locator-independent continuity when it changes access and address. Executing BGP on the same machine does not confer authority for its advertisements to be accepted. Mobile IP or a migration-capable transport could change the result, but neither is selected in this column. Same-link movement hidden by another layer is not credited as an IP mobility mechanism.", "method": "Corrected endpoint-role criterion; primary specification review", "source_label": "RFC 4271: BGP routing role; RFC 5944: distinct mobility extension", "sources": [ "https://www.rfc-editor.org/rfc/rfc4271.html", "https://www.rfc-editor.org/rfc/rfc5944.html" ], "editorial_references": [], "qualification": "" }, { "id": "F23-BP", "feature": "F23", "stack": "BP", "status": "Y", "reason": "A mobile bundle endpoint can retain its EID and pending bundles while changing access contacts. Under a policy that retains rather than fails pending forwarding, BP permits later forwarding without application resubmission. A bounded witness uses provisioned numeric contacts at both attachments and the same NODE-ID credentials: the convergence-layer TCP/TLS session can be rebuilt without replacing the bundle identity or application endpoint. The selected NODE-ID authentication separates that identity from a changing IP locator. Credit concerns continued bundle delivery, not TCP stream migration or automatic discovery of an arbitrary new contact. Retention policy, reachability and bundle lifetime remain conditions.", "method": "Primary documentation and bounded selected-profile inference; no execution", "source_label": "RFC 9171 sections 4.2.5 and 5.4; RFC 9174 node authentication", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4.3" ], "editorial_references": [], "qualification": "Provision both contacts and retained EID/NODE-ID credentials. Interrupt a transfer, move the endpoint and establish TCPCL at the new contact; verify delivery of the original pending bundle without resubmitting its application data. Record restart of partial CL transfer, routing decisions, duplicate handling and expiry." }, { "id": "F23-CG", "feature": "F23", "stack": "CG", "status": "Y", "reason": "A bounded planned-mobility witness qualifies under the existing F23 criterion, consistently with F23-BP. A mobile bundle endpoint keeps its EID, final-peer BPSec keys and pending bundle store while leaving access node A and later attaching to access node B. Both contacts, their native link bindings and the onward path to the same destination are provisioned before movement. SABR sections 2.2-2.3 represent changing adjacency with timed contacts between stable node numbers and compute routes from those plans, without requiring the mobile participant to originate infrastructure prefixes or modify the infrastructure during the move. RFC 9171 sections 5.4 and 5.4.1 permit retaining pending forwarding and resuming it when forwarding becomes possible. The original pending application data is delivered without application resubmission. The new contact establishes the selected TCPCLv4/TLS 1.3 connection using provisioned numeric peers and the retained NODE-ID credentials. A new convergence-layer session does not replace the BP endpoint or pending bundle identity.", "method": "Bounded selected-profile architectural inference and cross-column consistency; no execution", "source_label": "RFC 9171 retention; SABR timed node contacts; selected native convergence-layer specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4.1", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4.3" ], "editorial_references": [ "round367-sources.json", "round367-witness.json" ], "qualification": "This is a documentary constructive inference for scheduled movement and retained bundle delivery, not arbitrary-access discovery, seamless stream migration, lossless handover or an executed integrated-stack test. Require live persistent BP state, adequate storage, a retain-not-fail policy, bundle lifetime beyond the next contact, usable preprovisioned native links and correct schedules/clocks. An expired or deleted bundle is not recovered by this witness. No critical-bundle replication, custody extension or SAGA/IPND discovery is needed. The earlier demand for a live discovery adapter was too broad for this planned-contact role; its integration gaps remain relevant to unplanned mobility and E03, but do not block this architectural F23 Yes. No profile, criterion or external routing authority is added. TCPCL reconnection and any partial-transfer restart remain below the application. No claim that a TCP connection survives changing IP attachment." }, { "id": "F23-LT", "feature": "F23", "stack": "LT", "status": "Y", "reason": "A bounded planned-mobility witness qualifies under the existing F23 criterion, consistently with F23-BP. A mobile bundle endpoint keeps its EID, final-peer BPSec keys and pending bundle store while leaving access node A and later attaching to access node B. Both contacts, their native link bindings and the onward path to the same destination are provisioned before movement. SABR sections 2.2-2.3 represent changing adjacency with timed contacts between stable node numbers and compute routes from those plans, without requiring the mobile participant to originate infrastructure prefixes or modify the infrastructure during the move. RFC 9171 sections 5.4 and 5.4.1 permit retaining pending forwarding and resuming it when forwarding becomes possible. The original pending application data is delivered without application resubmission. The new contact uses its preprovisioned LTP engine mapping, Encapsulation binding and AOS virtual channel. An all-red LTP transfer on the new adjacent link carries the retained BP bundle; neither the BP source/destination identity nor final-pair BPSec keys depend on retaining the former LTP session.", "method": "Bounded selected-profile architectural inference and cross-column consistency; no execution", "source_label": "RFC 9171 retention; SABR timed node contacts; selected native convergence-layer specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4.1", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [ "round367-sources.json", "round367-witness.json" ], "qualification": "This is a documentary constructive inference for scheduled movement and retained bundle delivery, not arbitrary-access discovery, seamless stream migration, lossless handover or an executed integrated-stack test. Require live persistent BP state, adequate storage, a retain-not-fail policy, bundle lifetime beyond the next contact, usable preprovisioned native links and correct schedules/clocks. An expired or deleted bundle is not recovered by this witness. No critical-bundle replication, custody extension or SAGA/IPND discovery is needed. The earlier demand for a live discovery adapter was too broad for this planned-contact role; its integration gaps remain relevant to unplanned mobility and E03, but do not block this architectural F23 Yes. No profile, criterion or external routing authority is added. No UDP, IPND, TCPCL or TCP is inserted into this column. LTP is not credited with moving one live session between arbitrary engines. The conservative witness retains a pending BP bundle across the gap and starts its native transfer at the new contact; complete LTP/Encapsulation/AOS executable integration is still not qualified." }, { "id": "F23-LP", "feature": "F23", "stack": "LP", "status": "Y", "reason": "The selected libp2p transport uses QUIC with TLS peer authentication. QUIC client migration can preserve the authenticated connection and its streams across a client access/address change, retaining the libp2p peer relationship. Credit is architectural and conditional on migration support, nonzero usable connection IDs, retained connection state and peer permission, as for the separate QUIC column. It is not evidence that every libp2p implementation enables migration. Reconnecting, DCUtR connection replacement and transferring streams to a new connection are distinct and are not credited here.", "method": "Selected transport composition and primary specifications; no execution", "source_label": "libp2p QUIC transport and RFC 9000 migration", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html#section-9" ], "editorial_references": [], "qualification": "Pin a libp2p QUIC implementation and check whether active migration is enabled and exposed. Move the initiating peer between access networks during an existing stream; verify the same connection/peer binding without stream recreation. Test disabled migration and timeout. No execution performed." }, { "id": "F23-TO", "feature": "F23", "stack": "TO", "status": "Y", "reason": "The declared profile already includes optional Conflux onion-service resumption as design. A client changing access can rebuild paths to the same service and associate them with the retained circuit set using its secret nonce and sequence state. Buffered missing data can be retransmitted, including after both legs disappear, preserving the logical stream. This supplies an architectural mobility witness; it does not establish deployed Tor support. Section 2.7 explicitly says full resumption is not supported in C-Tor. Retained endpoint state, adequate buffering and a reachable service are required; memory pressure or unrecoverable loss can terminate the set.", "method": "Architectural inference from selected optional design; no execution", "source_label": "Tor proposal 329, sections 2.3, 2.4 and 2.7", "sources": [ "https://spec.torproject.org/proposals/329-traffic-splitting.html" ], "editorial_references": [], "qualification": "Identify an implementation of full onion-service resumption. Change the client access/address while keeping its local application connection alive; verify stream identity, ordering and recovery after both legs close. Exercise buffer exhaustion and timeout. Ordinary C-Tor cannot be assumed to pass this experiment." }, { "id": "F23-I2", "feature": "F23", "stack": "I2", "status": "Y", "reason": "A co-located client/router can retain its Destination and local I2CP session while changing external NTCP2 access. With UDP transport disabled, NTCPTransport accepts external-address updates and rebuilds RouterInfo separately from the local client session. TunnelPool replaces failed tunnel leases, while ClientConnectionRunner requests updated LeaseSets using existing SessionParams. This supplies a bounded witness with overlapping reachable access and timely replacement tunnels, without recreating the application Destination session. It does not preserve the old external TCP connection or establish streaming continuity: no streaming extension is selected. Retained router/client processes and usable peers at the new access are prerequisites.", "method": "Pinned Java source and I2CP specification; bounded architectural inference, no execution", "source_label": "I2P commit 37039e6594f1372368f0c1cf8258cdaf805a7fb4: NTCPTransport, TunnelPool and ClientConnectionRunner", "sources": [ "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/transport/ntcp/NTCPTransport.java", "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/tunnel/pool/TunnelPool.java", "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/client/ClientConnectionRunner.java", "https://i2p.net/en/docs/specs/i2cp/" ], "editorial_references": [], "qualification": "Run the pinned build with NTCP2 only and the selected private-network settings. Keep the local I2CP session alive, introduce the new access, renew multi-hop tunnels and leases, then remove the old access. Verify unchanged Destination/session ID and continuing message exchange without CreateSession. Measure losses and deadlines; test total tunnel loss and repeated LeaseSet negotiation failure, which can disconnect the client. No experiment performed." }, { "id": "F23-YG", "feature": "F23", "stack": "YG", "status": "Y", "reason": "A moving Yggdrasil node retains its key-derived IPv6 address while establishing new adjacent peerings. Routing resolves paths toward that identity independently of the underlying TCP/TLS peering addresses; the documented design explicitly handles node mobility. With the process, TUN interface and application UDP endpoint retained, path replacement need not recreate the application peer relationship. The witness uses reachable, preconfigured adjacent numeric peers in the selected private mesh; it does not import public peers or automatic peer exchange. This is architectural credit, not a measured handover or a guarantee that every interruption is survivable.", "method": "Primary documentation and bounded selected-profile inference; no execution", "source_label": "Yggdrasil implementation: identity and path recovery", "sources": [ "https://yggdrasil-network.github.io/implementation.html" ], "editorial_references": [], "qualification": "Using the pinned Ironwood composition, move one endpoint between two configured adjacent peers, preserving keys, TUN and UDP socket. Verify bidirectional delivery and unchanged IPv6 addresses; exercise stale paths, make-before-break, complete peering loss and recovery time." }, { "id": "F23-CJ", "feature": "F23", "stack": "CJ", "status": "Y", "reason": "A moving native cjdns endpoint can retain its key-derived IPv6 address and inner CryptoAuth session while its path labels change. getSession looks up the existing session by IPv6 identity and updates its path rather than allocating a new cryptographic session. Pathfinder updates use that function; successfully decrypted incoming traffic also teaches a new return path. With new authorized peerings and a usable path obtained through the selected routing system, the same local UDP endpoint can continue communicating. This is a bounded architectural witness with retained processes and state, not a claim that stable addressing alone supplies mobility. It does not establish automatic enrollment at arbitrary access networks or continuity after session expiry.", "method": "Pinned source analysis and bounded architectural inference; no execution", "source_label": "cjdns SessionManager.c, commit c1d3824ef165f98465e044c1079c1aa82609c676", "sources": [ "https://github.com/cjdelisle/cjdns/blob/c1d3824ef165f98465e044c1079c1aa82609c676/net/SessionManager.c" ], "editorial_references": [], "qualification": "Move the native endpoint between configured UDP peerings while preserving its process, key, TUN and application socket. Observe pathfinder/route-server updates, new labels and the same inner session/handles before timeout. Check both directions, stale labels, loss and CryptoAuth reset behavior. Pin a complete executable build; source inspection alone does not qualify deployment or seamless handover." }, { "id": "F23-MQ", "feature": "F23", "stack": "MQ", "status": "Y", "reason": "QUIC connection IDs permit an established client connection and its streams to continue when the client changes network path/address, with validation of the new path. This is a supported endpoint-mobility case within the selected multipath-QUIC stack, without needing to credit simultaneous paths. Credit assumes a confirmed handshake, usable connection IDs, retained connection state and a peer permitting active migration. Base RFC 9000 client migration does not establish arbitrary server migration or simultaneous movement of both endpoints. Loss and timeout remain possible.", "method": "RFC 9000 migration capability in selected QUIC composition; no execution", "source_label": "RFC 9000 sections 5.1 and 9", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9" ], "editorial_references": [], "qualification": "Pin the multipath-21 implementation and migration configuration. Move the client to a new local IP/access network during active streams; verify validation and stream continuity without a new TLS/application relationship. Test migration-disabled and timeout cases; measure outage and loss. No runtime test performed." }, { "id": "F23-SC", "feature": "F23", "stack": "SC", "status": "N", "reason": "The previous Yes moved an entire authorized AS and its control services with the endpoint. That grants infrastructure administration rather than ordinary endpoint mobility and is excluded. In the selected SCION/UDP composition, moving a host into another AS changes its ISD-AS/host endpoint tuple. Selecting a different path to the same AS does not provide relocation of that host identity. SCION leaves intra-AS routing outside its scope, and the selected underlay does not add a host-mobility mechanism. This No is for the declared composition, not a claim that SCION cannot carry a separate mobility-capable transport.", "method": "Corrected endpoint-role criterion; primary specification review", "source_label": "SCION overview: endpoint tuple and routing scope", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "F23-RT", "feature": "F23", "stack": "RT", "status": "N", "reason": "The selected active Link over serial interfaces is bound to its attached interface and established per-hop Link-table entries. Sending uses that interface, and Link reception rejects another interface. Announce/path discovery updates destination reachability, not the active Link bindings. The apparent LRPROOF rebalancing mechanism is establishment-time: transit hop adjustment requires an unvalidated entry, and endpoint proof validation operates while the Link is PENDING. It is not an active-Link handover mechanism. Thus the selected stack does not supply migration of ongoing Link communication to a new attachment path without Link establishment. This does not deny stable destination identity, reconnection, or movement that leaves the same logical attachment/path intact; unselected radio or lower-layer roaming mechanisms are not credited.", "method": "Reticulum 1.5.5 Link and Transport source trace; no execution", "source_label": "Reticulum 1.5.5 Link.py and Transport.py", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [], "qualification": "" }, { "id": "F23-NS", "feature": "F23", "stack": "NS", "status": "N", "reason": "NIP-01 subscriptions belong to individual WebSocket connections and end when the connection closes. In the selected WSS stack, an access change that breaks those connections requires new connections and new REQ messages; reusing a subscription identifier does not resume the previous subscription. This fails F23 continuity of ongoing logical communication. Author keys and signed events remain valid, and a new request can retrieve retained events with time filters. Those are valuable identity and history properties, but are not subscription migration. Two relays do not remove this lifecycle rule when both connections are lost. This No does not claim that mobile Nostr clients cannot reconnect or recover history.", "method": "Selected NIP-01 subscription lifecycle; no execution", "source_label": "Nostr NIP-01, Communication between clients and relays", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "F23-MT", "feature": "F23", "stack": "MT", "status": "Y", "reason": "The selected radio endpoint can change relay neighborhoods while keeping its node identity and confirmed public key. Directed-message routing learns a next hop but falls back to managed flooding when that route stops working. The pinned NextHopRouter retransmission path clears the next-hop preference and resends the retained packet through FloodingRouter on its final attempt. Thus an in-flight message can reach the same endpoint through its new neighborhood without a new peer relationship. This covers radio mobility inside a reachable mesh with compatible radio/channel settings, not continuous media, unlimited retry or delivery through a prolonged partition.", "method": "Primary documentation and bounded selected-profile inference; no execution", "source_label": "Meshtastic mesh algorithm and pinned next-hop retransmission implementation", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [], "qualification": "Move the pinned Alpha radio endpoint out of range of its learned next hop while a direct message awaits acknowledgement. Verify the same message ID, destination and verified key through flood fallback. Measure airtime, duplicates and delivery before retry exhaustion; no production or scale qualification is inferred." }, { "id": "F23-GN", "feature": "F23", "stack": "GN", "status": "Y", "reason": "The selected UDP TRANSPORT has explicit connected-neighbor address switching: it tests an alternative session with SYN, then adopts it on SYN_ACK while retaining the peer identity. The UDP plugin can create a session for a new address associated with that peer; this association still requires higher-layer validation/authentication. CADET separately retains channels and tunnel state above connections: connection loss removes a connection binding, and new paths are offered to the existing tunnel. Together these supply a bounded moving-endpoint witness with overlapping reachable access, known contacts and retained processes. This is more than stable identity alone. It does not establish automatic discovery at arbitrary attachments or successful recovery after every outage.", "method": "GNUnet 0.20.0 source trace; bounded architectural inference, no execution", "source_label": "GNUnet 0.20.0: UDP plugin, TRANSPORT neighbours and CADET peer/tunnel lifecycle", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Pin a complete GNUnet 0.20.0 runtime. Establish a CADET channel, introduce a validated second UDP locator while the old access remains available, observe ATS selection and SWITCH_SYN_SENT/SYN_ACK completion, then remove the old access. Verify unchanged peer/channel, continued traffic and no application channel recreation. Test stale contacts, failures and timeouts separately; no mobility experiment performed." }, { "id": "F23-ND", "feature": "F23", "stack": "ND", "status": "Y", "reason": "A consumer can continue fetching the same named, signed data after changing its Ethernet attachment. Interests issued or retransmitted at the new attachment establish fresh reverse paths, while content names and producer-key validation remain unchanged. This is recovery of per-packet requests within the existing retrieval, not establishment of a new persistent peer subscription. No stable authenticated consumer identity is claimed: the selected profile authenticates the producer. The witness requires preconfigured NFD faces/FIB reachability at both attachments and ordinary Interest retransmission; it does not establish producer mobility, automatic face discovery or migration of old PIT entries.", "method": "Primary documentation and bounded selected-profile inference; no execution", "source_label": "NDN technical report NDN-0013, section 4.4: mobile consumers", "sources": [ "https://named-data.net/techreport/TR013-mobility.pdf" ], "editorial_references": [], "qualification": "Move a consumer with its local application/Unix face retained between two preconfigured Ethernet attachments. Keep name and trust anchor fixed; retransmit an unanswered Interest after the move and verify Data on the new reverse path. Inspect suppression/PIT timeout and loss. Producer movement requires a separate mechanism." }, { "id": "F23-AX", "feature": "F23", "stack": "AX", "status": "Y", "reason": "A NET/ROM node hosting a local endpoint can retain its callsign/SSID and transport circuit while changing its radio crosslink neighbors. Network forwarding selects next hops by destination callsign, while the separate circuit manager retains circuit identifiers, sequence state and end-to-end retransmission. Route announcements and crosslink replacement can therefore restore reachability to the moving circuit endpoint without a new CONNECT. This architectural witness requires convergence before retry/idle limits and retained local circuit state. It does not cover an AX.25 terminal moving between different gateway nodes: that terminal uplink is a distinct connection. Callsigns are not cryptographic authentication.", "method": "Primary documentation and bounded selected-profile inference; no execution", "source_label": "NET/ROM 1.3: circuit manager, routing manager and crosslinks", "sources": [ "https://hamgate.ampr.org/docs/1987_netrom_version_1_3.pdf" ], "editorial_references": [], "qualification": "Pin an executable NET/ROM implementation. Move the node hosting the circuit endpoint between radio neighbors while keeping its process, callsign and local terminal attached. Verify unchanged circuit IDs and sequence continuity after route updates; test timeout, stale routes and crosslink failure. No radio experiment performed." }, { "id": "F23-BA", "feature": "F23", "stack": "BA", "status": "Y", "reason": "An attached Ethernet client can move between mesh attachment nodes while retaining its MAC/VLAN identity. Local learning detects the move, sends a roaming advertisement to the former originator, and updates translation-table ownership; the receive path updates the global client entry and forwarding handles the old local entry marked roaming. This preserves the L2 endpoint and frame service without requiring an application peer relationship restart. The witness is attached-client roaming within one mesh/VLAN, not arbitrary inter-network mobility or migration of the mesh originator itself. MAC identity is not cryptographic authentication. Loss, convergence delay, client isolation and upper-layer timeouts still limit continuity.", "method": "Linux 6.12 translation-table and forwarding source analysis; no execution", "source_label": "Linux 6.12 batman-adv client roaming and translation table", "sources": [ "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/batman-adv/translation-table.c?h=v6.12", "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/batman-adv/routing.c?h=v6.12" ], "editorial_references": [], "qualification": "With Linux 6.12, move a native Ethernet client retaining MAC/VLAN between two mesh attachment nodes during bidirectional traffic. Verify roaming advertisements, translation-table ownership and continued frame delivery, including traffic through the old node. Pin IV/V for execution, measure delay/loss and test rapid moves and isolation settings. No live mesh test performed." }, { "id": "F23-BL", "feature": "F23", "stack": "BL", "status": "N", "reason": "The selected IP/Babel profile uses provisioned interfaces and locally assigned ULA prefixes. Appendix E reduces forwarding and state requirements, but its stub still originates directly attached prefixes. Retaining an endpoint IP across attachments through that mechanism therefore still requires accepted prefix origination, which corrected F23 excludes. Ordinary access permission alone does not grant that role. This No is a scope inference, not a denial of Babel mobile-node reconvergence: that works when the node participates in routing with its retained prefix. No separate host-mobility mechanism is selected. Automatic updates after initial provisioning do not remove the routing authority prerequisite.", "method": "Documentary inference for the selected profile under corrected F23; no runtime test", "source_label": "RFC 8966 Appendix E (stub role), Appendix C (route filtering), section 1.1 (mobility)", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-E" ], "editorial_references": [], "qualification": "" }, { "id": "F23-RI", "feature": "F23", "stack": "RI", "status": "Y", "reason": "A bounded same-subnet leaf move can preserve the selected communication: RFC 6550 Appendix A.4 permits a subnet-wide prefix, section 16.2 permits leaf DAO signaling, and section 9.7 reports changed parent sets to the root for downward source-route reconstruction. RFC 6775 section 5.5 registers an existing address with a newly discovered router. Retaining that address, UDP ports, pairwise credential and live DTLS association avoids a new peer relationship or application reconstruction.", "method": "Bounded documentary composition and source-path analysis; no runtime execution", "source_label": "Primary RPL/6LoWPAN RFCs and pinned Athena source", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.7", "https://www.rfc-editor.org/rfc/rfc6550.html#appendix-A.4", "https://www.rfc-editor.org/rfc/rfc6550.html#section-16.2", "https://www.rfc-editor.org/rfc/rfc6775.html#section-5.5", "https://www.rfc-editor.org/rfc/rfc6552.html" ], "editorial_references": [ "round275-sources.json" ], "qualification": "Documentary composition, not an executed handover. Limit this witness to an admitted leaf physically moving between reachable parents in the same non-storing RPL DODAG, prefix and radio access domain. Enable updated DAO emission on parent change and complete neighbor registration; retain identity, interface/address and DTLS state through the interruption. The leaf advertises its own reachability, not an infrastructure prefix or AS. No changed-prefix or inter-domain move, lossless timing, arbitrary-speed mobility or new attachment implementation is qualified. CID is unnecessary for this unchanged locator/port witness; F08 retains its separately qualified changed-path mechanism." }, { "id": "F23-HP", "feature": "F23", "stack": "HP", "status": "Y", "reason": "RFC 8046 section 3.2.1 lets a moving host notify its reachable peer of a new locator with authenticated UPDATE/LOCATOR_SET signaling and address verification. The Host Identity and existing communication context remain; the endpoint need not originate infrastructure prefixes or administer routing.", "method": "Selected-profile documentary review; no mobility experiment", "source_label": "HIP host mobility and DTLS 1.3 primary specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-3.2.1" ], "editorial_references": [ "round261-sources.json" ], "qualification": "Bounded to one moving endpoint with a reachable known peer and retained HIP/ESP state. Normal address acquisition and access permission remain necessary. No simultaneous-mobility, lossless-handover or executed integration claim." }, { "id": "F23-CX", "feature": "F23", "stack": "CX", "status": "Y", "reason": "A bounded moving-consumer composition closes the earlier UDP-rebinding gap. Athena _UDPOpenConnection leaves the datagram socket unbound when no source is configured and _sendBuffer uses sendto, without connect or a device binding. Linux IPv4 UDP then performs route/source selection for each unconnected send. Keep the same numeric remote forwarder reachable through both ordinary access networks and change the local attachment through normal access provisioning, with a usable route throughout. The remote Athena listener demultiplexes the new source tuple into a new link automatically; PIT processing adds a new ingress for an existing Interest. The local name-prefix FIB, consumer retrieval window, content names and trusted producer key stay unchanged. Existing RTA Vegas timers re-express pending segments within the retained session. The source-level composition supports consumer mobility without application reconstruction or infrastructure prefix/AS authority.", "method": "Bounded architectural source composition; no new mobility experiment", "source_label": "Pinned Athena UDP/PIT, RTA retained retrieval and Linux IPv4 source-selection code", "sources": [ "https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_TransportLinkModuleUDP.c", "https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_PIT.c", "https://github.com/PARC/Libccnx-transport-rta/blob/031a0b7df65a4e00fb96bcf381a7cd4cdbedea62/ccnx/transport/transport_rta/components/Flowcontrol_Vegas/vegas_Session.c", "https://github.com/torvalds/linux/blob/v6.12/net/ipv4/udp.c", "https://github.com/torvalds/linux/blob/v6.12/net/ipv4/route.c" ], "editorial_references": [ "round372-sources.json", "round372-witness.json" ], "qualification": "This is a documentary make-before-break witness, not a newly executed end-to-end integration. Preserve the local consumer/forwarder IPC and processes; omit a fixed local IP/device binding. The far forwarder must remain reachable and accept the new UDP source. Athena marks the link erroneous for send failures other than EAGAIN/EINTR, so the witness excludes ENETUNREACH and other fatal socket errors during transition. It does not establish arbitrary outage recovery, producer mobility, changed remote-forwarder discovery, simultaneous mobility or lossless handover. Normal endpoint address/default-route provisioning is allowed; no infrastructure route changes or new CCNx FIB configuration occur at the move. CCNx has no selected authenticated consumer identity: preserved peer identity here is the content name/trusted producer key, not a newly invented client credential. Existing E03/signature-integration qualifications remain unchanged." }, { "id": "F23-LI", "feature": "F23", "stack": "LI", "status": "N", "reason": "For the selected ordinary IPv4/UDP host behind provisioned xTRs, EID reachability is managed by the infrastructure. The base profile provides no endpoint attachment-update procedure that preserves communication across arbitrary new access networks. RFC 9301 section 8.2 points to LISP-MN for individual-device mobility.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.2", "https://www.rfc-editor.org/rfc/rfc9300.html#section-4" ], "editorial_references": [], "qualification": "No for this endpoint role and composition, not all LISP deployments. Site relocation, infrastructure-assisted roaming and a separately selected mobile-node extension must not be confused with this baseline. No movement test performed." }, { "id": "F23-IL", "feature": "F23", "stack": "IL", "status": "Y", "reason": "A mobile host learns a new Locator from Router Advertisements and sends Locator Updates to its correspondent, preserving its NID and active upper-layer session. This endpoint role does not require the host to originate infrastructure routes or administer an AS (RFC 6740 section 6.2; RFC 6743).", "method": "Specification review", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6743.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "Documented architectural capability only. Pin and execute an ILNPv6/TCP implementation across two authorized attachments with overlapping connectivity; verify Locator Updates and retention of the same TCP connection. No measured lossless handover, simultaneous endpoint movement or deployment certification is claimed." }, { "id": "F23-TS", "feature": "F23", "stack": "TS", "status": "Y", "reason": "Stable overlay addressing, retained node identity and automatic endpoint/path updates permit an ordinary node to change access networks while retaining logical peer communication. No infrastructure prefix or AS administration is required.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "Architectural inference from stable overlay addressing, WireGuard roaming and Tailscale path failover. Requires usable new connectivity and retained endpoint state; no lossless handover or unlimited interruption claim." }, { "id": "F23-RA", "feature": "F23", "stack": "RA", "status": "Y", "reason": "The mobile endpoint locally drives attachment and DIF enrollment across the configured providers while retaining upper application communication. The application does not reconstruct the relationship, and the procedure does not require the endpoint to administer provider routes or originate infrastructure prefixes.", "method": "Primary tutorial, configuration and implementation-source assessment; no execution", "source_label": "IRATI native bootstrap and two-provider mobility documentation", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Tutorial-10%3A-DMM-two-providers-ARCFIRE-2018.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/ipcm.conf", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/internet.dif", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcm/addons/mobility-manager.cc" ], "editorial_references": [ "round658.html" ], "qualification": "Documentary and source-level evidence, not a local rerun. The witness uses a configured two-interface make-before-break handover. Abrupt outage recovery, lossless operation, simultaneous movement of both peers and arbitrary provider admission are not established. Local privileged setup is disclosed; it is not infrastructure route-administration authority." }, { "id": "F24-PN", "feature": "F24", "stack": "PN", "status": "Y", "reason": "PRP architecture section 8.2 explicitly requires the DTN realization to negotiate participant availability windows, including short intervals, for energy-saving transmission and inactivity between communication opportunities. This supplies coordinated receiving opportunities rather than merely restarting a session after sleep.", "method": "Primary documentary assessment under revised criterion; no runtime experiment", "source_label": "Pinned PRP architecture worktree and IP RFCs", "sources": [], "editorial_references": [ "round488-sources.json", "round460-sources.json", "cells/F27-PN.html", "round488.html", "round488-sources.json" ], "qualification": "Architectural capability credit, using the same documentary threshold as F27; not an implemented wake scheduler. The current worktree amendment is pinned separately from its base commit. Negotiation procedures, timing encodings, clock tolerance, update/expiry and control/cover behavior remain unspecified here. Carrier support is required. No radio wake precision, energy saving, preserved live session or guaranteed retained-packet delivery is demonstrated. Custody alone and old F24 reenrollment evidence are not the basis of this Yes." }, { "id": "F24-PI", "feature": "F24", "stack": "PI", "status": "Y", "reason": "PRP architecture section 8.2 explicitly requires the DTN realization to negotiate participant availability windows, including short intervals, for energy-saving transmission and inactivity between communication opportunities. This supplies coordinated receiving opportunities rather than merely restarting a session after sleep.", "method": "Primary documentary assessment under revised criterion; no runtime experiment", "source_label": "Pinned PRP architecture worktree and IP RFCs", "sources": [], "editorial_references": [ "round488-sources.json", "round460-sources.json", "cells/F27-PI.html", "round488.html", "round488-sources.json" ], "qualification": "Architectural capability credit, using the same documentary threshold as F27; not an implemented wake scheduler. The current worktree amendment is pinned separately from its base commit. Negotiation procedures, timing encodings, clock tolerance, update/expiry and control/cover behavior remain unspecified here. Carrier support is required. For PRP over IP, this does not schedule the underlying radio or suppress unrelated IP traffic. No radio wake precision, energy saving, preserved live session or guaranteed retained-packet delivery is demonstrated. Custody alone and old F24 reenrollment evidence are not the basis of this Yes." }, { "id": "F24-IP", "feature": "F24", "stack": "IP", "status": "N", "reason": "The selected IPv4/IPv6 datagram and ICMP composition provides packet forwarding and error/control messages, but no sender/receiver agreement scheduling delivery at endpoint wake opportunities. Retaining an address and refreshing neighbor state on wake does not provide the revised reception-coordination service.", "method": "Primary documentary assessment under revised criterion; no runtime experiment", "source_label": "Pinned PRP architecture worktree and IP RFCs", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html", "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [ "round488.html", "round488-sources.json" ], "qualification": "No eDRX, IEEE 802.11 power-save service, scheduled link binding or application rendezvous protocol is selected. Such lower-layer mechanisms can carry IP and could qualify in an explicitly expanded composition; this No is not a claim that IP devices cannot sleep. Queuing and ordinary neighbor retries alone do not establish a known receive opportunity." }, { "id": "F24-BP", "feature": "F24", "stack": "BP", "status": "N", "reason": "BPv7 retention and TCPCLv4 session policies support disrupted connectivity, but the selected Secure DTN composition includes no shared receiver availability schedule. TCPCL active-only periodic polling discovers transfer opportunities by opening a connection; it does not tell a sleeping receiver in advance when to listen.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "SABR contact plans, LTP operating schedules and BP/TCPCL", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-3.5", "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [ "round506.html", "round506-sources.json" ], "qualification": "Bundles can wait for a later connection subject to expiry and storage constraints. That alone does not coordinate delivery with planned sleep. A supplied contact schedule and matching link management could provide the missing behavior, as evaluated separately in CGR/SABR and LTP columns; those components are not selected here. No claim that BP prohibits such extensions or that custody is necessary for every scheduled delivery." }, { "id": "F24-CG", "feature": "F24", "stack": "CG", "status": "Y", "reason": "Architectural capability with the supplied contact/range plans already selected for this composition. SABR defines contacts by sending and receiving nodes, start/end times and rate, and assumes communication plans known to participants. A planned final-hop contact therefore provides a known receiving opportunity; BP can retain bundles until that contact and routing accounts for its timing.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "SABR contact plans, LTP operating schedules and BP/TCPCL", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [ "round506.html", "round506-sources.json" ], "qualification": "Bounded witness: provision coherent plans to the sender, receiver and final-hop forwarder, and use the receiver operating schedule to activate its link for the corresponding arrival interval, including propagation delay, clock error and setup/drain guards. Local link management must enforce that schedule for data and required control traffic; SABR itself does not switch radios or distribute plans. Updates require consistent reprovisioning, and a missed contact can require rerouting or retention until another opportunity, subject to bundle lifetime and storage limits. This is a supplied-plan architectural capability, not negotiated windows (F27), an executable power-management integration, or measured energy saving." }, { "id": "F24-LT", "feature": "F24", "stack": "LT", "status": "Y", "reason": "The selected LTP/SABR composition includes contact/range plans and clocks. LTP explicitly requires its operating environment to report scheduled starts/stops of peer communication and link availability; queued traffic and recovery timers accommodate interruptions. With the shared final-hop schedule controlling receiver availability, the receiver can listen at planned opportunities instead of continuously.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "SABR contact plans, LTP operating schedules and BP/TCPCL", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html#section-5", "https://www.rfc-editor.org/rfc/rfc5326.html#section-6.5", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round506.html", "round506-sources.json" ], "qualification": "The credited capability relies on the already selected supplied plans, implemented locally as matching transmitter and receiver operating schedules. Account for propagation, clock uncertainty, link startup and reverse report/acknowledgement opportunities; use guard intervals and apply updates consistently. LTP suspends/resumes recovery timers but does not program hardware sleep or negotiate schedules. BP retention remains subject to lifetime/storage and cancellation limits. Complete LTP/AOS binding, wake-controller execution and energy measurements remain unqualified; F27 stays No because externally supplied schedules are not participant negotiation." }, { "id": "F24-LP", "feature": "F24", "stack": "LP", "status": "N", "reason": "QUIC max_idle_timeout bounds idle connection lifetime; PING can keep state alive. Neither defines when a sleeping receiver will listen or requires the sender to deliver in known wake opportunities. The selected libp2p direct QUIC composition adds peer-authenticated streams but no sleep-coordination service.", "method": "Primary documentary reassessment; no runtime or energy test", "source_label": "Selected name-routing and transport/control specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-10.1", "https://github.com/libp2p/specs/blob/master/quic/README.md" ], "editorial_references": [ "round492.html", "round492-sources.json" ], "qualification": "This assessment considers the delivery benefit, not only the absence of a negotiation message. No scheduled access binding, coordinating custodian or application wake scheduler is selected. Flow control, retransmission and retained connection state alone do not meet F24. Such services could be added; their absence here is not a claim that QUIC-capable devices cannot sleep." }, { "id": "F24-TO", "feature": "F24", "stack": "TO", "status": "N", "reason": "Tor package/deliver windows and SENDME regulate cell credit on active circuits. TCP backpressure and link-padding timeout negotiation likewise do not arrange a future receiver wake opportunity. The selected Tor onion-service composition includes no sender or custodian contract to deliver during planned listening windows.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Tor flow control, I2P tunnel operation and GNUnet CADET", "sources": [ "https://spec.torproject.org/tor-spec/flow-control.html" ], "editorial_references": [ "round504.html", "round504-sources.json" ], "qualification": "This is a documentary verdict for the selected composition. Pausing traffic, disabling padding or reconnecting after waking can reduce activity but does not establish scheduled reception. A separate access-layer or application sleep scheduler could add that behavior; none is selected." }, { "id": "F24-I2", "feature": "F24", "stack": "I2", "status": "N", "reason": "I2P tunnel pools replace expiring tunnels and forward messages through available paths. Tunnel lifetime, anticipatory rebuilding and message throttling regulate tunnel availability and load, not a sleeping receiver schedule. The selected NTCP2/IP composition provides no coordinated wake-time delivery service.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Tor flow control, I2P tunnel operation and GNUnet CADET", "sources": [ "https://i2p.net/en/docs/specs/tunnel-implementation/" ], "editorial_references": [ "round504.html", "round504-sources.json" ], "qualification": "Buffering, retransmission and rebuilding after interruption do not by themselves tell a sender when the receiver will listen. The tunnel document identifies its implementation baseline as 0.9.41; the verdict is scoped to the selected composition and documented tunnel contract, not every I2P application or future extension. No additional scheduled access or sleep-aware custodian is selected." }, { "id": "F24-YG", "feature": "F24", "stack": "YG", "status": "N", "reason": "The selected Yggdrasil composition uses ordinary TCP/TLS peerings and pinned Ironwood routing. Ironwood peer monitoring uses keepalive acknowledgements and read deadlines; routing/path timers refresh reachability. Neither service negotiates when a sleeping receiver will be listening or queues delivery against that schedule.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Reticulum Link, Ironwood peers and Linux NET/ROM", "sources": [ "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/peers.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/config.go" ], "editorial_references": [ "round505.html", "round505-sources.json" ], "qualification": "Idle peerings, adjustable timeout values and reconnection after waking are distinct from coordinated reception. The selected composition includes neither a scheduled MAC nor an application delivery scheduler. This does not deny that Yggdrasil could run over a separate sleep-aware link service; that service is absent from this column. Source-qualified architectural verdict, not a runtime test." }, { "id": "F24-CJ", "feature": "F24", "stack": "CJ", "status": "N", "reason": "The selected cjdns forwarding/session composition sends encrypted packets over available paths and maintains or rediscovers reachability. Its session and switch interfaces do not express receiver wake intervals or hold delivery until a shared listening opportunity. No sleep-aware link or application scheduler is selected.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Meshtastic power FSM, cjdns forwarding and batman-adv transmission", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/SwitchCore.c" ], "editorial_references": [ "round507.html", "round507-sources.json" ], "qualification": "Session persistence, temporary buffering and rediscovery after interruption are not coordination of planned reception. A separately provided scheduled underlay could add that capability; it is not part of this column. This is a bounded documentary/source inference for the pinned composition, not a claim that every possible cjdns deployment must keep its hardware continuously powered." }, { "id": "F24-MQ", "feature": "F24", "stack": "MQ", "status": "N", "reason": "QUIC max_idle_timeout bounds idle connection lifetime; PING can keep state alive. Neither defines when a sleeping receiver will listen or requires the sender to deliver in known wake opportunities. The selected multipath-21 path-status preferences do not specify a wake schedule; backup-path use may resume when other paths fail.", "method": "Primary documentary reassessment; no runtime or energy test", "source_label": "Selected name-routing and transport/control specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-10.1", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.txt" ], "editorial_references": [ "round492.html", "round492-sources.json" ], "qualification": "This assessment considers the delivery benefit, not only the absence of a negotiation message. No scheduled access binding, coordinating custodian or application wake scheduler is selected. Flow control, retransmission and retained connection state alone do not meet F24. Such services could be added; their absence here is not a claim that QUIC-capable devices cannot sleep." }, { "id": "F24-SC", "feature": "F24", "stack": "SC", "status": "N", "reason": "SCION path exploration, registration and resolution supply forwarding paths. The selected IP/UDP/SCION/application-UDP composition has no receiver wake schedule or custodian arranging delivery at known listening times. Path availability is not coordination of an endpoint's sleep periods.", "method": "Primary documentary review and bounded selected-composition inference; no execution", "source_label": "HIP, ILNP, Babel and SCION specifications", "sources": [ "https://docs.scion.org/en/latest/overview.html#routing", "https://docs.scion.org/en/latest/overview.html#scope-and-goals" ], "editorial_references": [ "round494.html", "round494-sources.json" ], "qualification": "SCION leaves intra-AS delivery to its deployment. No scheduled access technology or application delivery scheduler is selected, so its possible addition cannot be credited to this composition. The verdict does not imply that SCION endpoints must always remain awake." }, { "id": "F24-RT", "feature": "F24", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link maintains liveness with keepalives, stale detection and timeout teardown. These timers bound how long silence is tolerated; they do not convey receiver listening windows or require the sender to hold traffic for an agreed wake opportunity. The selected serial Link composition supplies no sleep-coordination service.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Reticulum Link, Ironwood peers and Linux NET/ROM", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [ "round505.html", "round505-sources.json" ], "qualification": "A participant can wake, announce or re-establish a Link, and a custom application can add scheduling. Those possibilities do not establish F24 in the selected stack, which excludes LXMF and an application wake contract. Timer tolerance is not a promise that packets arrive when the receiver listens. Documentary source review only; no energy measurement or sleep experiment." }, { "id": "F24-NS", "feature": "F24", "stack": "NS", "status": "N", "reason": "NIP-01 REQ subscribes on a WebSocket connection and requests matching stored events. The since/until filters select event creation timestamps, not future receiver listening windows. Relays send matching updates on the active connection; the selected stack has no contract coordinating delivery with endpoint sleep periods.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "NDN Interest semantics, CCNx and NIP-01", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round503.html", "round503-sources.json" ], "qualification": "A client may reconnect after waking and query retained events. That is receiver-driven retrieval rather than a known wake-time delivery arrangement. TCP buffering and retries do not supply the missing schedule. No push service, scheduled access layer or additional NIP is selected; relay retention is also not a guarantee that all events survive." }, { "id": "F24-MT", "feature": "F24", "stack": "MT", "status": "N", "reason": "Meshtastic power saving includes CPU light sleep with the LoRa receiver remaining on; incoming radio traffic wakes the CPU. Local sleep and minimum-wake timers do not arrange a future listening window with senders. The selected CLIENT composition, with store-and-forward disabled, provides no coordinated radio-off reception schedule.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Meshtastic power FSM, cjdns forwarding and batman-adv transmission", "sources": [ "https://meshtastic.org/docs/configuration/radio/power/", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/PowerFSM.cpp" ], "editorial_references": [ "round507.html", "round507-sources.json" ], "qualification": "CPU sleep is a useful energy-saving mechanism but differs from F24: suspending reception and resuming at known coordinated opportunities. The documented ESP32 behavior is platform-specific; it is not attributed to every board or meshtasticd. Deep sleep or a later reboot also does not supply the missing sender schedule. This source-based verdict does not measure power consumption or deny other power-saving features." }, { "id": "F24-GN", "feature": "F24", "stack": "GN", "status": "N", "reason": "GNUnet CADET supplies flow control, optional reliable channels and connection keepalives. Its transmission-window notifications and receive-completion API regulate readiness and credit; they do not negotiate receiver wake times. The selected GNUnet 0.20.0 CADET/CORE/UDP composition has no scheduled reception contract.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Tor flow control, I2P tunnel operation and GNUnet CADET", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round504.html", "round504-sources.json" ], "qualification": "The pinned CADET configuration refreshes connections to avoid timeout; that periodic maintenance is not coordination with a sleeping endpoint. Retransmission or delayed local readiness also does not establish an agreed listening window. This verdict concerns the selected CADET service, not all applications that could be built over GNUnet, and is based on documentation and source inspection rather than execution." }, { "id": "F24-ND", "feature": "F24", "stack": "ND", "status": "N", "reason": "NDN InterestLifetime specifies the remaining timeout of an Interest. Pending Interests and content stores support retrieval when data is available, but do not require delivery in a previously coordinated receiver wake window. The selected NFD/Ethernet composition supplies no sleep-aware face service or delivery scheduler.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "NDN Interest semantics, CCNx and NIP-01", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html#interestlifetime" ], "editorial_references": [ "round503.html", "round503-sources.json" ], "qualification": "A consumer can wake and issue an Interest, and cached content can reduce dependence on producer availability. That receiver-initiated retrieval is useful but does not establish the coordinated wake-and-delivery behavior required by F24. Custom ApplicationParameters, a DTN extension or a scheduled MAC could add such behavior; none is selected. Existing caching/intermittency verdicts remain unchanged." }, { "id": "F24-AX", "feature": "F24", "stack": "AX", "status": "N", "reason": "Linux 6.12 NET/ROM queues frames subject to window credit and peer-busy state. Its timers cover retransmission, delayed acknowledgements, busy-state expiry and idle disconnection. These are flow-control and recovery mechanisms, not an agreed receiver wake schedule. The selected direct AX.25/NET/ROM composition adds no scheduled radio access service.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Reticulum Link, Ironwood peers and Linux NET/ROM", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_out.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_timer.c" ], "editorial_references": [ "round505.html", "round505-sources.json" ], "qualification": "A CHOKE indication stops sending while the receiver is busy; timer expiry or later acknowledgement is not advance coordination of a future listening opportunity. Packet-radio carrier access and retry timing likewise do not establish that coordination. A BBS mailbox or custom sleep-aware link/application is not selected. The finding is scoped to the selected Linux binding, not every extension or implementation of packet radio." }, { "id": "F24-BA", "feature": "F24", "stack": "BA", "status": "N", "reason": "Linux 6.12 batman-adv forwards frames to a selected next hop through the underlying network device. Transmission queues and delayed work implement forwarding/repetition, without a protocol schedule for an endpoint to stop listening and wake for coordinated delivery. The selected direct Ethernet-style composition adds no sleep-aware MAC service.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Meshtastic power FSM, cjdns forwarding and batman-adv transmission", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h" ], "editorial_references": [ "round507.html", "round507-sources.json" ], "qualification": "A lower-layer Wi-Fi power-save mechanism or externally scheduled link must be evaluated as an additional selected component, not inferred from transparent Ethernet bridging. Local queueing and retransmission do not identify future receiver availability. The verdict does not deny that batman-adv can operate over links offering their own power-saving functions; no such binding or runtime sleep test is credited here." }, { "id": "F24-BL", "feature": "F24", "stack": "BL", "status": "N", "reason": "Babel Hello and Update intervals govern routing messages, neighbor assessment and route expiry. They do not arrange delivery of application datagrams at a sleeping endpoint's listening opportunities. The selected IPv6/ICMPv6 service supplies no coordinating buffer or wake schedule.", "method": "Primary documentary review and bounded selected-composition inference; no execution", "source_label": "HIP, ILNP, Babel and SCION specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.4", "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.7" ], "editorial_references": [ "round494.html", "round494-sources.json" ], "qualification": "This is a result for the declared routed composition, not a denial that a Babel network can use an independently scheduled radio link. Longer control intervals and retained routes alone do not satisfy coordinated reception. No such link service is selected here." }, { "id": "F24-RI", "feature": "F24", "stack": "RI", "status": "N", "reason": "The selected IPv6 IoT/RPL composition uses RFC 6775 address registration. Its section 5.8 permits hosts to sleep between host-initiated exchanges and retain a valid neighbor registration, but explicitly leaves caching traffic for sleeping hosts outside its scope. Registration Lifetime is not a receiver listening schedule. No particular scheduled IEEE 802.15.4 mode is selected.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "RFC 6775 sleeping hosts and RFC 8180 TSCH boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6775.html#section-5.8", "https://www.rfc-editor.org/rfc/rfc8180.html#section-4.1" ], "editorial_references": [ "round508.html", "round508-sources.json" ], "qualification": "This verdict concerns the composition as listed, not all IPv6 IoT deployments. IEEE 802.15.4 is a family of link capabilities; citing it alone does not select TSCH, beacon-enabled scheduled reception or a particular power-save service. RFC 8180 section 4.1 supplies a concrete contrasting TSCH schedule with a shared active cell and inactive slots, announced in enhanced beacons. Selecting that binding would require explicit column qualification and reassessment, rather than silently crediting it to RPL. No runtime or energy measurement was performed." }, { "id": "F24-HP", "feature": "F24", "stack": "HP", "status": "N", "reason": "The selected HIP/ESP mobility mechanisms negotiate associations and update reachable locators. Locator lifetimes and address verification do not coordinate a receiver wake schedule or require transmission during its listening windows. ESP provides protected packet delivery without a scheduled custodian.", "method": "Primary documentary review and bounded selected-composition inference; no execution", "source_label": "HIP, ILNP, Babel and SCION specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-5.1", "https://www.rfc-editor.org/rfc/rfc7402.html#section-3.2" ], "editorial_references": [ "round494.html", "round494-sources.json" ], "qualification": "The selected IP/UDP host-to-host composition includes no timed access service or application wake scheduler. Preserving identity and association state while idle is distinct from arranging reception during sleep cycles. A separately supplied power-saving access mechanism could change the composition." }, { "id": "F24-CX", "feature": "F24", "stack": "CX", "status": "N", "reason": "CCNx InterestLifetime specifies how long a request may remain pending; content expiry and cache-time fields constrain content validity or caching. They do not specify when a sleeping receiver will listen or obligate a forwarder to hold and send the response during agreed wake opportunities.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "NDN Interest semantics, CCNx and NIP-01", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.2", "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.3.1" ], "editorial_references": [ "round503.html", "round503-sources.json" ], "qualification": "The selected CCNx/UDP/IP composition can retrieve cached objects after waking, but includes no coordinated access schedule, sleep-aware custodian or application wake contract. A long-lived Interest is a waiting interval, not a transmission window. This verdict leaves the benefits of caching and asynchronous retrieval intact." }, { "id": "F24-LI", "feature": "F24", "stack": "LI", "status": "N", "reason": "The selected LISP/inner-IP/UDP composition maintains mappings and locator reachability. Mapping lifetimes, registration refresh and RLOC probes do not tell the endpoint when to wake or arrange delivery at known listening opportunities.", "method": "Primary documentary reassessment; no runtime or energy test", "source_label": "Selected name-routing and transport/control specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [ "round492.html", "round492-sources.json" ], "qualification": "A mapping cache or temporary packet buffer is not a sleep-coordinating custodian. No scheduled access network or application delivery scheduler is selected. This does not deny compatibility with a separately supplied power-saving link layer; the verdict concerns the declared full composition." }, { "id": "F24-IL", "feature": "F24", "stack": "IL", "status": "N", "reason": "ILNP Locator Updates advertise Locator validity and preference, enabling mobility and multihoming. These fields do not define listening opportunities for a sleeping receiver. The selected TCP service likewise supplies flow control and retries rather than a coordinated wake/delivery schedule.", "method": "Primary documentary reassessment; no runtime or energy test", "source_label": "Selected name-routing and transport/control specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6743.html#section-2" ], "editorial_references": [ "round492.html", "round492-sources.json" ], "qualification": "Neither DNS rendezvous nor preserving an Identifier schedules packet arrival when the radio is awake. No timed delivery custodian or power-saving access mechanism is selected. This preserves the distinction between retaining communication identity through mobility and coordinated reception during planned sleep." }, { "id": "F24-TS", "feature": "F24", "stack": "TS", "status": "N", "reason": "The selected packet transport retries handshakes and expires queued traffic. Its timer behavior does not coordinate delivery attempts with a receiver sleep schedule.", "method": "Pinned dependency/source inspection and official documentation; no runtime test", "source_label": "Tailscale go.mod and selected wireguard-go dependency", "sources": [ "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/constants.go" ], "editorial_references": [ "round587.html", "round587-sources.json" ], "qualification": "Inference from the selected service and timer state machine. Waking and reconnecting does not provide scheduled reception. No lower-layer cellular sleep service is selected." }, { "id": "F24-RA", "feature": "F24", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Identify how the receiver learns wake/listen opportunities, who coordinates delivery, which traffic follows the schedule, and retention/expiry behavior. Specify clock or relative timing, tolerance and schedule changes. Do not inherit old F24 reenrollment evidence or F25 byte budgets; no measured energy saving is implied. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "F26-PN", "feature": "F26", "stack": "PN", "status": "Y", "reason": "PRP architecture section 7.2 derives forwarding state from control-plane policy and route installation. The packet path validates applicable generation, packet protection and replay/sequence state before next-hop dispatch. Intermediate participants use authenticated local forwarding state rather than re-evaluating endpoint relationships. This supplies an authorization boundary before onward transmission and protects subsequent PRP links against traffic that fails that local boundary. It does not require intermediaries to learn the final identity.", "method": "Primary architectural and forwarding-policy analysis; no bandwidth benchmark required", "source_label": "PRP architecture section 7.2, pinned prp-spec e4f9d396b24ff2069708a39bfaf0a568f486efb2", "sources": [], "editorial_references": [ "round446.html", "round446.html", "round446-sources.json", "round237.html", "round235-sources.json" ], "qualification": "Architectural credit for the native PRP forwarding boundary, not a completed per-carrier implementation test. The ingress link and validation CPU have already been consumed. Local authority does not imply knowledge of endpoint policy; compromised or authorized neighbors, scheduling and quantitative policing remain separate. No universal bandwidth guarantee is claimed." }, { "id": "F26-PI", "feature": "F26", "stack": "PI", "status": "Y", "reason": "PRP architecture section 7.2 derives forwarding state from control-plane policy and route installation. The packet path validates applicable generation, packet protection and replay/sequence state before next-hop dispatch. Intermediate participants use authenticated local forwarding state rather than re-evaluating endpoint relationships. This supplies an authorization boundary before onward transmission and protects subsequent PRP links against traffic that fails that local boundary. It does not require intermediaries to learn the final identity.", "method": "Primary architectural and forwarding-policy analysis; no bandwidth benchmark required", "source_label": "PRP architecture section 7.2, pinned prp-spec e4f9d396b24ff2069708a39bfaf0a568f486efb2", "sources": [], "editorial_references": [ "round446.html", "round446.html", "round446-sources.json", "round237.html", "round235-sources.json" ], "qualification": "Credit only onward PRP forwarding over the selected IP carrier. Underlying IP routers may already have carried the rejected traffic to this participant; their bandwidth is not protected by this PRP check. Preserve the UDP pre-validation endpoint-allocation concern from round237. No full-underlay DDoS protection or measured implementation conformance follows." }, { "id": "F26-IP", "feature": "F26", "stack": "IP", "status": "N", "reason": "The selected bare-IP profile forwards addressed datagrams without a native authenticated transit-admission boundary. Header checks, route lookup and hop limits do not establish permission to consume the onward link.", "method": "Primary architectural and forwarding-policy analysis; no bandwidth benchmark required", "source_label": "Selected composition and retained source assessment; new F26 criterion", "sources": [], "editorial_references": [ "round446.html", "round446.html", "round446-sources.json", "round445.html" ], "qualification": "Added ACLs, provider policing or protected overlays can change deployment behavior but are not silently added to bare IP here. No assertion that every operational IP network lacks defenses." }, { "id": "F26-BP", "feature": "F26", "stack": "BP", "status": "Y", "reason": "The selected TCPCLv4 composition uses TLS 1.3, participant-operated trust and NODE-ID validation. RFC 9174 sections 4.4.3–4.4.5 require certificate exchange, rejection of invalid or locally disallowed credentials, and node authentication before session negotiation. This adjacent-node admission prevents unaccepted peers from supplying bundles for subsequent DTN forwarding.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "RFC 9174 sections 4.4.3, 4.4.4.1, 4.4.4.3 and 4.4.5; existing selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.3", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.5" ], "editorial_references": [ "round449.html", "round449-sources.json" ], "qualification": "Requires the selected mandatory TLS and authenticated-node policy at each receiving transit boundary; opportunistic or unauthenticated TCPCL is not credited. Protection applies to onward bundle transfers, not IP links already traversed, TLS setup costs or flooding by admitted neighbors. Final-origin BPSec authorization is separate. This is documentary architectural plausibility; no full-stack integration or bandwidth test is added." }, { "id": "F26-CG", "feature": "F26", "stack": "CG", "status": "Y", "reason": "The selected TCPCLv4 composition uses TLS 1.3, participant-operated trust and NODE-ID validation. RFC 9174 sections 4.4.3–4.4.5 require certificate exchange, rejection of invalid or locally disallowed credentials, and node authentication before session negotiation. This adjacent-node admission prevents unaccepted peers from supplying bundles for subsequent DTN forwarding.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "RFC 9174 sections 4.4.3, 4.4.4.1, 4.4.4.3 and 4.4.5; existing selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.3", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.5" ], "editorial_references": [ "round449.html", "round449-sources.json" ], "qualification": "Requires the selected mandatory TLS and authenticated-node policy at each receiving transit boundary; opportunistic or unauthenticated TCPCL is not credited. Protection applies to onward bundle transfers, not IP links already traversed, TLS setup costs or flooding by admitted neighbors. Final-origin BPSec authorization is separate. This is documentary architectural plausibility; no full-stack integration or bandwidth test is added." }, { "id": "F26-LT", "feature": "F26", "stack": "LT", "status": "N", "reason": "The selected LTP/AOS composition has no link-security admission layer or selected LTP authentication extension. Engine identifiers, contact plans and segment integrity checks do not establish sender authority. Final-pair BPSec verification occurs at delivery, after transit forwarding.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary specification and pinned receive-path source", "sources": [ "https://www.rfc-editor.org/rfc/rfc5327.html", "https://www.rfc-editor.org/rfc/rfc5327.html" ], "editorial_references": [ "round453.html", "round453-sources.json" ], "qualification": "No is limited to the current composition. RFC 5327 defines optional LTP authentication mechanisms that could support a separately specified admission policy, but no such policy or transit key provisioning is selected here. SDLS and relay-held final BPSec keys are also absent. This is not a claim that LTP cannot support secure adjacency admission." }, { "id": "F26-LP", "feature": "F26", "stack": "LP", "status": "N", "reason": "The selected direct libp2p/QUIC composition gates peer connections at the receiving host. ConnectionGater operates during connection acceptance and security negotiation, not at the intervening IP routers; no admission-controlled transit relay is selected.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Pinned implementation and selected-role analysis", "sources": [ "https://raw.githubusercontent.com/libp2p/go-libp2p/v0.50.0/core/connmgr/gater.go", "https://raw.githubusercontent.com/libp2p/go-libp2p/v0.50.0/core/connmgr/gater.go" ], "editorial_references": [ "round451.html", "round451-sources.json" ], "qualification": "No applies to this direct transport composition. Its endpoint allowlist and resource protections remain credited elsewhere. Circuit Relay or other forwarding compositions would require a separate assessment; rejected incoming bytes have already used upstream IP links." }, { "id": "F26-TO", "feature": "F26", "stack": "TO", "status": "Y", "reason": "Tor requires an existing circuit associated with the receiving connection before forwarding RELAY or RELAY_EARLY cells. A missing circuit causes a drop at the transit relay; circuit creation and extension establish the local forwarding state. This gates onward overlay transmission on connection-scoped circuit admission, rather than only checking the final onion service.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Tor Specifications: circuit-ID checks, circuit creation and forwarded-cell digest scope", "sources": [ "https://spec.torproject.org/tor-spec/routing-relay-cells.html", "https://spec.torproject.org/tor-spec/creating-circuits.html", "https://spec.torproject.org/tor-spec/create-created-cells.html", "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [ "round455.html", "round455-sources.json" ], "qualification": "Credit only the circuit-state boundary on the selected TLS relay connections. Circuit IDs are not secret credentials, and clients may create valid circuits without a final-service allowlist. An admitted peer or circuit owner can still send abusive traffic; creation costs and incoming IP bandwidth are already spent. Forwarded cells are not digest-authenticated at every intermediate hop: unrecognized cells continue along an existing circuit. No full DDoS immunity, bandwidth reservation or runtime test is claimed." }, { "id": "F26-I2", "feature": "F26", "stack": "I2", "status": "Y", "reason": "The selected NTCP2 ingress establishes an authenticated router-to-router session: i2pd checks RouterInfo and the handshake static key before entering the data phase. Each data frame must pass ChaCha20-Poly1305 verification before ProcessNextFrame delivers I2NP messages to the tunnel queue. Failed authentication terminates the session before onward tunnel processing. This provides the adjacency admission boundary allowed by F26.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "i2pd 2.58.0 NTCP2 SessionConfirmed validation, AEAD receive path, I2NP queue and tunnel dispatch", "sources": [ "https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/NTCP2.cpp", "https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/I2NPProtocol.cpp", "https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/Tunnel.cpp", "https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/libi2pd/TransitTunnel.cpp", "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [ "round456.html", "round459.html", "round459-sources.json" ], "qualification": "This resolves the criterion at NTCP2 ingress, not through secrecy or exclusive ownership of the 32-bit tunnel ID. The inspected tunnel lookup still does not establish an incoming-peer-to-tunnel binding; an admitted peer knowing another tunnel ID remains outside this scoped protection. No final-source allowlist, authorized-peer flood containment or upstream IP bandwidth protection is inferred. Session setup and authentication costs remain. Evidence is pinned source ordering, with no runtime exploit, full-stack or throughput test." }, { "id": "F26-YG", "feature": "F26", "stack": "YG", "status": "Y", "reason": "The pinned Yggdrasil link handler decodes peer metadata, checks the configured key pin and nonempty incoming AllowedPublicKeys policy, then calls the routing engine HandleConn. Metadata decoding verifies an Ed25519 signature with the claimed key. Failed peer admission therefore prevents that connection from injecting traffic into onward overlay forwarding.", "method": "Primary source admission ordering and selected-role comparison; no execution", "source_label": "Pinned Yggdrasil link.go/version.go; documented native key-pin and AllowedPublicKeys settings", "sources": [ "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/link.go", "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/version.go", "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [ "round448.html", "round448-sources.json" ], "qualification": "Credit the private pinned-peer configuration, with a nonempty allowlist on incoming listeners and no multicast/local bypass. Empty AllowedPublicKeys permits incoming peers. This is adjacency admission, not a final-source allowlist; an accepted neighbor can route traffic from others. TLS/TCP setup, metadata checking and incoming underlay bytes are already spent. No per-destination bandwidth reservation, full implementation test or F16 change follows." }, { "id": "F26-CJ", "feature": "F26", "stack": "CJ", "status": "Y", "reason": "The selected private cjdns peering uses credential-required session admission. InterfaceController requests authenticated handshake handling; the Rust CryptoAuth/Noise paths enforce the requirement. afterDecrypt rejects authentication errors and prevents non-established sessions from sending transit-directed switch messages. Only accepted plaintext reaches the switch interface, protecting onward overlay links against failed adjacency admission.", "method": "Primary source admission ordering and selected-role comparison; no execution", "source_label": "Pinned InterfaceController afterDecrypt and incoming handshake; Rust crypto_auth and crypto_noise authorization branches", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/InterfaceController.c", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/crypto/crypto_auth.rs", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/crypto/crypto_noise.rs" ], "editorial_references": [ "round448.html", "round448-sources.json" ], "qualification": "Credit the configured private peer credentials, not a public beacon deployment. A peer that passes admission may carry other sources; F16 final-source access remains No. Local handshake/control messages and cryptographic work still occur before full establishment. Existing carrier and route-server costs are not eliminated, and authorized-neighbor flooding remains outside this scoped Yes. No new runtime or bandwidth measurement." }, { "id": "F26-MQ", "feature": "F26", "stack": "MQ", "status": "N", "reason": "QUIC address validation, TLS policy and stream limits act at the transport endpoints in this selected multipath composition. They do not authorize transit forwarding at intervening IP routers. Selecting two validated paths does not install authorization gates along those paths.", "method": "Primary source admission ordering and selected-role comparison; no execution", "source_label": "RFC 9000 endpoint address validation and flow control; selected multipath composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html" ], "editorial_references": [ "round445-sources.json", "round448.html", "round448-sources.json" ], "qualification": "No applies to the selected endpoint transport, without adding an admission-controlled forwarding overlay. F15-MQ remains Yes for its native setup/state protection. Retry anti-amplification limits endpoint responses; it does not prevent unsolicited inbound packets from consuming upstream network capacity." }, { "id": "F26-SC", "feature": "F26", "stack": "SC", "status": "Y", "reason": "SCION hop fields authenticate ingress/egress interface choices and expiry. The v0.12.0 router process path checks expiry, ingress and the current hop MAC before egress dispatch. Invalid authority therefore stops normal forwarding to the selected onward link. This is native base-SCION path authorization, sufficient for the local-transit boundary in F26.", "method": "Pinned source ordering and native admission-boundary analysis; no execution", "source_label": "SCION v0.12.0 router/dataplane.go: process, verifyCurrentMAC, validateHopExpiry and processEgress", "sources": [ "https://raw.githubusercontent.com/scionproto/scion/v0.12.0/router/dataplane.go", "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round447-sources.json", "round447.html" ], "qualification": "Path authority is not individual source or destination-service authorization. Base-SCION hop authenticators are reusable by a party that obtains them; this Yes does not establish protection against a flood using a valid path. Ingress UDP/IP bandwidth and MAC-checking work are already consumed, and an invalid packet can trigger SCMP slow-path processing. No EPIC, COLIBRI, bandwidth reservation or added policing is credited. Source mapping is not an executed deployment or benchmark." }, { "id": "F26-RT", "feature": "F26", "stack": "RT", "status": "Y", "reason": "In Reticulum 1.5.5, preprocess_inbound rejects missing or invalid IFAC before packet unpacking and transport dispatch. The selected serial profile enables secret IFAC. Failed interface authentication therefore prevents subsequent transport forwarding and consumption of onward links.", "method": "Pinned source ordering and native admission-boundary analysis; no execution", "source_label": "Reticulum 1.5.5 Transport.py: handle_ifac and preprocess_inbound", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round447-sources.json", "round447.html" ], "qualification": "Shared-interface credential authority, not individual destination consent. Credential holders can pass this gate. Serial reception and IFAC computation have already occurred; no ingress-medium protection, jamming resistance or measured capacity guarantee follows. Internal ifac_handled shortcuts assume trusted interface code." }, { "id": "F26-NS", "feature": "F26", "stack": "NS", "status": "Y", "reason": "The selected nostr-rs-relay implementation provides a native author whitelist. With pay-to-relay disabled, db.rs rejects events whose verified author is absent from that list before persistence and broadcast. This protects the relay-to-subscriber links from redistribution of those unauthorized events.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Pinned implementation and selected-role analysis", "sources": [ "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/db.rs", "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/db.rs", "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/server.rs", "https://raw.githubusercontent.com/scsibug/nostr-rs-relay/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/config.toml" ], "editorial_references": [ "round451.html", "round451-sources.json" ], "qualification": "Configure a nonempty pubkey_whitelist on both selected relays, disable pay-to-relay and start with a clean event store. This is event-author admission, not authenticated publishing connections, and needs no NIP-42. Incoming WebSocket bytes, signature verification, rejection notices and subscription/read traffic remain exposed; authorized-author floods are not contained by this check. No runtime test or general IP-link protection is claimed." }, { "id": "F26-MT", "feature": "F26", "stack": "MT", "status": "N", "reason": "The pinned Meshtastic receive gate rejects signature-policy failures, but deliberately retains opaque transit. NextHopRouter::relayOpaquePacket allows opaque forwarding in ALL and also in KNOWN_ONLY: the latter checks whether an outer-header party is known for a PKI-shaped unicast, without authenticating that party before retransmission. It then decrements the hop limit and sends the packet. Thus the selected forwarding composition lacks an enforced authorization boundary for all transit paths.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Pinned Router receive/decode gate and NextHopRouter opaque forwarding branch", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.h", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/ReliableRouter.cpp" ], "editorial_references": [ "round457.html", "round457-sources.json" ], "qualification": "No concerns the selected CLIENT relaying composition and its restricted-mode alternative, not final delivery. STRICT signature checking and F16 endpoint admission remain separate benefits. Opaque forwarding excludes module/phone delivery and uses deduplication and hop limits, but those controls do not establish sender or adjacency authority. This is source analysis, not an executed injection or radio-capacity test; no finding is generalized to other firmware revisions." }, { "id": "F26-GN", "feature": "F26", "stack": "GN", "status": "Y", "reason": "GNUnet 0.20.0 CORE accepts encrypted payload only in an established key-exchange state, verifies its HMAC and applies sequence/replay and age checks before delivering messages to clients. CADET registers its transit handlers through GNUNET_CORE_connect. Invalid session traffic is therefore rejected at the adjacent CORE boundary before it can trigger CADET onward forwarding.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "GNUnet 0.20.0 core_kx handle_encrypted/deliver_message and CADET CORE registration", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round458.html", "round458-sources.json" ], "qualification": "Credit hop-by-hop session admission and authenticated message delivery in the selected legacy TRANSPORT/CORE/CADET composition. This is not an administrator allowlist of final sources: a peer that establishes a valid session may still send abusive traffic. UDP ingress bandwidth, key-exchange work and authentication CPU remain exposed. The evidence is source ordering, not a runtime integration, flood or throughput test; final CADET application admission is a separate criterion." }, { "id": "F26-ND", "feature": "F26", "stack": "ND", "status": "N", "reason": "The selected NFD forwarding path accepts ordinary unsigned Interests. It checks scope, hop limit and duplicate nonces, creates PIT state, then invokes the forwarding strategy without requiring sender or adjacency authorization. An unapproved requester can therefore cause onward Interest transmissions.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Pinned forwarding pipeline and selected Interest authentication policy", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/forwarder.cpp", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/forwarder.cpp" ], "editorial_references": [ "round452.html", "round452-sources.json" ], "qualification": "NFD does suppress unsolicited Data and restrict response forwarding to pending downstreams. That request/response-state protection is real, but is not the transit admission required by F26: the selected Interest path itself has no authorization gate. Consumer-side Data signature validation does not supply that gate. No applies to this direct-Ethernet composition, not deployments with added access policies." }, { "id": "F26-AX", "feature": "F26", "stack": "AX", "status": "N", "reason": "The selected classic AX.25/NET/ROM composition uses callsigns, announcements and circuit state without an authenticated forwarding-authority gate. A syntactically valid callsign or circuit is not proof of authorization to consume subsequent links.", "method": "Primary architectural and forwarding-policy analysis; no bandwidth benchmark required", "source_label": "Selected composition and retained source assessment; new F26 criterion", "sources": [], "editorial_references": [ "round446.html", "round446.html", "round446-sources.json", "round445.html" ], "qualification": "Administrative port provisioning, radio licensing and endpoint application login do not provide the missing incoming-frame authority check. No extra link-security mechanism is selected." }, { "id": "F26-BA", "feature": "F26", "stack": "BA", "status": "N", "reason": "The selected BATMAN_IV/native Ethernet composition does not authenticate permission to enter transit forwarding. Mesh control state and duplicate suppression do not supply the required authorization gate on the next link.", "method": "Primary architectural and forwarding-policy analysis; no bandwidth benchmark required", "source_label": "Selected composition and retained source assessment; new F26 criterion", "sources": [], "editorial_references": [ "round446.html", "round446.html", "round446-sources.json", "round445.html" ], "qualification": "WPA, MACsec, VPN and additional firewall policy are absent from this selected composition. No conclusion about deployments that add them." }, { "id": "F26-BL", "feature": "F26", "stack": "BL", "status": "N", "reason": "Babel installs IP routes. The selected IPv6 composition has no data-plane forwarding authorization gate; prefix/interface advertisement filters control routes rather than permission to send data.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary RFC and selected profile; forwarding versus control/endpoint boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-6", "https://www.rfc-editor.org/rfc/rfc8966.html#section-6", "https://www.rfc-editor.org/rfc/rfc6740.html" ], "editorial_references": [ "round450.html", "round450-sources.json" ], "qualification": "No applies to the selected composition without firewall, IPsec or link admission. Authentication of routing messages would not itself authorize user-data forwarding." }, { "id": "F26-RI", "feature": "F26", "stack": "RI", "status": "Y", "reason": "Contiki-NG v4.9 provides a native secured-PAN receive gate: tsch_security_check_level rejects unsecured frames while associated to a secured PAN and enforces the configured security level/key index. tsch_security_parse_frame verifies the MIC; the receive slot marks failures invalid before delivering data upward. This supplies the missing admission ordering for the selected 802.15.4 protection before onward 6LoWPAN forwarding.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Contiki-NG v4.9 security-level gate, MIC verification, slot delivery ordering and secured-only join policy", "sources": [ "https://raw.githubusercontent.com/contiki-ng/contiki-ng/release/v4.9/os/net/mac/tsch/tsch-security.c", "https://raw.githubusercontent.com/contiki-ng/contiki-ng/release/v4.9/os/net/mac/tsch/tsch-slot-operation.c", "https://raw.githubusercontent.com/contiki-ng/contiki-ng/release/v4.9/os/net/mac/tsch/tsch-security.h", "https://raw.githubusercontent.com/contiki-ng/contiki-ng/release/v4.9/os/net/mac/tsch/tsch-conf.h", "https://raw.githubusercontent.com/contiki-ng/contiki-ng/release/v4.9/os/net/mac/tsch/tsch.c" ], "editorial_references": [ "round453.html", "round454.html", "round454-sources.json" ], "qualification": "Bounded mechanism witness: enable LLSEC802154, secured-only joining, secured PAN on all participating routers, and TSCH_SECURITY_CONF_SEC_LEVEL_OTHER=7 (ENC-MIC128). Provision private keys instead of demonstration keys; maintain nonce/ASN uniqueness across restarts. This selects the existing link-security mechanism, not a verified full RPL/DTLS integration. Scanning, radio airtime and authentication CPU are already spent; admitted key holders can still flood, and shared keys do not identify individual senders. The Linux v6.12 unsecured-frame bypass remains a separate unqualified implementation witness, not repaired by this result." }, { "id": "F26-HP", "feature": "F26", "stack": "HP", "status": "N", "reason": "The selected HIP/ESP composition authenticates endpoint associations and protects endpoint packet processing. Its IP transit routers do not evaluate HIP puzzles, host identity policy or ESP admission before using their onward links. Thus its endpoint defenses do not provide the selected-profile transit authorization required by F26.", "method": "Primary source admission ordering and selected-role comparison; no execution", "source_label": "RFC 7401 host-association scope and RFC 7402 ESP composition; selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html" ], "editorial_references": [ "round445-sources.json", "round448.html", "round448-sources.json" ], "qualification": "No concerns the declared host-to-host composition, not HIP deployments with added gateways or filtering infrastructure. F15-HIP remains Yes: setup-work protection is a separate benefit. A packet can be rejected at the HIP endpoint after consuming intervening IP links." }, { "id": "F26-CX", "feature": "F26", "stack": "CX", "status": "N", "reason": "RFC 8569 section 2.4.4 forwards Interests using hop limits, aggregation, cache lookup and FIB matching. The selected Interests use CRC32C, not an authentication credential; valid formatting and a matching route do not establish forwarding authority. Consequently this composition has no authorizing gate on onward Interest traffic.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Pinned forwarding pipeline and selected Interest authentication policy", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.4", "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.4" ], "editorial_references": [ "round452.html", "round452-sources.json" ], "qualification": "Pending-Interest matching constrains returned Content Objects and avoids unsolicited response forwarding. F26 excludes receiver-flow control alone. Optional authenticated Interest validation could support a different selected policy, but it is not present in this CRC32C profile. Producer signatures and final consumer trust remain separate benefits." }, { "id": "F26-LI", "feature": "F26", "stack": "LI", "status": "N", "reason": "The selected LISP data plane forwards through EID-to-RLOC mappings. Registration credentials authorize mapping updates, not individual data forwarding. No sender or adjacency admission credential is required before onward data transmission.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary RFC and selected profile; forwarding versus control/endpoint boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-16", "https://www.rfc-editor.org/rfc/rfc9300.html#section-16", "https://www.rfc-editor.org/rfc/rfc6740.html" ], "editorial_references": [ "round450.html", "round450-sources.json" ], "qualification": "RFC 9300 discusses optional source EID/RLOC consistency checks and anti-spoofing mitigations. Mapping consistency does not establish permission to send traffic. No applies to the selected base composition without added security gateways or filters." }, { "id": "F26-IL", "feature": "F26", "stack": "IL", "status": "N", "reason": "ILNPv6 retains locator-based IPv6 forwarding. The Nonce Destination Option protects endpoint session control against off-path interference; it does not install permission checks at intervening routers before onward transmission.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary RFC and selected profile; forwarding versus control/endpoint boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6744.html", "https://www.rfc-editor.org/rfc/rfc6744.html", "https://www.rfc-editor.org/rfc/rfc6740.html" ], "editorial_references": [ "round450.html", "round450-sources.json" ], "qualification": "No applies to the selected ILNPv6/TCP composition without IPsec or additional admission infrastructure. Endpoint rejection occurs after upstream links have carried the packet; mobility and session protection remain separate benefits." }, { "id": "F26-TS", "feature": "F26", "stack": "TS", "status": "Y", "reason": "The regional DERP mesh provides a bounded transit-authorization boundary. handleFrameForwardPacket rejects callers without canMesh before receiving and forwarding the inner packet. canMesh is derived from isMeshPeer, which requires a supplied nonzero mesh key matching the server key. The DERP architecture documents meshed servers in managed regions. This protects the receiving relay-to-client onward link against unauthorized mesh ForwardPacket injection; local forwarding authority meets F26 without exposing the final application identity.", "method": "Broad primary-source and pinned-code review; no new runtime test", "source_label": "Round 597 primary-source review", "sources": [ "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md" ], "editorial_references": [ "round597.html", "round597-sources.json" ], "qualification": "Source-level inference for the regional mesh role, not a production configuration audit. It does not establish ordinary leaf SendPacket admission, enforcement of tailnet grants by DERP, protection of already traversed ingress links, or containment of admitted malicious clients/mesh peers. No bandwidth benchmark was run." }, { "id": "F26-RA", "feature": "F26", "stack": "RA", "status": "Y", "reason": "At a protected transit adjacency, rmt_receive requires an existing N-1 port and successful SDU unprotection before decapsulation and onward rmt_send. The selected default crypto policy verifies the packet HMAC and returns failure on mismatch; RMT destroys the rejected packet. Traffic without the local adjacency authenticator is therefore stopped before using the next outgoing link.", "method": "Pinned source inspection of selected admission and forwarding policies; no runtime/security test", "source_label": "IRATI peer-key admission and authenticated SDU forwarding", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup-crypto-ps-default.c" ], "editorial_references": [ "round669.html" ], "qualification": "Scope is established protected transit traffic under the selected authenticated-adjacency policy, not every initial handshake. The ingress medium and local decryption, padding and MAC-verification work have already been consumed. Authorized peers can still send abusive traffic. This credits the explicit authenticated forwarding gate, not encryption alone, a CPU/state service floor, RF-jamming resistance or guaranteed bandwidth." }, { "id": "F27-PN", "feature": "F27", "stack": "PN", "status": "Y", "reason": "The owner-identified architecture amendment, section 8.2, requires the PRP DTN realization to negotiate availability windows between participants, including short intervals, for energy-saving transmission and inactivity between communication opportunities. This explicitly supplies the architectural capability that F18 retention and F24 silent resumption do not assess.", "method": "Primary architectural or protocol evidence; distinguish specified capability from executable realization", "source_label": "PRP architecture section 8.2 amended worktree", "sources": [], "editorial_references": [ "round460.html", "round460.html", "round460-sources.json", "communication-windows-proposal.html" ], "qualification": "Architectural Yes based on the exact amended worktree source pinned in round460-sources.json, not the unchanged base commit. The amendment leaves negotiation procedures, timing parameters and wire formats to separate specification and makes realization carrier-dependent. Duration/spacing encodings, update/cancellation, clock tolerance, control/cover exceptions, waiting-data policy and interaction with session/key expiry are not established by this paragraph. No executable integration, preserved traffic keys throughout sleep or energy measurement is claimed." }, { "id": "F27-PI", "feature": "F27", "stack": "PI", "status": "Y", "reason": "The owner-identified architecture amendment, section 8.2, requires the PRP DTN realization to negotiate availability windows between participants, including short intervals, for energy-saving transmission and inactivity between communication opportunities. This explicitly supplies the architectural capability that F18 retention and F24 silent resumption do not assess.", "method": "Primary architectural or protocol evidence; distinguish specified capability from executable realization", "source_label": "PRP architecture section 8.2 amended worktree", "sources": [], "editorial_references": [ "round460.html", "round460.html", "round460-sources.json", "communication-windows-proposal.html" ], "qualification": "Architectural Yes based on the exact amended worktree source pinned in round460-sources.json, not the unchanged base commit. The amendment leaves negotiation procedures, timing parameters and wire formats to separate specification and makes realization carrier-dependent. Duration/spacing encodings, update/cancellation, clock tolerance, control/cover exceptions, waiting-data policy and interaction with session/key expiry are not established by this paragraph. No executable integration, preserved traffic keys throughout sleep or energy measurement is claimed. Over IP, a PRP-level window does not by itself coordinate the underlying radio or suppress unrelated IP traffic." }, { "id": "F27-IP", "feature": "F27", "stack": "IP", "status": "N", "reason": "The selected IPv4/IPv6 datagram composition provides addressing and packet forwarding, with no participant exchange agreeing temporal reception windows and transmitter silence. Packet lifetime and hop limits do not define receiver availability.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary selected protocol specifications; temporal agreement versus timer/path preference", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html", "https://www.rfc-editor.org/rfc/rfc791.html" ], "editorial_references": [ "round461.html", "round461-sources.json" ], "qualification": "No applies to the selected IP layers. A radio access protocol or application may add scheduling, but no such timing-negotiation layer is selected here. This does not negate F24 resumption after local sleep." }, { "id": "F27-BP", "feature": "F27", "stack": "BP", "status": "N", "reason": "BPv7 retains bundles across disrupted connectivity. TCPCLv4 describes persistent, ephemeral and periodic polling policies, negotiates connection parameters and permits session termination. These mechanisms do not specify an agreement on temporal receiver availability windows. Idle termination ends a session rather than agreeing its next communication window.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html", "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "RFC 9174 sections 3.5, 4.3 and 6, with RFC 9171. Periodic polling and externally arranged policies remain possible; the selected profile has no temporal-agreement extension. This No does not negate DTN retention or planned contacts." }, { "id": "F27-CG", "feature": "F27", "stack": "CG", "status": "N", "reason": "The selected SABR contact plan supplies future link opportunities to routing; its distribution is external to the routing standard. BP/TCPCL session policies and those supplied schedules do not define participant negotiation of receiver availability windows.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "SABR sections 2.3.1 and 3.2 plus TCPCLv4 sections 3.5 and 6. F32 remains Yes for using future plans. A separately selected contact-negotiation mechanism could qualify, but supplied plans alone do not." }, { "id": "F27-LT", "feature": "F27", "stack": "LT", "status": "N", "reason": "LTP uses link-state cues and planned transmission schedules to suspend or resume recovery timers; SABR uses supplied contact plans. Neither selected mechanism specifies an agreement between participants negotiating receive windows and intervening inactivity.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "RFC 5326 sections 6.5–6.6 and SABR section 2.3.1. F32 planned routing and F33 interruption-aware recovery remain Yes. This No does not deny scheduled operation; no additional MAC/contact-negotiation protocol is selected." }, { "id": "F27-LP", "feature": "F27", "stack": "LP", "status": "N", "reason": "The selected direct-peer libp2p QUIC transport adds peer authentication and streams over QUIC. QUIC idle-timeout negotiation and flow-control credits do not agree temporal reception windows. The selected composition includes no application protocol providing that agreement.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html#section-10.1" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "libp2p QUIC transport specification and RFC 9000 section 10.1. This does not judge optional libp2p applications or future transport extensions." }, { "id": "F27-TO", "feature": "F27", "stack": "TO", "status": "N", "reason": "The selected Tor onion-service composition does not define an agreement on temporal receive windows and intervening inactivity. SENDME and XON/XOFF control traffic according to acknowledgments and buffer pressure; circuit-padding negotiation starts or stops a padding machine.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation; selected-composition assessment", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html", "https://spec.torproject.org/proposals/324-rtt-congestion-control.txt", "https://spec.torproject.org/padding-spec/circuit-level-padding.html" ], "editorial_references": [ "round473.html", "round473-sources.json" ], "qualification": "These are real peer-control mechanisms, but neither buffer-driven stream suspension nor padding-machine acceptance schedules receiver availability. Conflux circuit switching/resumption is separately credited and does not add a receive-window contract. No new runtime test; additional application scheduling is outside the selected profile." }, { "id": "F27-I2", "feature": "F27", "stack": "I2", "status": "N", "reason": "The selected NTCP2/tunnel composition does not specify an agreement on receiver availability windows. NTCP2 Options describe padding ratios, dummy-traffic rates and requested or maximum inserted message delay; these shape traffic rather than announce periods when a receiver is available.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation; selected-composition assessment", "sources": [ "https://i2p.net/en/docs/specs/ntcp2/", "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round473.html", "round473-sources.json" ], "qualification": "The Options text also retains format/negotiation TBD notes; the No does not depend solely on that maturity issue. Even the described parameters do not establish receive intervals and agreed inactivity. Tunnel expiry, replacement and transport reconnection remain distinct. No additional application scheduling protocol is selected." }, { "id": "F27-YG", "feature": "F27", "stack": "YG", "status": "N", "reason": "The selected Ironwood peer monitor schedules a keepalive response after traffic and applies a read deadline while awaiting a response. Its configurable timing values are local options. The wire dispatch and PacketConn interface define no agreement on temporal receive windows.", "method": "Primary RFC and pinned implementation assessment; no runtime experiment", "source_label": "Selected-composition mechanisms and interface evidence", "sources": [ "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/peers.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/config.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/types/packetconn.go" ], "editorial_references": [ "round485.html", "round485-sources.json", "round485-plan.json" ], "qualification": "No for the selected Yggdrasil/TCP/TLS profile and pinned Ironwood revision. Read deadlines, idle connection behavior, peer reconnects and local keepalive configuration are not an availability-window negotiation. No additional scheduler or application control exchange is selected; energy consumption is not measured." }, { "id": "F27-CJ", "feature": "F27", "stack": "CJ", "status": "N", "reason": "The pinned cjdns session and forwarding interfaces provide encrypted communication and path discovery, but no availability-window proposal/acceptance or delivery rule tied to a negotiated receiver inactivity interval. The selected composition adds neither an application timing agreement nor a scheduled-link negotiation service.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Pinned cjdns source, BP forwarding and Meshtastic store-forward", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/SwitchCore.c" ], "editorial_references": [ "round509.html", "round509-sources.json" ], "qualification": "Timeouts, buffering, path rediscovery and retention of session state do not specify the temporal agreement required by F27. This is a source-based finding for the selected composition, not a prohibition on adding such a service or a runtime sleep test. The same scoped distinction applies to its separately assessed F24 result." }, { "id": "F27-MQ", "feature": "F27", "stack": "MQ", "status": "N", "reason": "QUIC negotiates an idle timeout, not recurring availability windows. In the selected multipath-21 draft, PATH_STATUS_AVAILABLE and PATH_STATUS_BACKUP express path-use preferences that the sender need not follow; backup paths may carry traffic when alternatives fail. These mechanisms do not establish agreed receive windows or mandatory silence between them.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary selected protocol specifications; temporal agreement versus timer/path preference", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-10.1", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.txt" ], "editorial_references": [ "round461.html", "round461-sources.json" ], "qualification": "No is limited to RFC 9000 plus the selected multipath-21 composition. It does not cover added energy-aware extensions or application scheduling. Idle-timeout deferral, PING, local packet scheduling and path migration retain their distinct benefits." }, { "id": "F27-SC", "feature": "F27", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP composition provides path discovery, selection and datagram forwarding, without a receiver-window negotiation protocol. Path-segment validity and expiration govern usable routing state, not an agreement about endpoint wake or receive times.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation; selected-composition assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [ "round473.html", "round473-sources.json" ], "qualification": "This is scoped to the declared UDP stack, with no scheduling application or negotiated link-power profile added. Path control and failure recovery remain available but do not alone satisfy F27. No claim is made about every possible transport or carrier used with SCION." }, { "id": "F27-RT", "feature": "F27", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link uses RTT-derived keepalive and stale timers. Its watchdog sends liveness traffic and closes a stale link. Resource flow windows control outstanding parts, not negotiated periods when a receiver is available.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Resource.py" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "No temporal receive-window offer/acceptance is defined by the selected Link/serial composition. Local watchdog sleep, rate adaptation and buffering do not qualify. No LXMF or custom application scheduling is selected; this does not deny operation on slow links or ordinary temporary inactivity." }, { "id": "F27-NS", "feature": "F27", "stack": "NS", "status": "N", "reason": "NIP-01 subscriptions select events and deliver subsequent matches until closure or replacement. The since/until filters select event creation timestamps, not transmission times. REQ/CLOSE and relay storage permit later retrieval without negotiating receiver availability windows.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "Selected NIP-01 over WebSocket/TLS. No additional NIP or application scheduling agreement is assumed." }, { "id": "F27-MT", "feature": "F27", "stack": "MT", "status": "N", "reason": "The selected firmware implements local power-state transitions driven by configured sleep durations, wake timers, received packets, power and user input. PowerFSM_setup and the Config.Power fields do not establish a peer offer/acceptance contract specifying when a transmitter must deliver to an available receiver. Local sleep and wake intervals therefore do not satisfy F27.", "method": "Pinned firmware source and primary documentation; no runtime test", "source_label": "Meshtastic selected firmware 8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/PowerFSM.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/config.pb.h", "https://meshtastic.org/docs/configuration/radio/power/" ], "editorial_references": [ "round480.html", "round480-sources.json" ], "qualification": "This credits neither an absence of power-saving features nor measured energy use. Behavior depends on board and role; the selected ordinary CLIENT composition does not add a negotiated scheduling protocol. Administrative configuration of one device and wake on received activity are distinct from a bilateral availability agreement. Store-and-forward is disabled and is not a substitute for that agreement." }, { "id": "F27-GN", "feature": "F27", "stack": "GN", "status": "N", "reason": "GNUnet 0.20.0 CADET uses message-window backpressure and receive_done readiness. The selected legacy UDP transport also communicates a desired inter-message flow-control delay in its ACK. Neither specifies an agreed interval of receiver availability with inactive periods between windows.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "GNUnet 0.20.0 service/transport code and Tor circuit specification", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round486.html", "round486-sources.json", "round486-plan.json" ], "qualification": "The UDP delay field is explicitly credited as peer feedback, not dismissed as a purely local timer. It paces messages; it does not negotiate opening/closing times or an availability schedule. CADET channel setup and the selected transport do not add such an agreement. This is a judgment about the selected 0.20.0 composition, not all GNUnet releases or custom applications." }, { "id": "F27-ND", "feature": "F27", "stack": "ND", "status": "N", "reason": "In the selected NDN v0.3 composition, InterestLifetime limits the time an Interest remains pending. Consumer-driven retrieval can avoid unsolicited Data, but the packet exchange does not agree future availability windows or a transmitter schedule for intervening inactivity.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "NDN v0.3 Interest packet fields and InterestLifetime semantics. Arbitrary ApplicationParameters can support an additional application protocol; none is selected here." }, { "id": "F27-AX", "feature": "F27", "stack": "AX", "status": "N", "reason": "NET/ROM negotiates a receive window measured in frames. Its CHOKE flag signals receiver congestion; Linux 6.12 starts T4 on CHOKE and clears the busy condition when that timer expires. These messages do not agree on future receiver availability periods.", "method": "Primary RFC and pinned implementation assessment; no runtime experiment", "source_label": "Selected-composition mechanisms and interface evidence", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_in.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_timer.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_out.c", "https://hamgate.ampr.org/docs/1987_netrom_version_1_3.pdf" ], "editorial_references": [ "round485.html", "round485-sources.json", "round485-plan.json" ], "qualification": "The selected direct KISS/AX.25/NET/ROM composition provides flow control and local timers, but no temporal-window offer and acceptance. Frame windows and busy/unbusy signaling are explicitly considered. Neither a locally delayed transmission nor a separate application schedule is treated as a selected negotiated sleep service." }, { "id": "F27-BA", "feature": "F27", "stack": "BA", "status": "N", "reason": "The selected BATMAN_IV/native Ethernet composition does not negotiate receiver availability windows. Its ORIG_INTERVAL configures local routing-announcement cadence; the public v6.12 control attributes and packet types provide no receiver-window offer/acceptance contract. Local transmission intervals do not tell a sender when its peer has agreed to be available.", "method": "Pinned Linux v6.12 source and primary documentation; no runtime test", "source_label": "Selected BATMAN_IV/native Ethernet composition", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batman_adv.h", "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h", "https://docs.kernel.org/networking/batman-adv.html" ], "editorial_references": [ "round478.html", "round478-sources.json" ], "qualification": "This assessment covers the declared direct Ethernet-style carrier. No Wi-Fi power-save or application scheduling protocol is selected. A sleeping kernel worker, duplicate-protection window or routing metric window is not a negotiated communication window." }, { "id": "F27-BL", "feature": "F27", "stack": "BL", "status": "N", "reason": "Babel exchanges routing information for the selected IPv6 data plane. Hello/update intervals and neighbor-expiry timers govern routing maintenance; they do not negotiate receiver availability windows that constrain user-data transmission.", "method": "Primary normative source and selected adjacency-policy analysis; no execution", "source_label": "Primary selected protocol specifications; temporal agreement versus timer/path preference", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round461.html", "round461-sources.json" ], "qualification": "No applies to IPv6/Babel without an added MAC scheduling or application agreement. Locally configured timers and planned device shutdown do not supply the missing bilateral temporal agreement." }, { "id": "F27-RI", "feature": "F27", "stack": "RI", "status": "N", "reason": "The selected RFC 6775 registration exchange negotiates neither transmission windows nor the intervening receiver inactivity schedule. A host chooses its sleep interval locally and registers an address lifetime long enough to cover it; the router confirmation maintains address reachability state, not a timed communication agreement. The selected RPL/6LoWPAN/DTLS composition adds no window-negotiation protocol.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "RFC 6775 sleeping hosts and RFC 8180 TSCH boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6775.html#section-5.8.1", "https://www.rfc-editor.org/rfc/rfc8180.html#section-1" ], "editorial_references": [ "round508.html", "round508-sources.json" ], "qualification": "F27 is distinct from F24. Even the contrasting minimal RFC 8180 TSCH schedule is learned on joining and shared by all nodes; that document leaves dynamic schedule management outside scope. It is not selected here and is not evidence of bilateral window negotiation. A separately specified scheduling function or link mechanism could change this assessment. This does not deny sleeping-host support or imply that ordinary registration must run continuously." }, { "id": "F27-HP", "feature": "F27", "stack": "HP", "status": "N", "reason": "HIPv2 establishes associations and the selected mobility extension updates locator sets. Locator Lifetime expresses address validity; UPDATE acknowledgments and reachability checks do not agree reception windows or intervening inactivity.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "RFC 7401 association state and RFC 8046 sections 4–5. No added sleep-scheduling extension is selected." }, { "id": "F27-CX", "feature": "F27", "stack": "CX", "status": "N", "reason": "CCNx Interest Lifetime expresses how long a requester will wait for content. Interest/Content Object matching and pending-interest expiry do not negotiate receiver availability windows. Requesting content only when awake is useful, but remains distinct from agreeing a future transmission schedule.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "RFC 8569 sections 2.2 and 2.4.2. No application scheduling protocol is selected over CCNx." }, { "id": "F27-LI", "feature": "F27", "stack": "LI", "status": "N", "reason": "The selected LISP data and control planes encapsulate traffic and maintain EID-to-RLOC mappings. Mapping TTL, registration refresh and RLOC probes describe mapping validity and reachability, not a participant agreement to defer transmission until receiver availability windows.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "RFC 9300 and RFC 9301 mapping messages and RLOC probing. No application or access-network scheduler is added." }, { "id": "F27-IL", "feature": "F27", "stack": "IL", "status": "N", "reason": "ILNP Locator Update advertisements and acknowledgments synchronize locator bindings. Their Lifetime bounds locator validity and Preference ranks locators; neither establishes an agreed temporal receive schedule with inactivity between opportunities.", "method": "Primary specification analysis; no runtime experiment", "source_label": "Primary protocol definitions; bounded selected-composition inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6743.html" ], "editorial_references": [ "round462.html", "round462-sources.json" ], "qualification": "RFC 6740 and RFC 6743 section 2. TCP flow control and local sleep policies do not supply temporal-window negotiation." }, { "id": "F27-TS", "feature": "F27", "stack": "TS", "status": "N", "reason": "WireGuard uses local keepalive, rekey and retry timers, without an exchange agreeing on receiver availability windows. DERP forwarding does not add such negotiation.", "method": "Pinned dependency/source inspection and official documentation; no runtime test", "source_label": "Tailscale go.mod and selected wireguard-go dependency", "sources": [ "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/constants.go" ], "editorial_references": [ "round587.html", "round587-sources.json" ], "qualification": "No additional temporal-availability or application scheduling protocol is selected. Local inactivity settings are not negotiated communication windows." }, { "id": "F27-RA", "feature": "F27", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Identify the availability-window agreement, acceptance and direction; document duration/spacing, clock basis, changes, expiry, pending-data handling and which data/control/cover traffic obeys it. Distinguish retained relationships, logical connections and cryptographic sessions. No result is inherited from F18, F24 or F25. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "F28-PN", "feature": "F28", "stack": "PN", "status": "Y", "reason": "The participant requests a route decision toward an exact authenticated member identity through an intermediary; accepted scoped authority carries a recursive HS2 attempt whose target identity the requester must verify. This permits participant-selected PRP-level legs beyond merely choosing a local access interface. Member Route Intent sections 2, 4, 6 and 8 supply the architectural mechanism.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [], "editorial_references": [ "round464.html#prp-sources", "round464.html", "round464-sources.json" ], "qualification": "Architectural capability, not generally interoperable activation: ROUTE-001 still gates reciprocal generation coordination, deferred-result convergence and alias lifetime. Each leg requires reciprocal intent and local admission. No claim of controlling hidden IP-underlay hops, arbitrary noncooperating nodes or operational TPA wire admission. The older TPA text candidate is not used as an admitted wire source." }, { "id": "F28-PI", "feature": "F28", "stack": "PI", "status": "Y", "reason": "The participant requests a route decision toward an exact authenticated member identity through an intermediary; accepted scoped authority carries a recursive HS2 attempt whose target identity the requester must verify. This permits participant-selected PRP-level legs beyond merely choosing a local access interface. Member Route Intent sections 2, 4, 6 and 8 supply the architectural mechanism.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [], "editorial_references": [ "round464.html#prp-sources", "round464.html", "round464-sources.json" ], "qualification": "Architectural capability, not generally interoperable activation: ROUTE-001 still gates reciprocal generation coordination, deferred-result convergence and alias lifetime. Each leg requires reciprocal intent and local admission. No claim of controlling hidden IP-underlay hops, arbitrary noncooperating nodes or operational TPA wire admission. The older TPA text candidate is not used as an admitted wire source." }, { "id": "F28-IP", "feature": "F28", "stack": "IP", "status": "Y", "reason": "IPv4 Loose and Strict Source and Record Route options let the source specify intermediate IP addresses. Loose routing permits other hops between listed addresses; strict routing requires the listed sequence. This is native endpoint path selection in the IPv4 branch of the declared IPv4/IPv6 column.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc1812.html", "https://www.rfc-editor.org/rfc/rfc5095.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "RFC 791 section 3.1 and RFC 1812 sections 5.2.4.1 and 5.3.13.4. The witness requires a path whose routers permit source-routed packets; filtering or local policy may prevent use. No authenticated router-identity proof or general public-Internet availability is claimed. IPv6 RH0 is deprecated by RFC 5095 and is not a witness; no Segment Routing extension is silently added." }, { "id": "F28-BP", "feature": "F28", "stack": "BP", "status": "N", "reason": "The selected BPv7 endpoint service sends a bundle to an identified destination. Forwarding-node and convergence-layer selection are performed by the BPA using routing information and policy. The selected static/aggregate forwarding composition supplies no endpoint interface or bundle path constraint selecting downstream intermediaries.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP endpoint service, SABR route computation and LTP engine service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.3", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round516.html", "round516-sources.json" ], "qualification": "An operator can configure routes, and an application could add an overlay of explicit intermediate destinations. Neither is the selected endpoint service. BPSec origin authentication, status reports and the Previous Node block do not impose a sender-chosen path. This verdict does not deny administrative route control or the possibility of a BP extension implementing endpoint path selection." }, { "id": "F28-CG", "feature": "F28", "stack": "CG", "status": "N", "reason": "SABR computes candidate routes from contact plans and selects neighboring nodes for forwarding. This gives the routing agent trajectory knowledge and schedule-aware choices, but the selected BP application interface does not expose those routes for sender selection or encode an enforced endpoint-selected intermediary constraint.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP endpoint service, SABR route computation and LTP engine service", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.3" ], "editorial_references": [ "round516.html", "round516-sources.json" ], "qualification": "F32 remains Yes for route planning. Supplying a contact plan administratively is distinct from an endpoint selecting a path for its communication. The selected composition adds no route-choice API or source-route extension binding later forwarders to that choice. Local routing policy and rerouting after contact failure remain possible; no general claim that CGR cannot support an additional endpoint-control interface is made." }, { "id": "F28-LT", "feature": "F28", "stack": "LT", "status": "N", "reason": "The selected LTP stack uses BP/SABR for routing and LTP for transfer to a neighboring engine. Choosing the destination engine of one LTP transfer does not select downstream intermediaries of the BP communication. The composition supplies no endpoint path-selection API or enforced multi-hop path constraint.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP endpoint service, SABR route computation and LTP engine service", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html#section-4", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round516.html", "round516-sources.json" ], "qualification": "LTP is a reliable transfer mechanism, not an end-to-end route-selection service. Its client can identify a remote engine, while the BP/SABR forwarding role chooses the next transfer and future routes. F33 reliable interruption recovery and F32 contact-based planning remain credited independently. A custom chain of application transfers or additional source-route mechanism would require separate selection and qualification." }, { "id": "F28-LP", "feature": "F28", "stack": "LP", "status": "N", "reason": "The selected libp2p composition uses direct IPv4/UDP/QUIC connections to known peers. QUIC path migration changes endpoint network attachment and validates reachability; it does not select intermediate routers. No relay circuit or other endpoint-selected intermediary service is included in the composition.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "QUIC migration, libp2p Circuit Relay and cjdns route labels", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9", "https://github.com/libp2p/specs/blob/master/relay/circuit-v2.md" ], "editorial_references": [ "round515.html", "round515-sources.json" ], "qualification": "This is not a project-wide absence claim. Circuit Relay v2 lets an initiator connect through a named relay using a circuit multiaddress, with reservation and relay policy dependencies. That is a concrete candidate for a separately selected path-control witness, but it changes the direct transport composition and requires its security/multiplexing binding to be documented. Merely supporting multiaddresses or migration does not import that relay service into the current verdict." }, { "id": "F28-TO", "feature": "F28", "stack": "TO", "status": "Y", "reason": "The originating Tor process selects circuit relays and builds the circuit through them. Native path constraints and the control protocol permit explicit relay-path choices rather than only selecting a destination or access interface.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://spec.torproject.org/path-spec/path-selection-constraints.html", "https://spec.torproject.org/control-spec/commands.html#extendcircuit" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "The witness concerns the locally constructed circuit portion. Onion-service communication combines circuits through a rendezvous point; the sender does not choose the remote service half or hidden IP-underlay hops. Guard, family, purpose and relay-availability constraints remain. Control-port access is local privileged authority; arbitrary custom paths are not recommended anonymity defaults." }, { "id": "F28-I2", "feature": "F28", "stack": "I2", "status": "Y", "reason": "The local tunnel creator chooses participating routers and constructs the tunnel through that ordered sequence. The selected i2pd 2.58.0 source exposes SetExplicitPeers/SelectExplicitPeers and a custom peer selector as concrete local path-control mechanisms.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://github.com/PurpleI2P/i2pd/blob/2.58.0/libi2pd/TunnelPool.cpp", "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Bounded to locally created tunnels, including the sender outbound leg. The destination creates its own inbound tunnel; the sender does not control that full remote leg or IP-underlay hops. Availability and peer admission still apply. This is source-backed capability, not a new executed tunnel test or a claim that every client API exposes arbitrary peer lists." }, { "id": "F28-YG", "feature": "F28", "stack": "YG", "status": "N", "reason": "Ironwood WriteTo accepts a destination public key and passes the packet to its router. The pathfinder installs the internally learned path for that destination or starts a lookup. The selected interface exposes neither a requested intermediate-node sequence nor an exclusion constraint for a transmitted packet.", "method": "Primary RFC and pinned implementation assessment; no runtime experiment", "source_label": "Selected-composition mechanisms and interface evidence", "sources": [ "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/packetconn.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/types/packetconn.go" ], "editorial_references": [ "round485.html", "round485-sources.json", "round485-plan.json" ], "qualification": "Internal source paths exist and are explicitly acknowledged; their existence is not an endpoint path-selection API. Configuring or prioritizing adjacent peers selects local access, which F28 excludes. The verdict is limited to the declared Yggdrasil composition and pinned implementation, not a claim that its path machinery could never expose such a facility. No custom router modification is selected." }, { "id": "F28-CJ", "feature": "F28", "stack": "CJ", "status": "N", "reason": "The cjdns column explicitly selects the ordinary IPv6 application path without custom route-label overrides. In the pinned SessionManager, a missing label is filled from the selected session path. The ordinary endpoint service therefore relies on internal path selection rather than an application-supplied intermediary constraint.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "QUIC migration, libp2p Circuit Relay and cjdns route labels", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/SwitchCore.c" ], "editorial_references": [ "round515.html", "round515-sources.json" ], "qualification": "cjdns has real source-route labels: SessionManager can preserve a supplied label and SwitchCore processes it. The No is limited to the explicitly selected application interface, not the absence of source routing in cjdns. A qualified route-label injection interface could be assessed separately, including how the endpoint obtains valid labels and how failures are handled. No underlay-hop visibility or runtime path-enforcement result is inferred." }, { "id": "F28-MQ", "feature": "F28", "stack": "MQ", "status": "N", "reason": "The selected multipath-21 extension establishes and validates transport paths using endpoint addresses and path IDs, then schedules packets over them. Its sections 3.1 and 5.2 also allow multiple path IDs on the same address/port tuple. It supplies no mechanism selecting or enforcing an intermediate node, domain or segment beyond the endpoint/access choices excluded by F28.", "method": "Primary documentary assessment; no runtime test", "source_label": "Pinned primary specifications; selected-composition inference", "sources": [ "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-3.1", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-5.2" ], "editorial_references": [ "round479.html", "round479-sources.json" ], "qualification": "This preserves explicit transport-path scheduling and simultaneous transmission capabilities. A path ID is not an intermediate-router itinerary. Differentiated-service markings in section 5.2 do not specify an intermediary constraint. No source-routing, SCION or relay overlay is added to this selected composition; later extensions are not assessed." }, { "id": "F28-SC", "feature": "F28", "stack": "SC", "status": "Y", "reason": "SCION endpoints obtain path segments and combine them into packet-carried forwarding paths. This provides explicit selection of AS-level intermediaries rather than only a destination or local interface.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Selection is among paths exposed by the control infrastructure and authorized segment information. It does not control hidden intra-AS or IP-underlay hops, or remove trust-root dependencies." }, { "id": "F28-RT", "feature": "F28", "stack": "RT", "status": "N", "reason": "The selected Reticulum 1.5.5 Link composition addresses a destination and relies on Transport path state populated by announces and path requests. Requesting discovery on an interface, inspecting hop information or choosing local access does not specify or exclude downstream transport nodes. No endpoint-controlled source-route or intermediary-selection mechanism is selected.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Reticulum Transport path selection and CCNx forwarding semantics", "sources": [ "https://reticulum.network/manual/reference.html", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round514.html", "round514-sources.json" ], "qualification": "The request_path interface parameter restricts where a discovery request is sent; it is not an enforced path description. Forwarders continue to use their own next-hop state. This does not deny route discovery, route replacement or the ability to inspect some path information. A separately implemented overlay or administrative topology constraint would be additional functionality, not the selected native endpoint service." }, { "id": "F28-NS", "feature": "F28", "stack": "NS", "status": "Y", "reason": "At the event-delivery layer, a Nostr publisher chooses the relay WebSocket endpoints to which it sends EVENT messages. Those relays receive and serve the event to subscribing readers. The selected two-relay publication therefore gives the sender explicit choice of application intermediaries between the author and readers; this meets the intermediary-selection branch of F28.", "method": "Primary documentary assessment; no runtime test", "source_label": "Pinned primary specifications; selected-composition inference", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round479.html", "round479-sources.json" ], "qualification": "Granularity is the relay service, not its IP routers or a complete enforced reader path. A selected relay can reject publication, readers must reach a relay holding the event, and recipients can redistribute it elsewhere. Choice controls the publisher-initiated delivery, not all later copies. No NIP-65 discovery, hidden-hop visibility or sovereign control of the underlay is inferred." }, { "id": "F28-MT", "feature": "F28", "stack": "MT", "status": "N", "reason": "The selected firmware learns next hops from observed forwarding and responses. NextHopRouter::send sets next_hop from getNextHop for the destination; route checks can clear that preference, and the final retry falls back to managed flooding. This is automatic hop selection, not an endpoint-selected and enforced intermediary constraint.", "method": "Pinned firmware source and primary documentation; no runtime test", "source_label": "Selected Meshtastic ordinary CLIENT composition", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp", "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [ "round482.html", "round482-sources.json" ], "qualification": "The next_hop header is explicitly considered: having that field does not itself expose sender control, and fallback does not preserve an exclusive relay choice. Destination selection, hop limits, role configuration and diagnostic traceroute remain available. No modified firmware or additional source-routing protocol is selected; this finding does not deny native multi-hop delivery." }, { "id": "F28-GN", "feature": "F28", "stack": "GN", "status": "N", "reason": "The selected CADET API opens a channel by destination peer identity and port. Its get_path API reports known paths. Internally, the tunnel service evaluates available paths and creates connections; the channel API does not bind outgoing traffic to a caller-selected path or intermediate-peer constraint.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "GNUnet 0.20.0 service/transport code and Tor circuit specification", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round486.html", "round486-sources.json", "round486-plan.json" ], "qualification": "CADET carries explicit peer paths and exposes path inspection; both are acknowledged. Inspection and automatic path selection do not establish the requested endpoint control through the selected service interface. This No is bounded to the declared 0.20.0 API composition; modifying the tunnel service or introducing another routing API would require reassessment." }, { "id": "F28-ND", "feature": "F28", "stack": "ND", "status": "Y", "reason": "NDN Interests expose ForwardingHint to the consumer. In the selected NFD 24.07 implementation, Strategy::lookupFib uses the delegation names in that hint instead of the content name while outside the producer region. With provisioned routes for distinct delegation regions, the endpoint can select which region the forwarded Interest is directed toward, without changing the requested content name.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "NDN v0.3 and pinned NFD 24.07 forwarding-hint implementation", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html#forwardinghint", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/strategy.cpp", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/forwarder.cpp", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/multicast-strategy.cpp" ], "editorial_references": [ "round518.html", "round518-sources.json" ], "qualification": "Bounded native-feature witness: one known delegation name per Interest, usable local FIB routes toward that region and consistent producer-region configuration. The selected multicast strategy also calls lookupFib, so the hint selects its forwarding entry but may still fan out across multiple next hops. The hint is removed on entering the producer region. Cache hits can satisfy the Interest earlier, and default routes can reduce path discrimination; the positive applies to forwarding of an unsatisfied Interest where delegation-specific routes exist. It does not enforce an exact hop list, cryptographic path compliance or universal cache bypass. This F28 configuration is separate from the G01 flooding witness, which deliberately uses no hints; its qualifications remain unchanged. No new protocol layer or runtime validation is claimed." }, { "id": "F28-AX", "feature": "F28", "stack": "AX", "status": "N", "reason": "The selected application uses Linux 6.12 NET/ROM circuits. Its connect operation selects the destination callsign; NET/ROM forwarding chooses a neighbor from routing state. AX.25 digipeater sequences can be attached to configured neighbor routes, but this does not give the NET/ROM endpoint an interface to select downstream intermediaries for its communication.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Linux v6.12 NET/ROM connection and route configuration", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/af_netrom.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c" ], "editorial_references": [ "round517.html", "round517-sources.json" ], "qualification": "This verdict does not deny AX.25 source routing through digipeaters. It distinguishes the selected NET/ROM socket service from raw AX.25 operation and administrative route provisioning. Linux exposes the route modification path under CAP_NET_ADMIN; nr_route_frame uses the selected neighbor and its configured digipeater path. A separate raw AX.25 endpoint or application-controlled route mechanism would require an explicit composition change. No runtime path test was performed." }, { "id": "F28-BA", "feature": "F28", "stack": "BA", "status": "N", "reason": "In Linux v6.12, batadv_send_skb_to_orig calls batadv_find_router for the destination originator. The latter uses the learned router and, when bonding is enabled, automatically rotates suitable candidates. The payload-facing bat0 service and declared unicast headers provide no endpoint-selected intermediary sequence or constraint carried through the mesh.", "method": "Pinned Linux v6.12 source and primary documentation; no runtime test", "source_label": "Selected BATMAN_IV/native Ethernet composition", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h", "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batman_adv.h" ], "editorial_references": [ "round478.html", "round478-sources.json" ], "qualification": "Interface attachment, local algorithm/metric settings and automatic bonding remain available. They do not supply the endpoint path control required by F28 beyond selecting local access. Gateway mode is off in this composition. Diagnostic route recording is observation, not an enforced payload path; no added source-routing overlay is credited." }, { "id": "F28-BL", "feature": "F28", "stack": "BL", "status": "N", "reason": "Babel selects feasible routes using routing information and local policy. The selected IPv6/Babel composition exposes ordinary destination-based forwarding, not a sender interface to select or exclude downstream intermediaries. Selecting a local next hop or adjusting administrative route metrics does not enforce an endpoint-chosen path beyond that hop.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Babel route selection, LISP RLOC selection and RPL source routing", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.6" ], "editorial_references": [ "round513.html", "round513-sources.json" ], "qualification": "RFC 8966 section 3.6 permits routing policy and implementation choices, but does not define an endpoint path-selection contract. The fixed aggregate hierarchy used for the separate G01 witness likewise does not supply such an interface. No source-routing extension, tunnel chain or application path-control service is selected. This does not deny administrator traffic engineering or automatic route recovery." }, { "id": "F28-RI", "feature": "F28", "stack": "RI", "status": "N", "reason": "The selected IPv6 IoT endpoint is a RPL leaf. In non-storing operation, routers collect routing information and insert the RFC 6554 source route for downward delivery. That infrastructure-selected path does not expose an endpoint interface to choose or exclude downstream intermediaries; selecting a parent or local access alone does not satisfy F28.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Babel route selection, LISP RLOC selection and RPL source routing", "sources": [ "https://www.rfc-editor.org/rfc/rfc6554.html#section-2", "https://www.rfc-editor.org/rfc/rfc6554.html#section-4.1" ], "editorial_references": [ "round513.html", "round513-sources.json" ], "qualification": "RPL does contain genuine source routing: the header specifies IPv6 hops inside its routing domain. This verdict does not erase that feature. It distinguishes the selected leaf endpoint role from a router constructing the header; an endpoint acting as a suitably informed RPL router would be a different qualified role. Domain-boundary restrictions and the selected OF0 routing behavior remain unchanged. No added path-selection application is credited." }, { "id": "F28-HP", "feature": "F28", "stack": "HP", "status": "N", "reason": "The selected HIP composition uses RFC 8046 host mobility: LOCATOR_SET communicates reachable peer addresses and preferences while preserving the host identity and ESP association. It does not expose selection or exclusion of forwarding intermediaries beyond endpoint locators and local attachment. IP routing still chooses the transit path.", "method": "Primary specification review; no runtime experiment", "source_label": "RFC 6740 and RFC 8046 architectural review", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc8046.html#section-1", "https://www.rfc-editor.org/rfc/rfc8046.html#section-5.5" ], "editorial_references": [ "round519.html", "round519-sources.json" ], "qualification": "This verdict concerns HIPv2/ESP with RFC 8046 as selected, not all possible HIP extensions or IP routing configurations. RFC 8046 explicitly leaves multihoming procedures to RFC 8047, which is not selected here. Address verification and preferred-locator changes enable mobility but do not establish an endpoint-controlled intermediary segment. The RFC's discussion of an attacker using an IPv6 Routing header is not a selected HIP path-control service. No runtime experiment or claim that HIP prevents other-layer path control." }, { "id": "F28-CX", "feature": "F28", "stack": "CX", "status": "N", "reason": "In the selected CCNx 1.0 composition, the consumer selects a content name and optional validation restrictions. Forwarders choose next hops using their FIB and local forwarding policy; the Interest does not carry an endpoint-chosen sequence or constraint on intermediate forwarders. The selected static prefix routes are administrative configuration, not an endpoint path-selection interface.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Reticulum Transport path selection and CCNx forwarding semantics", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.2", "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.4" ], "editorial_references": [ "round514.html", "round514-sources.json" ], "qualification": "ContentObjectHashRestriction and KeyIdRestriction constrain acceptable content, not the forwarding trajectory. HopLimit bounds traversal length without naming or excluding intermediaries. An endpoint FIB can select its local next hop, but does not impose the downstream route. Custom name conventions, routing extensions or overlay chains are not selected. Named-content retrieval and caching retain their separate positive assessments." }, { "id": "F28-LI", "feature": "F28", "stack": "LI", "status": "N", "reason": "In the selected LISP composition, the ITR selects a destination RLOC from the EID mapping and encapsulates the endpoint packet. RLOC priorities, weights and the selected load-sharing witness concern tunnel-router decisions; they do not give the sending application endpoint an interface to select the forwarding intermediaries.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Babel route selection, LISP RLOC selection and RPL source routing", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-9", "https://www.rfc-editor.org/rfc/rfc9300.html#section-4.2" ], "editorial_references": [ "round513.html", "round513-sources.json" ], "qualification": "The positive concurrent-path witness in F09 is an ITR policy, not endpoint path control. End hosts remain ordinary inner-IPv4 endpoints in this column. No co-located endpoint xTR, explicit locator path extension or endpoint-to-ITR path-selection API is selected. LISP traffic engineering remains a capability of the infrastructure, without implying F28 for this composition." }, { "id": "F28-IL", "feature": "F28", "stack": "IL", "status": "Y", "reason": "RFC 6740 sections 3.2 and 5.1 expose host policy for locator selection. Its single-interface example lets the endpoint insert a source locator associated with an upstream provider; the site border router can use that locator to select the egress link. This provides provider-segment choice beyond selecting a local interface.", "method": "Primary specification review; no runtime experiment", "source_label": "RFC 6740 and RFC 8046 architectural review", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-5.1", "https://www.rfc-editor.org/rfc/rfc6740.html#section-3.2" ], "editorial_references": [ "round519.html", "round519-sources.json" ], "qualification": "Bounded witness: distinct provider locators advertised on one interface and a border-router policy mapping each source locator to its corresponding provider link. Other border policies can override this choice; the capability is conditional on that explicit configuration. No arbitrary transit-node selection or cryptographic path enforcement is claimed. Withdrawal requires locator/cache updates and may disrupt traffic; uninterrupted failover is not established. This is native ILNP host control, not multipath TCP, and does not alter the separate mobility witness or qualify an executable implementation." }, { "id": "F28-TS", "feature": "F28", "stack": "TS", "status": "Y", "reason": "Linux endpoints can constrain their DERP intermediary through the existing TS_DEBUG_USE_DERP_ADDR and TS_DEBUG_ALWAYS_USE_DERP controls. setDERPMap replaces the control-provided map with one hostname in synthetic region 999, omits other regions, and defaults to HTTPS/443. bindSocket disables normal UDP sockets when always-DERP is enabled. Peers must use matching maps. The author of issue 7841 explicitly confirms that this combination works when communicating clients agree on the map; the reported failure mixed a normal control map with overridden maps. This supplies the missing compatibility evidence and supports a bounded source inference for F28: selecting an accessible managed DERP hostname constrains the relay contact while retaining the selected components.", "method": "Pinned source inference corroborated by developer exchange report; no local runtime test", "source_label": "Tailscale issue 7841 follow-up and magicsock sources at 566f89e0fb2a", "sources": [ "https://github.com/tailscale/tailscale/issues/7841#issuecomment-1518491495", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/debugknobs.go", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/derp.go", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/magicsock.go" ], "editorial_references": [ "round600.html", "round600-sources.json" ], "qualification": "Advanced/debug configuration requiring control of daemon startup and matching configuration at both endpoints, not an ordinary per-flow path selector or unilateral steering of an unmodified remote peer. Use a managed DERP hostname with valid TLS; HTTP-only development mode, self-hosted relays and Headscale are not added to the selected profile. The issue describes a developer test, not a current managed-service qualification; the HTTPS managed-host application is source inference and was not exercised here. Granularity is the selected relay hostname/service, not hidden IP hops or every internal regional mesh server. An unavailable or mismatched sole region can break delivery; no fallback to an omitted region is credited. Tailnet Lock, authorization and control-service dependencies remain. F28 requires a capability and enforcement mechanism, not production-support certification." }, { "id": "F28-RA", "feature": "F28", "stack": "RA", "status": "N", "reason": "The selected application API requests a remote application and QoS. Its optional DIF argument is advisory and may be ignored. Link-state forwarding is selected by the IPC machinery; the application interface supplies no enforceable inclusion or exclusion of intermediate nodes or domains. Choosing a local access in the mobility manager is insufficient for F28.", "method": "Primary API, forwarding-policy documentation and pinned source assessment; no execution", "source_label": "IRATI application API and selected forwarding behavior", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Application-API.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/default.dif", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md" ], "editorial_references": [ "round660.html" ], "qualification": "No for the selected endpoint service. Administrator-installed routing policies are not an exposed per-communication endpoint path-selection contract. Another policy or API could add such control; no impossibility claim about RINA as a framework." }, { "id": "F29-PN", "feature": "F29", "stack": "PN", "status": "Y", "reason": "The selected content-rendezvous witness uses an ALIAS representing the requested content. PRP discovery returns candidate participants under that reference, so the requester does not select a server in advance. The author confirmed content retrieval as an intended ALIAS use. Subsequent transfer by an application does not negate supplier discovery by content reference.", "method": "Scoped architectural composition; primary SCIR rules and attributed author clarification", "source_label": "Author clarification and explicitly selected architectural witness; provenance separated in round465-sources.json", "sources": [], "editorial_references": [ "round465.html#F29", "round465-sources.json" ], "qualification": "Architectural Yes for the explicitly selected content-ALIAS use, not every ALIAS. Generic rendezvous text alone neither certifies content availability nor grants access. The content convention, transfer and candidate authentication must be stated; no NDN-style Interest/Data wire or implementation-completeness claim is inferred." }, { "id": "F29-PI", "feature": "F29", "stack": "PI", "status": "Y", "reason": "The selected content-rendezvous witness uses an ALIAS representing the requested content. PRP discovery returns candidate participants under that reference, so the requester does not select a server in advance. The author confirmed content retrieval as an intended ALIAS use. Subsequent transfer by an application does not negate supplier discovery by content reference.", "method": "Scoped architectural composition; primary SCIR rules and attributed author clarification", "source_label": "Author clarification and explicitly selected architectural witness; provenance separated in round465-sources.json", "sources": [], "editorial_references": [ "round465.html#F29", "round465-sources.json" ], "qualification": "Architectural Yes for the explicitly selected content-ALIAS use, not every ALIAS. Generic rendezvous text alone neither certifies content availability nor grants access. The content convention, transfer and candidate authentication must be stated; no NDN-style Interest/Data wire or implementation-completeness claim is inferred." }, { "id": "F29-IP", "feature": "F29", "stack": "IP", "status": "N", "reason": "IPv4/IPv6 forwards datagrams toward destination addresses, not named content objects.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "DNS, a content lookup protocol and a content delivery application are not selected. Numeric destination routing is not named-content retrieval." }, { "id": "F29-BP", "feature": "F29", "stack": "BP", "status": "N", "reason": "BP routes bundles to destination EIDs. Bundle identifiers distinguish transmissions; neither identifier is a selected content-to-supplier lookup service. The BP profile allows collective endpoint names, but selects no content-to-supplier binding.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "No for the declared composition, not a prohibition on content applications over BP. A content naming/registration convention and supplier lookup could be added, but are not selected here. BPSec verification, contact-route computation and convergence-layer delivery do not supply that missing service." }, { "id": "F29-CG", "feature": "F29", "stack": "CG", "status": "N", "reason": "BP routes bundles to destination EIDs. Bundle identifiers distinguish transmissions; neither identifier is a selected content-to-supplier lookup service. This profile explicitly selects singleton destinations and no shared-reference directory.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "No for the declared composition, not a prohibition on content applications over BP. A content naming/registration convention and supplier lookup could be added, but are not selected here. BPSec verification, contact-route computation and convergence-layer delivery do not supply that missing service." }, { "id": "F29-LT", "feature": "F29", "stack": "LT", "status": "N", "reason": "BP routes bundles to destination EIDs. Bundle identifiers distinguish transmissions; neither identifier is a selected content-to-supplier lookup service. This profile explicitly selects singleton destinations and no shared-reference directory.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "No for the declared composition, not a prohibition on content applications over BP. A content naming/registration convention and supplier lookup could be added, but are not selected here. BPSec verification, contact-route computation and convergence-layer delivery do not supply that missing service." }, { "id": "F29-LP", "feature": "F29", "stack": "LP", "status": "N", "reason": "Direct-peer libp2p over QUIC addresses peers, locators or transport connections rather than resolving a content reference to a supplier. Known numeric peers and Peer IDs; no content-routing, object-transfer or pubsub module is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No applies to this composition, not to every application that could use it. No additional content-rendezvous convention is selected; generic byte transport or participant naming alone does not satisfy F29." }, { "id": "F29-TO", "feature": "F29", "stack": "TO", "status": "N", "reason": "Tor onion-service transport finds or addresses participants/services rather than locating a supplier from a content reference. Onion-service identity, rendezvous descriptors and circuit protection are control/transport functions; no content application is selected.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "This No is limited to the declared composition. A separate content-reference profile could change the assessment, but none is selected here." }, { "id": "F29-I2", "feature": "F29", "stack": "I2", "status": "N", "reason": "I2P destination/tunnel transport finds or addresses participants/services rather than locating a supplier from a content reference. Known destination keys and NTCP2/tunnels are selected; file sharing, mailboxes and content applications are not.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "This No is limited to the declared composition. A separate content-reference profile could change the assessment, but none is selected here." }, { "id": "F29-YG", "feature": "F29", "stack": "YG", "status": "N", "reason": "Yggdrasil IPv6 overlay finds or addresses participants/services rather than locating a supplier from a content reference. The selected service carries application UDP between cryptographic node addresses, without a content-service extension.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "This No is limited to the declared composition. A separate content-reference profile could change the assessment, but none is selected here." }, { "id": "F29-CJ", "feature": "F29", "stack": "CJ", "status": "N", "reason": "cjdns IPv6 overlay finds or addresses participants/services rather than locating a supplier from a content reference. The selected ordinary application path carries UDP between node addresses; route-server discovery and route labels are not content naming.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "This No is limited to the declared composition. A separate content-reference profile could change the assessment, but none is selected here." }, { "id": "F29-MQ", "feature": "F29", "stack": "MQ", "status": "N", "reason": "Multipath QUIC addresses peers, locators or transport connections rather than resolving a content reference to a supplier. Selected multipath-21 manages paths for QUIC connections; it adds no content-object service.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No applies to this composition, not to every application that could use it. No additional content-rendezvous convention is selected; generic byte transport or participant naming alone does not satisfy F29." }, { "id": "F29-SC", "feature": "F29", "stack": "SC", "status": "N", "reason": "SCION forwards using link or endpoint/path identifiers, not a content-reference lookup that chooses a supplier or content replica.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "No content-rendezvous profile or content-retrieval layer is selected. Transporting an application that could implement one does not itself supply the capability." }, { "id": "F29-RT", "feature": "F29", "stack": "RT", "status": "N", "reason": "A Reticulum Resource advertisement is sent on an already selected Link to its peer. Destination hashes bind application/aspect naming to identity; request-handler paths are resolved at that destination. Resource hashes and part maps coordinate the chosen transfer, not network-wide supplier selection by content reference.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Resource.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Destination.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "No for the selected Link profile. A custom request handler could implement a content service, but its callable and content-discovery convention would be additional application functionality. Resource advertisement is explicitly considered and is not interpreted as a network supplier announcement." }, { "id": "F29-NS", "feature": "F29", "stack": "NS", "status": "Y", "reason": "NIP-01 defines an event ID as a digest of the serialized event and a REQ ids filter. Within the selected configured relay pool, a client can query the same exact event ID at multiple relays and accept a matching returned copy without knowing beforehand which relay stores it. The event reference, rather than a fixed origin-server address, selects the requested object.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "NIP-01 event queries and Reticulum 1.5.5 Resource evidence", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round510.html", "round510-sources.json" ], "qualification": "Bounded application-layer retrieval from configured candidate relays: the client still opens WebSocket connections to those relays, which are explicit service dependencies. This is not global relay discovery, inter-relay request forwarding or guaranteed availability. The credited behavior does not require choosing one specific supplier in advance, but it does require knowing a relay pool and the event ID. Limit the witness to retained regular events queried by exact ID; verify the returned event digest/signature. Replaceable-event latest-version discovery and external files linked in content are not inferred." }, { "id": "F29-MT", "feature": "F29", "stack": "MT", "status": "N", "reason": "The selected Meshtastic message service addresses a node or channel. MeshPacket.id identifies a sender packet, and Data.request_id/reply_id correlate routing reports or responses. These fields do not bind a named content reference to supplier discovery or cache selection. The selected direct-message/channel composition contains no content-reference retrieval service.", "method": "Pinned firmware source and primary documentation; no runtime test", "source_label": "Meshtastic selected firmware 8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/mesh.pb.h", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/StoreForwardModule.cpp", "https://meshtastic.org/docs/configuration/module/store-and-forward-module/" ], "editorial_references": [ "round480.html", "round480-sources.json" ], "qualification": "A channel broadcast can reach many participants, and an added application could ask them for content. That added request/response convention is not part of the declared composition. Node discovery, packet correlation and payload signatures do not independently supply F29. Store-and-forward is explicitly disabled; its separate history feature is not silently added to this profile." }, { "id": "F29-GN", "feature": "F29", "stack": "GN", "status": "N", "reason": "GNUnet CADET finds or addresses participants/services rather than locating a supplier from a content reference. The selected CADET channels and R5N peer discovery exclude the separate GNUnet file-sharing, GNS and Messenger subsystems.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "This No is limited to the declared composition. A separate content-reference profile could change the assessment, but none is selected here." }, { "id": "F29-ND", "feature": "F29", "stack": "ND", "status": "Y", "reason": "An Interest names the requested Data; forwarding, matching and the Content Store can supply that Data without the consumer first choosing its producer or cache.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NDN-packet-spec/current/data.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Known names and configured FIBs are retained. No global name discovery, arbitrary semantic search or guaranteed content availability is inferred." }, { "id": "F29-AX", "feature": "F29", "stack": "AX", "status": "N", "reason": "AX.25/NET/ROM finds or addresses participants/services rather than locating a supplier from a content reference. The selected radio/serial network and transport circuits use callsign/SSID addressing; no BBS, mailbox or added cryptographic application is selected.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://linux-ax25.in-berlin.de/wiki/NET/ROM", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "This No is limited to the declared composition. A separate content-reference profile could change the assessment, but none is selected here." }, { "id": "F29-BA", "feature": "F29", "stack": "BA", "status": "N", "reason": "batman-adv forwards using link or endpoint/path identifiers, not a content-reference lookup that chooses a supplier or content replica.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/Documentation/networking/batman-adv.rst" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "No content-rendezvous profile or content-retrieval layer is selected. Transporting an application that could implement one does not itself supply the capability." }, { "id": "F29-BL", "feature": "F29", "stack": "BL", "status": "N", "reason": "IPv6/Babel addresses peers, locators or transport connections rather than resolving a content reference to a supplier. Babel maintains prefix reachability for IPv6 datagrams; no application content protocol or cryptographic payload layer is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No applies to this composition, not to every application that could use it. No additional content-rendezvous convention is selected; generic byte transport or participant naming alone does not satisfy F29." }, { "id": "F29-RI", "feature": "F29", "stack": "RI", "status": "N", "reason": "6LoWPAN/IPv6/RPL/UDP/DTLS addresses peers, locators or transport connections rather than resolving a content reference to a supplier. Selected endpoint leaves use non-storing RPL and pairwise DTLS PSKs; no CoAP, MQTT, object-security or content-service layer is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No applies to this composition, not to every application that could use it. No additional content-rendezvous convention is selected; generic byte transport or participant naming alone does not satisfy F29." }, { "id": "F29-HP", "feature": "F29", "stack": "HP", "status": "N", "reason": "HIPv2/ESP with application UDP addresses peers, locators or transport connections rather than resolving a content reference to a supplier. HIP identifies hosts and ESP protects host-to-host packets; no content-service or application-authentication wrapper is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No applies to this composition, not to every application that could use it. No additional content-rendezvous convention is selected; generic byte transport or participant naming alone does not satisfy F29." }, { "id": "F29-CX", "feature": "F29", "stack": "CX", "status": "Y", "reason": "CCNx Interests identify content by name and optional restrictions; forwarders can return matching Content Objects from a producer or Content Store without prior consumer selection of that supplier.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "The selected static prefix FIB and known names remain necessary. No unselected dynamic name-discovery service is credited." }, { "id": "F29-LI", "feature": "F29", "stack": "LI", "status": "N", "reason": "LISP forwards using link or endpoint/path identifiers, not a content-reference lookup that chooses a supplier or content replica.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "No content-rendezvous profile or content-retrieval layer is selected. Transporting an application that could implement one does not itself supply the capability." }, { "id": "F29-IL", "feature": "F29", "stack": "IL", "status": "N", "reason": "ILNPv6/TCP addresses peers, locators or transport connections rather than resolving a content reference to a supplier. Identifier/Locator separation and DNS NID/L64 records address participants and their locations; no content-reference, IPsec or application-security layer is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No applies to this composition, not to every application that could use it. No additional content-rendezvous convention is selected; generic byte transport or participant naming alone does not satisfy F29." }, { "id": "F29-TS", "feature": "F29", "stack": "TS", "status": "N", "reason": "The selected packet service addresses peer nodes, not content references resolved to suppliers. It provides no content-reference-to-supplier binding.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "Inference from the declared service boundary. Content discovery added by an application would be a different composition." }, { "id": "F29-RA", "feature": "F29", "stack": "RA", "status": "N", "reason": "The selected RINA service allocates a flow to a named remote application and exchanges SDUs with it. An application name selects a communication peer, not a content reference bound to an object or its suppliers. No content-discovery application is selected.", "method": "Selected-service boundary assessment using primary API documentation; no execution", "source_label": "IRATI application API: registration, flow allocation and SDU exchange", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Application-API.md", "https://github.com/IRATI/stack/wiki/Application-API" ], "editorial_references": [ "round653.html" ], "qualification": "No verdict on whether a separate application could implement content discovery over RINA. Application naming and placement independence alone do not meet F29." }, { "id": "F30-PN", "feature": "F30", "stack": "PN", "status": "Y", "reason": "The selected digest-bound ALIAS witness forms the rendezvous text from a canonical cryptographic digest of the object. A recipient with an independently trusted expected ALIAS can hash the received bytes, reconstruct that text and SCIR, and compare the reference regardless of the supplier or delivery connection. This supplies reference-based object integrity/authenticity without requiring an origin signature.", "method": "Scoped architectural composition; primary SCIR rules and attributed author clarification", "source_label": "Author clarification and explicitly selected architectural witness; provenance separated in round465-sources.json", "sources": [], "editorial_references": [ "round465.html#F30", "round465-sources.json" ], "qualification": "Explicit composition witness, not a universal ALIAS property or an already standardized content profile. For concreteness the assessment uses the text sha256: followed by 64 lowercase hexadecimal digits of SHA-256 over the exact object bytes, with a fixed supported ALIAS reference suite known to the recipient. This convention is an editorial witness, not a registered PRP namespace or new wire assignment. The expected ALIAS must be trusted independently of the untrusted supplier. Hashing/verification is performed by the consumer. Titles and search-term aliases do not qualify; no authorship, freshness or replay guarantee follows." }, { "id": "F30-PI", "feature": "F30", "stack": "PI", "status": "Y", "reason": "The selected digest-bound ALIAS witness forms the rendezvous text from a canonical cryptographic digest of the object. A recipient with an independently trusted expected ALIAS can hash the received bytes, reconstruct that text and SCIR, and compare the reference regardless of the supplier or delivery connection. This supplies reference-based object integrity/authenticity without requiring an origin signature.", "method": "Scoped architectural composition; primary SCIR rules and attributed author clarification", "source_label": "Author clarification and explicitly selected architectural witness; provenance separated in round465-sources.json", "sources": [], "editorial_references": [ "round465.html#F30", "round465-sources.json" ], "qualification": "Explicit composition witness, not a universal ALIAS property or an already standardized content profile. For concreteness the assessment uses the text sha256: followed by 64 lowercase hexadecimal digits of SHA-256 over the exact object bytes, with a fixed supported ALIAS reference suite known to the recipient. This convention is an editorial witness, not a registered PRP namespace or new wire assignment. The expected ALIAS must be trusted independently of the untrusted supplier. Hashing/verification is performed by the consumer. Titles and search-term aliases do not qualify; no authorship, freshness or replay guarantee follows." }, { "id": "F30-IP", "feature": "F30", "stack": "IP", "status": "N", "reason": "The selected bare IP composition contains no cryptographic object-authentication mechanism. IPv4 header checksums and link checks do not authenticate content.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "IPsec, TLS and application signatures are not selected; no object-verification capability is inherited from them." }, { "id": "F30-BP", "feature": "F30", "stack": "BP", "status": "Y", "reason": "The selected BPSec integrity blocks protect bundle targets with HMAC under provisioned final-pair keys. The security acceptor can verify those stored blocks after forwarding across different contacts or convergence-layer sessions.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9172.html", "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Object-level verification is recipient/key scoped, not a publicly verifiable producer signature. Required primary/payload coverage and exact key bindings remain as declared in the profile. Transit holders of only encrypted copies gain no origin authority. Complete-composition integration qualifications remain." }, { "id": "F30-CG", "feature": "F30", "stack": "CG", "status": "Y", "reason": "The selected BPSec integrity blocks protect bundle targets with HMAC under provisioned final-pair keys. The security acceptor can verify those stored blocks after forwarding across different contacts or convergence-layer sessions.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9172.html", "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Object-level verification is recipient/key scoped, not a publicly verifiable producer signature. Required primary/payload coverage and exact key bindings remain as declared in the profile. Transit holders of only encrypted copies gain no origin authority. Complete-composition integration qualifications remain." }, { "id": "F30-LT", "feature": "F30", "stack": "LT", "status": "Y", "reason": "The selected BPSec integrity blocks protect bundle targets with HMAC under provisioned final-pair keys. The security acceptor can verify those stored blocks after forwarding across different contacts or convergence-layer sessions.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9172.html", "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Object-level verification is recipient/key scoped, not a publicly verifiable producer signature. Required primary/payload coverage and exact key bindings remain as declared in the profile. Transit holders of only encrypted copies gain no origin authority. Complete-composition integration qualifications remain." }, { "id": "F30-LP", "feature": "F30", "stack": "LP", "status": "N", "reason": "TLS protects QUIC traffic and authenticates peers; it does not attach reusable origin evidence to application objects.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Known numeric peers and Peer IDs; no content-routing, object-transfer or pubsub module is selected. No consumer-side object-signing or independently trusted content-digest profile is selected. This does not negate the security of the established transport where present." }, { "id": "F30-TO", "feature": "F30", "stack": "TO", "status": "N", "reason": "Tor onion-service transport does not attach a selected independently verifiable proof or trusted digest reference to application content objects. Onion-service identity, rendezvous descriptors and circuit protection are control/transport functions; no content application is selected.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Transport authentication, key exchange, signed routing/descriptor records and integrity checks do not authenticate arbitrary delivered content. No object-verification convention is selected; this does not deny transport security where provided." }, { "id": "F30-I2", "feature": "F30", "stack": "I2", "status": "N", "reason": "I2P destination/tunnel transport does not attach a selected independently verifiable proof or trusted digest reference to application content objects. Known destination keys and NTCP2/tunnels are selected; file sharing, mailboxes and content applications are not.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Transport authentication, key exchange, signed routing/descriptor records and integrity checks do not authenticate arbitrary delivered content. No object-verification convention is selected; this does not deny transport security where provided." }, { "id": "F30-YG", "feature": "F30", "stack": "YG", "status": "N", "reason": "Yggdrasil IPv6 overlay does not attach a selected independently verifiable proof or trusted digest reference to application content objects. The selected service carries application UDP between cryptographic node addresses, without a content-service extension.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Transport authentication, key exchange, signed routing/descriptor records and integrity checks do not authenticate arbitrary delivered content. No object-verification convention is selected; this does not deny transport security where provided." }, { "id": "F30-CJ", "feature": "F30", "stack": "CJ", "status": "N", "reason": "cjdns IPv6 overlay does not attach a selected independently verifiable proof or trusted digest reference to application content objects. The selected ordinary application path carries UDP between node addresses; route-server discovery and route labels are not content naming.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Transport authentication, key exchange, signed routing/descriptor records and integrity checks do not authenticate arbitrary delivered content. No object-verification convention is selected; this does not deny transport security where provided." }, { "id": "F30-MQ", "feature": "F30", "stack": "MQ", "status": "N", "reason": "QUIC/TLS protection is connection- and packet-key scoped; the multipath extension does not define independently verifiable application objects.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Selected multipath-21 manages paths for QUIC connections; it adds no content-object service. No consumer-side object-signing or independently trusted content-digest profile is selected. This does not negate the security of the established transport where present." }, { "id": "F30-SC", "feature": "F30", "stack": "SC", "status": "N", "reason": "SCION in the selected profile provides no independently verifiable application-object signature, MAC or trusted content-reference construction.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Link checks, mapping information or path authentication are distinct from content-object authentication. No additional object-signing application or trusted digest profile is selected." }, { "id": "F30-RT", "feature": "F30", "stack": "RT", "status": "N", "reason": "The selected Reticulum 1.5.5 Link composition authenticates the live communication context, while Resource uses transfer hashes and a receipt proof derived from data and the resource hash. It does not attach an origin signature or independently provisioned trusted content reference to the Resource for verification after re-serving through another connection.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "NIP-01 event queries and Reticulum 1.5.5 Resource evidence", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Resource.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [ "round510.html", "round510-sources.json" ], "qualification": "A hash advertised by the same supplier and a proof returned by the receiver are not independent origin evidence. Link.identify authenticates a peer in the Link, not a reusable object wrapper. An application could retain a digest obtained over an authenticated Link as a trusted reference, or use Identity signing to define signed objects; neither object-verification profile is selected here. LXMF is also excluded. This No does not deny transfer integrity, transport authentication, or the availability of generic signing primitives." }, { "id": "F30-NS", "feature": "F30", "stack": "NS", "status": "Y", "reason": "NIP-01 event IDs commit to serialized event fields, and Schnorr signatures authenticate those events under the author public key. Readers can verify the same event received through different relays or connections.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Readers must verify the ID and signature and apply their author-trust policy. This proves key authorship, not civil identity, freshness or access control." }, { "id": "F30-MT", "feature": "F30", "stack": "MT", "status": "Y", "reason": "The selected firmware supplies object-level authenticity for signable channel broadcasts. Router.cpp perhapsEncode signs locally originated non-PKI broadcasts when signedDataFits succeeds. CryptoEngine buildSigningBuffer binds the payload to version, sender, packet ID, recipient, port, request/reply IDs, emoji, bitfield and flags. xeddsa_verify needs that retained envelope, signature and sender public key, not a live transport session. Preserving these inputs therefore permits verification after relay delivery or storage, satisfying F30 at this bounded object scope.", "method": "Pinned signing and verification source trace; no runtime test", "source_label": "Selected Meshtastic firmware; signable broadcast witness", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/CryptoEngine.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/mesh.pb.h" ], "editorial_references": [ "round481.html", "round481-sources.json" ], "qualification": "Yes for XEdDSA-enabled builds and broadcasts fitting the signed encoding, with the sender public key independently trusted. Normal-mode PKI direct messages are not automatically signed by this branch and do not inherit the witness. Preserve the signed envelope, not just the payload or a serialized xeddsa_signed flag. Hop/relay fields and channel representation are outside the signature; changing covered fields invalidates it. A stored signature supplies no freshness, anti-replay guarantee, civil identity, key-revocation history or secure archival storage. This is a source-qualified capability, not an executed archive/restore test or cryptographic audit." }, { "id": "F30-GN", "feature": "F30", "stack": "GN", "status": "N", "reason": "GNUnet CADET does not attach a selected independently verifiable proof or trusted digest reference to application content objects. The selected CADET channels and R5N peer discovery exclude the separate GNUnet file-sharing, GNS and Messenger subsystems.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Transport authentication, key exchange, signed routing/descriptor records and integrity checks do not authenticate arbitrary delivered content. No object-verification convention is selected; this does not deny transport security where provided." }, { "id": "F30-ND", "feature": "F30", "stack": "ND", "status": "Y", "reason": "The selected ECDSA-signed Data object carries a signature over its name, metadata and content. A consumer with the selected trust anchors can verify it after delivery from another forwarder or cache.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NDN-packet-spec/current/data.html", "https://docs.named-data.net/NDN-packet-spec/current/signature.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Producer-key authorization and actual consumer verification are required. A signature alone does not guarantee freshness or the truth of the content." }, { "id": "F30-AX", "feature": "F30", "stack": "AX", "status": "N", "reason": "AX.25/NET/ROM does not attach a selected independently verifiable proof or trusted digest reference to application content objects. The selected radio/serial network and transport circuits use callsign/SSID addressing; no BBS, mailbox or added cryptographic application is selected.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://linux-ax25.in-berlin.de/wiki/NET/ROM", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Transport authentication, key exchange, signed routing/descriptor records and integrity checks do not authenticate arbitrary delivered content. No object-verification convention is selected; this does not deny transport security where provided." }, { "id": "F30-BA", "feature": "F30", "stack": "BA", "status": "N", "reason": "batman-adv in the selected profile provides no independently verifiable application-object signature, MAC or trusted content-reference construction.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/Documentation/networking/batman-adv.rst" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Link checks, mapping information or path authentication are distinct from content-object authentication. No additional object-signing application or trusted digest profile is selected." }, { "id": "F30-BL", "feature": "F30", "stack": "BL", "status": "N", "reason": "The selected IPv6/Babel composition does not cryptographically authenticate application objects. Routing checks and packet checksums are insufficient.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Babel maintains prefix reachability for IPv6 datagrams; no application content protocol or cryptographic payload layer is selected. No consumer-side object-signing or independently trusted content-digest profile is selected. This does not negate the security of the established transport where present." }, { "id": "F30-RI", "feature": "F30", "stack": "RI", "status": "N", "reason": "DTLS record protection is association/epoch scoped. The selected pairwise PSK handshake does not create a reusable signed or MACed content-object envelope.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Selected endpoint leaves use non-storing RPL and pairwise DTLS PSKs; no CoAP, MQTT, object-security or content-service layer is selected. No consumer-side object-signing or independently trusted content-digest profile is selected. This does not negate the security of the established transport where present." }, { "id": "F30-HP", "feature": "F30", "stack": "HP", "status": "N", "reason": "ESP integrity is scoped to security associations. HIP identity signatures authenticate protocol exchanges, not arbitrary application objects.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "HIP identifies hosts and ESP protects host-to-host packets; no content-service or application-authentication wrapper is selected. No consumer-side object-signing or independently trusted content-digest profile is selected. This does not negate the security of the established transport where present." }, { "id": "F30-CX", "feature": "F30", "stack": "CX", "status": "Y", "reason": "The selected ECDSA-SHA256 Content Object validation binds the protected object to a producer key trusted by the consumer, independently of the supplying UDP peer or cache.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Credit is for the selected signature profile, not CRC32C Interests or every optional CCNx validation algorithm. Trust and consumer verification remain necessary." }, { "id": "F30-LI", "feature": "F30", "stack": "LI", "status": "N", "reason": "LISP in the selected profile provides no independently verifiable application-object signature, MAC or trusted content-reference construction.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Link checks, mapping information or path authentication are distinct from content-object authentication. No additional object-signing application or trusted digest profile is selected." }, { "id": "F30-IL", "feature": "F30", "stack": "IL", "status": "N", "reason": "The selected ILNP/TCP stack has no object signature, keyed object MAC or trusted digest-reference mechanism. Locator-update nonces do not supply one.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Identifier/Locator separation and DNS NID/L64 records address participants and their locations; no content-reference, IPsec or application-security layer is selected. No consumer-side object-signing or independently trusted content-digest profile is selected. This does not negate the security of the established transport where present." }, { "id": "F30-TS", "feature": "F30", "stack": "TS", "status": "N", "reason": "WireGuard authenticates encrypted packets within its peer session. This does not provide reusable object evidence against a trusted origin or reference after delivery over another connection.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "The selected profile includes no content signature or trusted object-digest protocol. Tailnet Lock authenticates node admission, not arbitrary delivered objects." }, { "id": "F30-RA", "feature": "F30", "stack": "RA", "status": "N", "reason": "The selected normal-DIF service delivers SDUs through application flows. Its SDU-protection boundary protects and exposes data on underlying flows; the application API delivers data and peer naming information, not a portable authenticated object with origin-verification evidence. No object-signing or trusted content-reference layer is included in this composition. It therefore does not supply F30 object authenticity across storage or delivery through a different connection.", "method": "Selected-service boundary assessment from application API and SDU-protection architecture", "source_label": "IRATI application API and software architecture: SDU Protection", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Application-API.md", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round657.html" ], "qualification": "No applies to the declared composition, not to all applications or possible RINA policies. An application can add signed objects above RINA, but that would add a layer absent from this column. This decision does not deny available channel-protection policies and does not resolve F06 or F07. No runtime test or cryptographic audit." }, { "id": "F31-PN", "feature": "F31", "stack": "PN", "status": "Y", "reason": "PRP custody belongs to E2E and multicast channels, with negotiated responsibility and the applicable channel authorization. The F31 architectural witness is the previously author-confirmed reuse within authorized multicast delivery: an intermediary can use its retained unit for additional authorized consumers or branches without reacquiring that unit from the origin. This is not a public object-custody service. E2E retention for its original recipient alone remains the separate F11/F18 capability and does not independently establish F31.", "method": "Architectural scope reconciliation; no runtime test", "source_label": "Author clarification: E2E/multicast channel custody; pinned custody amendments; earlier authorized-reuse witness", "sources": [], "editorial_references": [ "round467.html", "round467-scope.json", "round466-sources.json", "round465-sources.json" ], "qualification": "Author clarification in round467 narrows the earlier wording: there is no public CDN-style object custody. Retained units are not made available to arbitrary requesters, and knowing or announcing an ALIAS grants no access to them. Custody does not confer reading keys, authority to admit listeners or permission to move payload into an unrelated channel. F31 does not require public access; its Yes is limited to the previously confirmed authorized multicast reuse, not every custody operation or all E2E channels. The pinned amendments in round466 specify custody policy, acceptance and delivery scope; exact later-request matching, negotiation procedures, release conditions and formats remain unqualified. No implementation or interoperability claim is added." }, { "id": "F31-PI", "feature": "F31", "stack": "PI", "status": "Y", "reason": "PRP custody belongs to E2E and multicast channels, with negotiated responsibility and the applicable channel authorization. The F31 architectural witness is the previously author-confirmed reuse within authorized multicast delivery: an intermediary can use its retained unit for additional authorized consumers or branches without reacquiring that unit from the origin. This is not a public object-custody service. E2E retention for its original recipient alone remains the separate F11/F18 capability and does not independently establish F31.", "method": "Architectural scope reconciliation; no runtime test", "source_label": "Author clarification: E2E/multicast channel custody; pinned custody amendments; earlier authorized-reuse witness", "sources": [], "editorial_references": [ "round467.html", "round467-scope.json", "round466-sources.json", "round465-sources.json" ], "qualification": "Author clarification in round467 narrows the earlier wording: there is no public CDN-style object custody. Retained units are not made available to arbitrary requesters, and knowing or announcing an ALIAS grants no access to them. Custody does not confer reading keys, authority to admit listeners or permission to move payload into an unrelated channel. F31 does not require public access; its Yes is limited to the previously confirmed authorized multicast reuse, not every custody operation or all E2E channels. The pinned amendments in round466 specify custody policy, acceptance and delivery scope; exact later-request matching, negotiation procedures, release conditions and formats remain unqualified. No implementation or interoperability claim is added." }, { "id": "F31-IP", "feature": "F31", "stack": "IP", "status": "N", "reason": "IP router queues and fragmentation/reassembly support packet delivery, not a reusable content cache serving later requests from other clients.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "No HTTP proxy, CDN or information-centric extension is selected." }, { "id": "F31-BP", "feature": "F31", "stack": "BP", "status": "N", "reason": "The selected BP forwarding store retains a bundle for delivery to its designated endpoint and removes retention constraints as processing completes. It supplies no content-cache request/response service for another requester.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.7", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.11", "https://www.rfc-editor.org/rfc/rfc9172.html" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "Forwarding copies, fragmentation buffers and retry storage remain supported. They do not by themselves match a later content request and serve it from a reusable object. The BP profile allows collective endpoint names, but selects no content-to-supplier binding. The selected pairwise security policies do not grant arbitrary new consumers access; confidentiality alone is not the reason for No. A separately selected cache-serving application or authorized multicast-reuse convention would require a fresh assessment." }, { "id": "F31-CG", "feature": "F31", "stack": "CG", "status": "N", "reason": "The selected BP forwarding store retains a bundle for delivery to its designated endpoint and removes retention constraints as processing completes. It supplies no content-cache request/response service for another requester.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.7", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.11", "https://www.rfc-editor.org/rfc/rfc9172.html" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "Forwarding copies, fragmentation buffers and retry storage remain supported. They do not by themselves match a later content request and serve it from a reusable object. This profile explicitly selects singleton destinations and no shared-reference directory. The selected pairwise security policies do not grant arbitrary new consumers access; confidentiality alone is not the reason for No. A separately selected cache-serving application or authorized multicast-reuse convention would require a fresh assessment." }, { "id": "F31-LT", "feature": "F31", "stack": "LT", "status": "N", "reason": "The selected BP forwarding store retains a bundle for delivery to its designated endpoint and removes retention constraints as processing completes. It supplies no content-cache request/response service for another requester.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.7", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.11", "https://www.rfc-editor.org/rfc/rfc9172.html" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "Forwarding copies, fragmentation buffers and retry storage remain supported. They do not by themselves match a later content request and serve it from a reusable object. This profile explicitly selects singleton destinations and no shared-reference directory. The selected pairwise security policies do not grant arbitrary new consumers access; confidentiality alone is not the reason for No. A separately selected cache-serving application or authorized multicast-reuse convention would require a fresh assessment." }, { "id": "F31-LP", "feature": "F31", "stack": "LP", "status": "N", "reason": "Direct-peer libp2p over QUIC supplies no selected content store that serves a retained object to a later different requester. Known numeric peers and Peer IDs; no content-routing, object-transfer or pubsub module is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Transport retransmission buffers, forwarding queues, route caches and duplicate suppression are not cross-requester object reuse. Neither a public nor an authorized private content-cache/custody service is selected." }, { "id": "F31-TO", "feature": "F31", "stack": "TO", "status": "N", "reason": "Tor onion-service transport supplies no selected retained-content service that answers a later request from a different consumer. Onion-service identity, rendezvous descriptors and circuit protection are control/transport functions; no content application is selected.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Directory/route caches, circuit queues, link retransmissions and forwarding replication do not establish cross-requester payload reuse. Private authorized reuse would qualify, but no such content-custody/cache service is selected." }, { "id": "F31-I2", "feature": "F31", "stack": "I2", "status": "N", "reason": "I2P destination/tunnel transport supplies no selected retained-content service that answers a later request from a different consumer. Known destination keys and NTCP2/tunnels are selected; file sharing, mailboxes and content applications are not.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Directory/route caches, circuit queues, link retransmissions and forwarding replication do not establish cross-requester payload reuse. Private authorized reuse would qualify, but no such content-custody/cache service is selected." }, { "id": "F31-YG", "feature": "F31", "stack": "YG", "status": "N", "reason": "Yggdrasil IPv6 overlay supplies no selected retained-content service that answers a later request from a different consumer. The selected service carries application UDP between cryptographic node addresses, without a content-service extension.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Directory/route caches, circuit queues, link retransmissions and forwarding replication do not establish cross-requester payload reuse. Private authorized reuse would qualify, but no such content-custody/cache service is selected." }, { "id": "F31-CJ", "feature": "F31", "stack": "CJ", "status": "N", "reason": "cjdns IPv6 overlay supplies no selected retained-content service that answers a later request from a different consumer. The selected ordinary application path carries UDP between node addresses; route-server discovery and route labels are not content naming.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Directory/route caches, circuit queues, link retransmissions and forwarding replication do not establish cross-requester payload reuse. Private authorized reuse would qualify, but no such content-custody/cache service is selected." }, { "id": "F31-MQ", "feature": "F31", "stack": "MQ", "status": "N", "reason": "Multipath QUIC supplies no selected content store that serves a retained object to a later different requester. Selected multipath-21 manages paths for QUIC connections; it adds no content-object service.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Transport retransmission buffers, forwarding queues, route caches and duplicate suppression are not cross-requester object reuse. Neither a public nor an authorized private content-cache/custody service is selected." }, { "id": "F31-SC", "feature": "F31", "stack": "SC", "status": "N", "reason": "SCION forwarding state and queues do not provide reusable content-object storage that satisfies later requests from other consumers.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Replication, duplicate suppression, learned addressing and transient buffers alone do not qualify. No additional content cache or custody-serving protocol is selected." }, { "id": "F31-RT", "feature": "F31", "stack": "RT", "status": "N", "reason": "The selected Resource mechanism retains parts for its chosen link transfer and recovery. Its explicit cache request retrieves a receipt proof for that transfer; it does not expose the retained content as a reusable object to another requester.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Resource.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "The receipt cache is acknowledged rather than treated as absent. Resource payload encryption and requests are link-bound; a node running a new content-serving application could redistribute data, but that is not selected. No LXMF propagation service is imported. This judgment is not a claim that all Reticulum caching is impossible." }, { "id": "F31-NS", "feature": "F31", "stack": "NS", "status": "Y", "reason": "The selected regular-event relays store events and answer matching subscriptions from multiple readers, reusing the stored event without asking the author to republish it for each reader.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "The selected in-memory relay stores qualify during their lifetime; restart persistence is not required by F31. Relay policy and event retention apply. Ephemeral events are not this witness." }, { "id": "F31-MT", "feature": "F31", "stack": "MT", "status": "N", "reason": "The selected Meshtastic CLIENT composition explicitly disables Store & Forward. Ordinary mesh forwarding and transient packet retention do not provide another remote requester with a cache-serving interface for reusable content. The optional Store & Forward module has a history request/response service, but it is not active in this composition.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Pinned cjdns source, BP forwarding and Meshtastic store-forward", "sources": [ "https://meshtastic.org/docs/configuration/module/store-and-forward-module/", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/StoreForwardModule.cpp" ], "editorial_references": [ "round509.html", "round509-sources.json" ], "qualification": "The optional module can return retained text history within a requested time window and configured limits; its existence is documented rather than attributed to the disabled profile. A local phone/client history cache and forwarding or duplicate-suppression buffers are not, by themselves, a cross-requester mesh service. Selecting the module would require reassessing its roles, authorization, retention and serving rules; no universal claim against Meshtastic content reuse is made." }, { "id": "F31-GN", "feature": "F31", "stack": "GN", "status": "N", "reason": "GNUnet CADET supplies no selected retained-content service that answers a later request from a different consumer. The selected CADET channels and R5N peer discovery exclude the separate GNUnet file-sharing, GNS and Messenger subsystems.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Directory/route caches, circuit queues, link retransmissions and forwarding replication do not establish cross-requester payload reuse. Private authorized reuse would qualify, but no such content-custody/cache service is selected." }, { "id": "F31-ND", "feature": "F31", "stack": "ND", "status": "Y", "reason": "The selected NFD Content Store can admit Data and satisfy a subsequent matching Interest from another consumer using that retained object, avoiding another producer transfer.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NDN-packet-spec/current/data.html", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/table/cs.cpp" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Positive cache capacity with admission and serving enabled; matching, freshness and eviction rules apply. The pinned NFD 24.07 CS source is mechanism evidence, not a new runtime or cache-hit benchmark. No public-access or restart-durability requirement." }, { "id": "F31-AX", "feature": "F31", "stack": "AX", "status": "N", "reason": "AX.25/NET/ROM supplies no selected retained-content service that answers a later request from a different consumer. The selected radio/serial network and transport circuits use callsign/SSID addressing; no BBS, mailbox or added cryptographic application is selected.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://linux-ax25.in-berlin.de/wiki/NET/ROM", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Directory/route caches, circuit queues, link retransmissions and forwarding replication do not establish cross-requester payload reuse. Private authorized reuse would qualify, but no such content-custody/cache service is selected." }, { "id": "F31-BA", "feature": "F31", "stack": "BA", "status": "N", "reason": "batman-adv forwarding state and queues do not provide reusable content-object storage that satisfies later requests from other consumers.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/Documentation/networking/batman-adv.rst" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Replication, duplicate suppression, learned addressing and transient buffers alone do not qualify. No additional content cache or custody-serving protocol is selected." }, { "id": "F31-BL", "feature": "F31", "stack": "BL", "status": "N", "reason": "IPv6/Babel supplies no selected content store that serves a retained object to a later different requester. Babel maintains prefix reachability for IPv6 datagrams; no application content protocol or cryptographic payload layer is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Transport retransmission buffers, forwarding queues, route caches and duplicate suppression are not cross-requester object reuse. Neither a public nor an authorized private content-cache/custody service is selected." }, { "id": "F31-RI", "feature": "F31", "stack": "RI", "status": "N", "reason": "6LoWPAN/IPv6/RPL/UDP/DTLS supplies no selected content store that serves a retained object to a later different requester. Selected endpoint leaves use non-storing RPL and pairwise DTLS PSKs; no CoAP, MQTT, object-security or content-service layer is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Transport retransmission buffers, forwarding queues, route caches and duplicate suppression are not cross-requester object reuse. Neither a public nor an authorized private content-cache/custody service is selected." }, { "id": "F31-HP", "feature": "F31", "stack": "HP", "status": "N", "reason": "HIPv2/ESP with application UDP supplies no selected content store that serves a retained object to a later different requester. HIP identifies hosts and ESP protects host-to-host packets; no content-service or application-authentication wrapper is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Transport retransmission buffers, forwarding queues, route caches and duplicate suppression are not cross-requester object reuse. Neither a public nor an authorized private content-cache/custody service is selected." }, { "id": "F31-CX", "feature": "F31", "stack": "CX", "status": "Y", "reason": "CCNx Content Stores can reuse a stored object to answer a later matching Interest from another consumer. Matching restrictions and cache validity determine whether the copy can be served.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "A configured Content Store is required. Bounded retention and eviction remain possible; this does not guarantee that every intermediate node caches or fully validates all objects." }, { "id": "F31-LI", "feature": "F31", "stack": "LI", "status": "N", "reason": "LISP forwarding state and queues do not provide reusable content-object storage that satisfies later requests from other consumers.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Replication, duplicate suppression, learned addressing and transient buffers alone do not qualify. No additional content cache or custody-serving protocol is selected." }, { "id": "F31-IL", "feature": "F31", "stack": "IL", "status": "N", "reason": "ILNPv6/TCP supplies no selected content store that serves a retained object to a later different requester. Identifier/Locator separation and DNS NID/L64 records address participants and their locations; no content-reference, IPsec or application-security layer is selected.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Transport retransmission buffers, forwarding queues, route caches and duplicate suppression are not cross-requester object reuse. Neither a public nor an authorized private content-cache/custody service is selected." }, { "id": "F31-TS", "feature": "F31", "stack": "TS", "status": "N", "reason": "The selected forwarding service relays encrypted packets to their destination, without content-object lookup and reuse to satisfy another requester.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "Packet queues are not reusable content caches. No additional caching application is selected." }, { "id": "F31-RA", "feature": "F31", "stack": "RA", "status": "N", "reason": "The selected normal-DIF service transports SDUs on allocated application flows. It supplies no selected reusable-object lookup and serving path for a later independent requester. Flow and retransmission buffering do not constitute a shared content cache.", "method": "Selected-service boundary assessment using primary API documentation; no execution", "source_label": "IRATI application API: registration, flow allocation and SDU exchange", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Application-API.md", "https://github.com/IRATI/stack/wiki/Application-API" ], "editorial_references": [ "round653.html" ], "qualification": "A content-cache application could be built above the service, but is not included in this column. No general impossibility of caching over RINA is claimed." }, { "id": "F32-PN", "feature": "F32", "stack": "PN", "status": "Y", "reason": "The protocol author confirms that clients calculate their trajectories using negotiated availability and transport capacity. Each client negotiates capacity, QoS and bandwidth reservation with the aggregators along its half of the path up to the rendezvous; the opposite client does the same for the other half. Known future availability and usable capacity therefore feed local trajectory selection, including whether the intended transfer fits the selected opportunities. Planning need not be performed by a central service or by one participant with the entire end-to-end contact plan. This author-confirmed architectural composition supplies the capability omitted by the earlier review, which assessed availability windows and resource observations separately.", "method": "Direct protocol-author clarification and architectural composition assessment; no runtime test", "source_label": "Protocol author, conversation of 2026-10-23; exact statement preserved in round581-sources.json", "sources": [], "editorial_references": [ "round581.html#F32-PN", "round581.html", "round581-sources.json" ], "qualification": "Architectural Yes based explicitly on the author clarification, not an independently demonstrated wire or executable planner. Each side is responsible for negotiating its own half; knowledge or authority over the other half is not assumed. A local feasible plan is not by itself a global delivery guarantee: rendezvous coordination, custody where required, current agreements and compatible delivery timing still matter. This does not assign a global clock, atomic reservation protocol, numeric opcode or stale-plan recovery procedure. Concrete capacity accounting, validity and change handling remain implementation/profile obligations. F32 does not require guaranteed bandwidth or a particular SABR algorithm. The clarification establishes a composed planning capability; it does not turn a resource report or the retention mechanism alone into a reservation service." }, { "id": "F32-PI", "feature": "F32", "stack": "PI", "status": "Y", "reason": "The protocol author confirms that clients calculate their trajectories using negotiated availability and transport capacity. Each client negotiates capacity, QoS and bandwidth reservation with the aggregators along its half of the path up to the rendezvous; the opposite client does the same for the other half. Known future availability and usable capacity therefore feed local trajectory selection, including whether the intended transfer fits the selected opportunities. Planning need not be performed by a central service or by one participant with the entire end-to-end contact plan. This author-confirmed architectural composition supplies the capability omitted by the earlier review, which assessed availability windows and resource observations separately.", "method": "Direct protocol-author clarification and architectural composition assessment; no runtime test", "source_label": "Protocol author, conversation of 2026-10-23; exact statement preserved in round581-sources.json", "sources": [], "editorial_references": [ "round581.html#F32-PI", "round581.html", "round581-sources.json" ], "qualification": "Architectural Yes based explicitly on the author clarification, not an independently demonstrated wire or executable planner. Each side is responsible for negotiating its own half; knowledge or authority over the other half is not assumed. A local feasible plan is not by itself a global delivery guarantee: rendezvous coordination, custody where required, current agreements and compatible delivery timing still matter. This does not assign a global clock, atomic reservation protocol, numeric opcode or stale-plan recovery procedure. Concrete capacity accounting, validity and change handling remain implementation/profile obligations. F32 does not require guaranteed bandwidth or a particular SABR algorithm. The clarification establishes a composed planning capability; it does not turn a resource report or the retention mechanism alone into a reservation service. IPv4/UDP supplies the carrier; this planning benefit belongs to PRP agreements and trajectory selection, not BGP or an inferred underlay bandwidth guarantee." }, { "id": "F32-IP", "feature": "F32", "stack": "IP", "status": "N", "reason": "The selected IP/BGP composition routes using reachability and route policy; it does not compute temporally feasible routes from future contact windows and transferable contact capacity.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "No contact-plan routing or DTN extension is selected. Manual route changes or future maintenance schedules are not a route-planning mechanism in this composition." }, { "id": "F32-BP", "feature": "F32", "stack": "BP", "status": "N", "reason": "BPv7 section 5.4 delegates selection of forwarding nodes and convergence-layer adapters to routing information and policy. The selected Secure DTN composition supplies static/aggregate forwarding exits and TCPCL, but no future-contact plan with capacity-aware route computation. Retaining a bundle until forwarding becomes possible does not satisfy F32.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Pinned cjdns source, BP forwarding and Meshtastic store-forward", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round509.html", "round509-sources.json" ], "qualification": "BP can host schedule-aware routing, including CGR/SABR, which is separately selected in other columns. The use of ION as a witness for specific BPSec mechanisms does not select every ION routing facility. This No concerns the listed composition rather than a limitation imposed on all BP deployments. Existing store-and-forward and interruption support remain credited independently." }, { "id": "F32-CG", "feature": "F32", "stack": "CG", "status": "Y", "reason": "The selected SABR/CGR routing layer uses future contact times, rates, propagation ranges and backlog/volume accounting when computing and filtering candidate routes. It evaluates temporal and capacity feasibility rather than merely waiting for a link.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "CCSDS 734.3-B-1 sections 2.3–2.4 and 3.2.4–3.2.6. Supplied contact plans and clocks are required; route lists are recomputed on plan change. The existing BPv7/SABR metadata and complete-composition implementation qualifications remain open. LT inherits this from its explicitly selected SABR layer, not LTP alone." }, { "id": "F32-LT", "feature": "F32", "stack": "LT", "status": "Y", "reason": "The selected SABR/CGR routing layer uses future contact times, rates, propagation ranges and backlog/volume accounting when computing and filtering candidate routes. It evaluates temporal and capacity feasibility rather than merely waiting for a link.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "CCSDS 734.3-B-1 sections 2.3–2.4 and 3.2.4–3.2.6. Supplied contact plans and clocks are required; route lists are recomputed on plan change. The existing BPv7/SABR metadata and complete-composition implementation qualifications remain open. LT inherits this from its explicitly selected SABR layer, not LTP alone." }, { "id": "F32-LP", "feature": "F32", "stack": "LP", "status": "N", "reason": "Direct-peer libp2p over QUIC does not select routes using future contact intervals and their usable transfer volumes in the declared composition.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Known numeric peers and Peer IDs; no content-routing, object-transfer or pubsub module is selected. Path preferences, neighbor timers, rank/metric updates, transport flow control and local radio schedules do not by themselves compute temporal route-capacity feasibility. No contact-plan routing extension is selected." }, { "id": "F32-TO", "feature": "F32", "stack": "TO", "status": "N", "reason": "Tor onion-service transport does not compute temporally and capacity-feasible routes from future contact intervals in the selected composition.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Onion-service identity, rendezvous descriptors and circuit protection are control/transport functions; no content application is selected. Current topology, peer selection, tunnel lifetime, routing metrics and queue limits are distinct from contact-plan route computation." }, { "id": "F32-I2", "feature": "F32", "stack": "I2", "status": "N", "reason": "I2P destination/tunnel transport does not compute temporally and capacity-feasible routes from future contact intervals in the selected composition.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "Known destination keys and NTCP2/tunnels are selected; file sharing, mailboxes and content applications are not. Current topology, peer selection, tunnel lifetime, routing metrics and queue limits are distinct from contact-plan route computation." }, { "id": "F32-YG", "feature": "F32", "stack": "YG", "status": "N", "reason": "Yggdrasil IPv6 overlay does not compute temporally and capacity-feasible routes from future contact intervals in the selected composition.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "The selected service carries application UDP between cryptographic node addresses, without a content-service extension. Current topology, peer selection, tunnel lifetime, routing metrics and queue limits are distinct from contact-plan route computation." }, { "id": "F32-CJ", "feature": "F32", "stack": "CJ", "status": "N", "reason": "cjdns IPv6 overlay does not compute temporally and capacity-feasible routes from future contact intervals in the selected composition.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "The selected ordinary application path carries UDP between node addresses; route-server discovery and route labels are not content naming. Current topology, peer selection, tunnel lifetime, routing metrics and queue limits are distinct from contact-plan route computation." }, { "id": "F32-MQ", "feature": "F32", "stack": "MQ", "status": "N", "reason": "Multipath QUIC does not select routes using future contact intervals and their usable transfer volumes in the declared composition.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Selected multipath-21 manages paths for QUIC connections; it adds no content-object service. Path preferences, neighbor timers, rank/metric updates, transport flow control and local radio schedules do not by themselves compute temporal route-capacity feasibility. No contact-plan routing extension is selected." }, { "id": "F32-SC", "feature": "F32", "stack": "SC", "status": "N", "reason": "SCION discovers and combines advertised path segments and exposes path choice to endpoints. The selected profile does not compute routes from future link-availability intervals and transferable contact capacities.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [ "round472.html", "round472-sources.json" ], "qualification": "Path validity/expiration, segment freshness and static path metrics are distinct from a future contact plan. F28 explicit path selection remains Yes; no scheduled-contact routing extension is selected." }, { "id": "F32-RT", "feature": "F32", "stack": "RT", "status": "N", "reason": "Reticulum routes or relays using learned destinations/current mesh information rather than a time-indexed plan of future contact opportunities and their transferable capacity.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://reticulum.network/manual/understanding.html" ], "editorial_references": [ "round472.html", "round472-sources.json" ], "qualification": "The selected profile adds no contact-plan routing extension. Announce/path lifetimes, link metrics, hop limits, retry delays and radio duty limits are not computation of temporal and capacity feasibility along future contacts." }, { "id": "F32-NS", "feature": "F32", "stack": "NS", "status": "N", "reason": "Nostr in this composition does not compute routes from future contact intervals and usable contact volumes.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Current reachability, request lifetimes, event timestamps and local scheduling are not temporal route-capacity planning. No SABR-like extension is selected." }, { "id": "F32-MT", "feature": "F32", "stack": "MT", "status": "N", "reason": "Meshtastic routes or relays using learned destinations/current mesh information rather than a time-indexed plan of future contact opportunities and their transferable capacity.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [ "round472.html", "round472-sources.json" ], "qualification": "The selected profile adds no contact-plan routing extension. Announce/path lifetimes, link metrics, hop limits, retry delays and radio duty limits are not computation of temporal and capacity feasibility along future contacts." }, { "id": "F32-GN", "feature": "F32", "stack": "GN", "status": "N", "reason": "GNUnet CADET does not compute temporally and capacity-feasible routes from future contact intervals in the selected composition.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "The selected CADET channels and R5N peer discovery exclude the separate GNUnet file-sharing, GNS and Messenger subsystems. Current topology, peer selection, tunnel lifetime, routing metrics and queue limits are distinct from contact-plan route computation." }, { "id": "F32-ND", "feature": "F32", "stack": "ND", "status": "N", "reason": "NDN with static FIB in this composition does not compute routes from future contact intervals and usable contact volumes.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NDN-packet-spec/current/data.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Current reachability, request lifetimes, event timestamps and local scheduling are not temporal route-capacity planning. No SABR-like extension is selected." }, { "id": "F32-AX", "feature": "F32", "stack": "AX", "status": "N", "reason": "AX.25/NET/ROM does not compute temporally and capacity-feasible routes from future contact intervals in the selected composition.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://linux-ax25.in-berlin.de/wiki/NET/ROM", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "The selected radio/serial network and transport circuits use callsign/SSID addressing; no BBS, mailbox or added cryptographic application is selected. Current topology, peer selection, tunnel lifetime, routing metrics and queue limits are distinct from contact-plan route computation." }, { "id": "F32-BA", "feature": "F32", "stack": "BA", "status": "N", "reason": "batman-adv in this composition does not compute routes from future contact intervals and usable contact volumes.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/Documentation/networking/batman-adv.rst" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Current reachability, request lifetimes, event timestamps and local scheduling are not temporal route-capacity planning. No SABR-like extension is selected." }, { "id": "F32-BL", "feature": "F32", "stack": "BL", "status": "N", "reason": "IPv6/Babel does not select routes using future contact intervals and their usable transfer volumes in the declared composition.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Babel maintains prefix reachability for IPv6 datagrams; no application content protocol or cryptographic payload layer is selected. Path preferences, neighbor timers, rank/metric updates, transport flow control and local radio schedules do not by themselves compute temporal route-capacity feasibility. No contact-plan routing extension is selected." }, { "id": "F32-RI", "feature": "F32", "stack": "RI", "status": "N", "reason": "6LoWPAN/IPv6/RPL/UDP/DTLS does not select routes using future contact intervals and their usable transfer volumes in the declared composition.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Selected endpoint leaves use non-storing RPL and pairwise DTLS PSKs; no CoAP, MQTT, object-security or content-service layer is selected. Path preferences, neighbor timers, rank/metric updates, transport flow control and local radio schedules do not by themselves compute temporal route-capacity feasibility. No contact-plan routing extension is selected." }, { "id": "F32-HP", "feature": "F32", "stack": "HP", "status": "N", "reason": "HIPv2/ESP with application UDP does not select routes using future contact intervals and their usable transfer volumes in the declared composition.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "HIP identifies hosts and ESP protects host-to-host packets; no content-service or application-authentication wrapper is selected. Path preferences, neighbor timers, rank/metric updates, transport flow control and local radio schedules do not by themselves compute temporal route-capacity feasibility. No contact-plan routing extension is selected." }, { "id": "F32-CX", "feature": "F32", "stack": "CX", "status": "N", "reason": "CCNx with static FIB in this composition does not compute routes from future contact intervals and usable contact volumes.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Current reachability, request lifetimes, event timestamps and local scheduling are not temporal route-capacity planning. No SABR-like extension is selected." }, { "id": "F32-LI", "feature": "F32", "stack": "LI", "status": "N", "reason": "LISP in this composition does not compute routes from future contact intervals and usable contact volumes.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Current reachability, request lifetimes, event timestamps and local scheduling are not temporal route-capacity planning. No SABR-like extension is selected." }, { "id": "F32-IL", "feature": "F32", "stack": "IL", "status": "N", "reason": "ILNPv6/TCP does not select routes using future contact intervals and their usable transfer volumes in the declared composition.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Identifier/Locator separation and DNS NID/L64 records address participants and their locations; no content-reference, IPsec or application-security layer is selected. Path preferences, neighbor timers, rank/metric updates, transport flow control and local radio schedules do not by themselves compute temporal route-capacity feasibility. No contact-plan routing extension is selected." }, { "id": "F32-TS", "feature": "F32", "stack": "TS", "status": "N", "reason": "Tailscale selects direct or relayed connectivity using current reachability and rechecks those paths. This is not route planning from future contact opportunities and usable transfer capacity.", "method": "Pinned dependency/source inspection and official documentation; no runtime test", "source_label": "Tailscale go.mod and selected wireguard-go dependency", "sources": [ "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/constants.go" ], "editorial_references": [ "round587.html", "round587-sources.json" ], "qualification": "Inference from the selected connection procedure. Current-path failover and latency selection do not constitute a contact plan." }, { "id": "F32-RA", "feature": "F32", "stack": "RA", "status": "N", "reason": "The selected link-state/Dijkstra policy computes forwarding from the known connectivity graph. Its routing inputs do not represent future contact intervals and usable transfer volumes, and its computation does not account for item feasibility over such intervals. QoS flow allocation and programmed access handovers do not add contact-plan route computation.", "method": "Pinned forwarding, queue-lifecycle and routing-source inspection with selected-policy documentation", "source_label": "IRATI RMT, DTP and link-state routing source; normal-DIF configuration", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/routing-ps.cc", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/default.dif", "https://raw.githubusercontent.com/wiki/IRATI/stack/Flow-Allocation.md", "https://arxiv.org/abs/2510.27325" ], "editorial_references": [ "round659.html" ], "qualification": "No for the selected routing policy. Alternative time-dependent routing could be implemented as another policy, but is not part of this column. This does not deny QoS-aware flow allocation or current-topology route repair. No execution or capacity benchmark." }, { "id": "F33-PN", "feature": "F33", "stack": "PN", "status": "Y", "reason": "Relationship Retention sections 5, 7–10 define a recovery mechanism adapted to delayed contacts: immutable retained-item identity, cumulative/selective E2E feedback repeatable on an authorized reverse path, no required periodic feedback without contact, pending work across path loss, safe reprotection and duplicate suppression. This is a specified recovery alternative to treating every long interruption as ordinary timeout failure.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [], "editorial_references": [ "round464.html#prp-sources", "round464.html", "round464-sources.json" ], "qualification": "Architectural Yes for ORDERED|RELIABLE items under negotiated retention bounds and preserved cryptographic viability. RET-001 policy activation remains unavailable; no measured delay range, operational scheduler or unlimited outage tolerance is claimed. Expiry and terminal failures still apply. This verdict relies on the explicit recovery semantics, not retention alone." }, { "id": "F33-PI", "feature": "F33", "stack": "PI", "status": "Y", "reason": "Relationship Retention sections 5, 7–10 define a recovery mechanism adapted to delayed contacts: immutable retained-item identity, cumulative/selective E2E feedback repeatable on an authorized reverse path, no required periodic feedback without contact, pending work across path loss, safe reprotection and duplicate suppression. This is a specified recovery alternative to treating every long interruption as ordinary timeout failure.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [], "editorial_references": [ "round464.html#prp-sources", "round464.html", "round464-sources.json" ], "qualification": "Architectural Yes for ORDERED|RELIABLE items under negotiated retention bounds and preserved cryptographic viability. RET-001 policy activation remains unavailable; no measured delay range, operational scheduler or unlimited outage tolerance is claimed. Expiry and terminal failures still apply. This verdict relies on the explicit recovery semantics, not retention alone." }, { "id": "F33-IP", "feature": "F33", "stack": "IP", "status": "N", "reason": "Bare IP provides datagram delivery without retransmission-based reliable transfer. It therefore supplies no reliable-transfer recovery adapted to prolonged interruptions.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "No TCP, LTP or other reliable transport is selected. ICMP errors and fragment-reassembly timers do not qualify." }, { "id": "F33-BP", "feature": "F33", "stack": "BP", "status": "N", "reason": "TCPCLv4 acknowledgements can support reactive bundle fragmentation after a session interruption, reducing repeated bytes. However, its reliable transfer remains TCP-based and a broken transfer is reported to the BPA for policy-driven recovery. The selected composition specifies no recovery adaptation covering both prolonged propagation delay and unavailable contact intervals, as required by F33.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BPv7, TCPCLv4 and SABR; comparison with LTP", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc9174.html#section-6.1", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round512.html", "round512-sources.json" ], "qualification": "This No does not negate meaningful interruption recovery: RFC 9174 sections 3.2 and 6.1 explicitly support acknowledgements before closure and explain avoiding redundant retransmission. BP section 5.4 permits another forwarding attempt, subject to policy, lifetime and storage; fragmentation is also subject to bundle/security constraints. These mechanisms do not suspend TCP recovery across contact loss or establish an equivalent long-delay/contact-aware transfer contract. Enlarging timeouts alone does not qualify. No claim that BP cannot cross a long outage, or that LTP is the only possible qualifying mechanism, is made." }, { "id": "F33-CG", "feature": "F33", "stack": "CG", "status": "N", "reason": "Adding SABR contact/range plans to BP/TCPCL enables schedule-aware route selection but does not replace the selected TCPCL reliable-transfer behavior. Planned forwarding and possible reactive fragmentation do not establish transfer recovery adapted to both prolonged propagation delay and interruptions. The selected composition has no LTP or equivalent contact-aware recovery layer.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BPv7, TCPCLv4 and SABR; comparison with LTP", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9174.html#section-5.1.1", "https://www.rfc-editor.org/rfc/rfc5326.html#section-6.5" ], "editorial_references": [ "round512.html", "round512-sources.json" ], "qualification": "SABR retains its positive F32 route-planning and F24 scheduled-reception assessments. F33 evaluates a different mechanism: acknowledgements, retries and recovery while transfer opportunities disappear. TCPCL can close and report failure, and BP may retry later; credit for those behaviors does not imply suspended recovery timers or a long-delay transfer contract. The LTP column explicitly selects the RFC 5326 mechanism and remains Yes. This is a documentary composition finding, not an interoperability test or a claim of failed DTN delivery." }, { "id": "F33-LT", "feature": "F33", "stack": "LT", "status": "Y", "reason": "LTP checkpoint/report recovery accounts for long propagation delay and explicitly suspends and resumes acknowledgment countdown timers on link-state cues. This supports the selected reliable red-part transfer across scheduled transmission interruptions.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "RFC 5326 sections 6.5–6.7. Accurate cues, retained session state, latency estimates and retry/resource limits matter. No unlimited outage or complete BP/AOS integration result is claimed." }, { "id": "F33-LP", "feature": "F33", "stack": "LP", "status": "N", "reason": "The selected libp2p QUIC transport uses ordinary QUIC reliable streams. RFC 9002 sections 5 and 6.2 define RTT estimation and exponentially backed-off probe timers. They do not define recovery suspension tied to the loss of a transfer opportunity. The libp2p QUIC specification adds peer authentication and addressing, not a contact-aware recovery protocol.", "method": "Primary specification analysis; no new runtime test", "source_label": "Primary specifications; selected-composition documentary assessment", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9002.html#section-6.2", "https://www.rfc-editor.org/rfc/rfc9000.html#section-10.1" ], "editorial_references": [ "round477.html", "round477-sources.json" ], "qualification": "No under F33 as defined, not a claim that QUIC cannot operate over a high-RTT link or survive any outage. RFC 9000 section 10.1 permits idle-timeout configuration; increasing or disabling that timeout is not itself the required interruption adaptation. No application-level durable-transfer extension is selected." }, { "id": "F33-TO", "feature": "F33", "stack": "TO", "status": "N", "reason": "Tor tears down a circuit on an unrecoverable error, including loss of its carrying OR connection. DESTROY releases circuit resources and closes associated edge connections. The selected stack does not preserve that transfer through a contact-loss suspension and resume it on the restored circuit.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "GNUnet 0.20.0 service/transport code and Tor circuit specification", "sources": [ "https://spec.torproject.org/tor-spec/tearing-down-circuits.html" ], "editorial_references": [ "round486.html", "round486-sources.json", "round486-plan.json" ], "qualification": "TCP retransmission can bridge ordinary outages while a connection survives. Building a replacement circuit or retrying an application transaction is not transparent recovery of the interrupted transfer. This verdict does not claim every brief outage destroys a circuit, and no application-level resumable-transfer protocol is selected." }, { "id": "F33-I2", "feature": "F33", "stack": "I2", "status": "N", "reason": "The selected I2P composition specifies NTCP2 links and destination tunnels, not a contact-aware reliable-transfer layer. NTCP2 uses TCP for an adjacent connection; tunnel rebuilding restores paths but does not preserve a checkpointed transfer across prolonged loss of communication opportunities. No contact schedule, timer suspension or equivalent recovery contract is selected.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "I2P transport layering and GNUnet CADET recovery", "sources": [ "https://i2p.net/en/docs/api/streaming/", "https://i2p.net/en/docs/specs/tunnel-implementation/" ], "editorial_references": [ "round511.html", "round511-sources.json" ], "qualification": "I2P also documents an application-layer Streaming library with acknowledgements, retransmission and RTT/congestion behavior. That optional layer is not silently added to the column, and ordinary streaming retries alone would not establish F33. The finding does not deny I2P reliability under normal operating conditions or prohibit application-level deferred delivery. No outage-duration measurement or universal timeout bound is claimed." }, { "id": "F33-YG", "feature": "F33", "stack": "YG", "status": "N", "reason": "Yggdrasil is assessed here with application UDP, as explicitly selected in its column. The composition supplies packet routing, not an end-to-end retransmission service with recovery adapted to prolonged contact loss.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://yggdrasil-network.github.io/about.html", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [ "round471.html", "round471-sources.json" ], "qualification": "UDP does not guarantee delivery. Route repair, path replacement and cryptographic state do not supply missing application retransmission. Yggdrasil TCP peer links do not change its final IPv6/UDP service into reliable end-to-end delivery; no interruption-aware recovery extension is selected. This is a composition verdict, not a limit on applications that could be added." }, { "id": "F33-CJ", "feature": "F33", "stack": "CJ", "status": "N", "reason": "cjdns is assessed here with application UDP, as explicitly selected in its column. The composition supplies packet routing, not an end-to-end retransmission service with recovery adapted to prolonged contact loss.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [ "round471.html", "round471-sources.json" ], "qualification": "UDP does not guarantee delivery. Route repair, path replacement and cryptographic state do not supply missing application retransmission. Yggdrasil TCP peer links do not change its final IPv6/UDP service into reliable end-to-end delivery; no interruption-aware recovery extension is selected. This is a composition verdict, not a limit on applications that could be added." }, { "id": "F33-MQ", "feature": "F33", "stack": "MQ", "status": "N", "reason": "Multipath-21 sections 5.4 and 5.6-5.9 support per-path delay estimates, retransmission on another available path and ordinary QUIC loss detection. Connection idle expiry still applies across all paths. This supplies alternate-path recovery, but no specified suspension/resumption of reliable-transfer recovery across a prolonged absence of all transfer opportunities.", "method": "Primary specification analysis; no new runtime test", "source_label": "Primary specifications; selected-composition documentary assessment", "sources": [ "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-5.7", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-5.9", "https://www.rfc-editor.org/rfc/rfc9002.html#section-6.2" ], "editorial_references": [ "round477.html", "round477-sources.json" ], "qualification": "The satellite/terrestrial RTT example and alternate-path retransmissions are explicitly acknowledged. They do not meet the interruption part of F33 merely by accommodating different delays. This No is limited to the selected historical multipath-21 composition; it does not deny multipath continuity while another path remains available, nor assess later extensions. No runtime failure is claimed." }, { "id": "F33-SC", "feature": "F33", "stack": "SC", "status": "N", "reason": "SCION is assessed here with application UDP, as explicitly selected in its column. The composition supplies packet routing, not an end-to-end retransmission service with recovery adapted to prolonged contact loss.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [ "round471.html", "round471-sources.json" ], "qualification": "UDP does not guarantee delivery. Route repair, path replacement and cryptographic state do not supply missing application retransmission. Yggdrasil TCP peer links do not change its final IPv6/UDP service into reliable end-to-end delivery; no interruption-aware recovery extension is selected. This is a composition verdict, not a limit on applications that could be added." }, { "id": "F33-RT", "feature": "F33", "stack": "RT", "status": "N", "reason": "Reticulum adapts Resource windows and retries to measured link behavior, but retry exhaustion cancels the transfer. Resource.ensure_link aborts when the link is not active, and the Link watchdog tears down stale links. No selected mechanism suspends recovery through a prolonged loss of contact and resumes the retained transfer after contact returns.", "method": "Primary specification and pinned-source assessment; no runtime experiment", "source_label": "Selected-composition documentary boundary; no added application service", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Resource.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Link.py" ], "editorial_references": [ "round484.html", "round484-sources.json", "round484-plan.json" ], "qualification": "Slow-link adaptation, bounded retransmission and cached receipt recovery remain real capabilities. They do not establish the interruption adaptation required by F33. No unlimited-delay requirement is introduced, and this is not a measured reliability failure. Application-level reconnect/restart procedures are not selected." }, { "id": "F33-NS", "feature": "F33", "stack": "NS", "status": "N", "reason": "Basic Nostr provides relay acceptance replies and retrieval of stored events, but NIP-01 specifies no contact-aware retransmission/resumption procedure for an interrupted transfer. WebSocket uses TCP; RFC 6455 section 7.2.3 describes reconnect backoff after abnormal closure, while TCP retains ordinary RTO-based recovery. These mechanisms do not supply the prolonged-contact-interruption adaptation required by F33.", "method": "Primary documentary assessment; no runtime test", "source_label": "Pinned primary specifications; selected-composition inference", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md", "https://www.rfc-editor.org/rfc/rfc6455.html#section-7.2.3", "https://www.rfc-editor.org/rfc/rfc6298.html#section-5" ], "editorial_references": [ "round479.html", "round479-sources.json" ], "qualification": "Relay storage, later REQ retrieval and application retry remain useful. An OK reply acknowledges relay acceptance, not eventual reader receipt; stored-event retrieval does not itself resume a partially delivered reliable transfer. No additional durable client outbox or recovery extension is selected. This No does not deny offline reading or recovery from ordinary disconnections." }, { "id": "F33-MT", "feature": "F33", "stack": "MT", "status": "N", "reason": "ReliableRouter adjusts retry deadlines for packet airtime, and NextHopRouter schedules attempts with a finite remaining-retransmission counter. At exhaustion it reports MAX_RETRANSMIT for locally originated traffic and removes the pending packet. The selected mechanism does not suspend recovery on loss of a prolonged contact opportunity and resume the retained transfer when contact returns.", "method": "Pinned firmware source and primary documentation; no runtime test", "source_label": "Selected Meshtastic ordinary CLIENT composition", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/ReliableRouter.cpp", "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [ "round482.html", "round482-sources.json" ], "qualification": "Airtime adjustments, channel-utilization-sensitive timeouts, initial duty-cycle rejection handling and final flooding fallback are real adaptations, but address local transmission conditions and bounded retries. They do not establish F33 contact-aware recovery. Store-and-forward is disabled in this composition. No unlimited outage tolerance or new RF experiment is claimed, and ordinary reliable messaging remains credited." }, { "id": "F33-GN", "feature": "F33", "stack": "GN", "status": "N", "reason": "GNUnet 0.20.0 CADET supplies reliable channels with acknowledgements, retained pending messages and retry/backoff logic. The reviewed channel and connection code manages live-path readiness, retransmission and liveness, but supplies no contact-plan or prolonged-interruption recovery contract that distinguishes unavailable transfer opportunities from ordinary loss.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "I2P transport layering and GNUnet CADET recovery", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round511.html", "round511-sources.json" ], "qualification": "Waiting for a path, backing off retries or retaining queued messages can bridge some disruptions; these useful behaviors do not by themselves establish the documented long-delay/contact adaptation required by F33. No separate DTN transfer service is selected. This is a bounded source/documentation assessment, not a claim that CADET always fails after a particular outage or that all queued data is immediately lost. Runtime recovery and maximum supported outage remain unmeasured." }, { "id": "F33-ND", "feature": "F33", "stack": "ND", "status": "N", "reason": "The selected NDN packet format and NFD profile provide Interest expiry, forwarding and cached Data. InterestLifetime is an application-supplied timeout; these mechanisms do not specify interruption-aware reliable object-transfer recovery in this composition.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NFD/24.07/" ], "editorial_references": [ "round471.html", "round471-sources.json" ], "qualification": "Increasing InterestLifetime, re-expressing an Interest or obtaining cached Data is not by itself the F33 adaptation. Link reliability and forwarding retry mechanisms do not establish prolonged-contact suspension/resumption. The profile explicitly excludes a DTN extension; no additional consumer transfer protocol is selected. Cache-assisted staged delivery remains separately credited in F18." }, { "id": "F33-AX", "feature": "F33", "stack": "AX", "status": "N", "reason": "Linux 6.12 NET/ROM restarts T1 after retransmission and disconnects with ETIMEDOUT when n2 retries are exhausted, including in the connected state. A routing failure in nr_transmit_buffer disconnects with ENETUNREACH. Neither path suspends and resumes the outstanding transfer around a known interruption.", "method": "Primary RFC and pinned implementation assessment; no runtime experiment", "source_label": "Selected-composition mechanisms and interface evidence", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_timer.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_out.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_in.c" ], "editorial_references": [ "round485.html", "round485-sources.json", "round485-plan.json" ], "qualification": "NET/ROM and AX.25 provide real acknowledgments and retransmission. T1/N2 tuning, CHOKE flow control and disabling an idle timeout do not establish contact-aware recovery. The verdict concerns the selected Linux NET/ROM circuit, not every radio application or later store-and-forward layer; no radio reliability measurement is claimed." }, { "id": "F33-BA", "feature": "F33", "stack": "BA", "status": "N", "reason": "The selected native L2 service forwards Ethernet payloads without an end-to-end reliable-transfer recovery contract. In v6.12, batadv_send_skb_to_orig frees a packet when no router is available; broadcast forwarding uses a bounded repetition counter. Neither path suspends acknowledged-transfer recovery until a later contact opportunity.", "method": "Pinned Linux v6.12 source and primary documentation; no runtime test", "source_label": "Selected BATMAN_IV/native Ethernet composition", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h", "https://docs.kernel.org/networking/batman-adv.html" ], "editorial_references": [ "round478.html", "round478-sources.json" ], "qualification": "Broadcast repetitions, topology repair, fragment handling and the diagnostic throughput meter do not provide reliable delayed payload delivery. No TCP, LTP, durable-transfer application or special carrier recovery is selected. This is a source-level capability judgment, not a measured outage experiment." }, { "id": "F33-BL", "feature": "F33", "stack": "BL", "status": "N", "reason": "Babel maintains routing reachability for IPv6 datagrams; its routing-update recovery is not a reliable user-data transfer protocol.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No TCP, LTP or other reliable user transport is selected. Repaired routes do not retransmit application data lost during an interruption." }, { "id": "F33-RI", "feature": "F33", "stack": "RI", "status": "N", "reason": "DTLS 1.3 preserves the underlying datagram delivery semantics for application data. Reliable handshake flights and link-layer retries do not supply reliable end-to-end item recovery across prolonged contact interruptions.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html", "https://www.rfc-editor.org/rfc/rfc6550.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "The selected UDP/DTLS profile has no additional reliable-transfer or retained-item recovery service. This does not negate planned sleep, fresh reconnection or bounded link retries." }, { "id": "F33-HP", "feature": "F33", "stack": "HP", "status": "N", "reason": "The selected application traffic is UDP carried by HIP-established ESP associations. Neither HIP control retransmissions nor ESP anti-replay processing supplies reliable application-item recovery adapted to prolonged interruptions.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "No reliable application transport or DTN recovery layer is selected. Host mobility and association maintenance retain their separate benefits." }, { "id": "F33-CX", "feature": "F33", "stack": "CX", "status": "N", "reason": "The selected CCNx 1.0 semantics provide Interest lifetimes, Interest Returns and Content Object matching over UDP. They do not define a reliable transfer recovery procedure adapted to prolonged loss of contact.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [ "round471.html", "round471-sources.json" ], "qualification": "RFC 8569 InterestLifetime and Interest Return behavior can support application retry decisions, but no contact-aware recovery extension is selected. Content caching and ordinary timeout/reissue behavior do not suffice for F33. This preserves the separate content retrieval, verification and reuse positives." }, { "id": "F33-LI", "feature": "F33", "stack": "LI", "status": "N", "reason": "The selected LISP composition carries application UDP in inner IPv4 and LISP/UDP encapsulation. RFC 9300 provides mapping-based forwarding and locator reachability; it does not supply reliable payload transfer. RFC 9301 control-message recovery maintains mappings, rather than retransmitting lost application datagrams.", "method": "Primary RFC and pinned implementation assessment; no runtime experiment", "source_label": "Selected-composition mechanisms and interface evidence", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-4.2", "https://www.rfc-editor.org/rfc/rfc9300.html#section-6", "https://www.rfc-editor.org/rfc/rfc9300.html#section-10", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [ "round485.html", "round485-sources.json", "round485-plan.json" ], "qualification": "No contact-adapted payload acknowledgment/retransmission layer is selected. Buffering a packet during a map lookup, RLOC probing, echo-nonce reachability and switching locators do not provide that service. This does not deny that a separately selected reliable or disruption-tolerant application could run over LISP." }, { "id": "F33-IL", "feature": "F33", "stack": "IL", "status": "N", "reason": "The selected ILNPv6/TCP composition changes transport identity binding and checksum inputs (RFC 6741 section 4), and updates locators while preserving endpoint identifiers. Its reliable-transfer layer remains TCP: RFC 6298 section 5 retransmits on RTO expiry and doubles the timer. No selected mechanism converts lost contact opportunities into suspended recovery timers or equivalent contact-aware resumption.", "method": "Primary specification analysis; no new runtime test", "source_label": "Primary specifications; selected-composition documentary assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc6741.html#section-4", "https://www.rfc-editor.org/rfc/rfc6741.html#section-5.2", "https://www.rfc-editor.org/rfc/rfc6298.html#section-5" ], "editorial_references": [ "round477.html", "round477-sources.json" ], "qualification": "RFC 6741 section 5.2 retains aged locator entries for active sessions; that preserves location state, not a suspended TCP recovery budget. Mobility continuity with overlapping attachments remains credited separately. No claim that all outages terminate TCP, or that TCP cannot accommodate long RTTs; the specific F33 adaptation is absent from this declared composition." }, { "id": "F33-TS", "feature": "F33", "stack": "TS", "status": "N", "reason": "The selected packet tunnel does not provide reliable item transfer adapted to prolonged interruption. Handshake retries eventually stop and discard staged packets rather than suspending recovery for a later contact.", "method": "Pinned dependency/source inspection and official documentation; no runtime test", "source_label": "Tailscale go.mod and selected wireguard-go dependency", "sources": [ "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/constants.go" ], "editorial_references": [ "round587.html", "round587-sources.json" ], "qualification": "DERP TCP reliability is limited to live relay connections. Ordinary application TCP, if added, would not establish delay-tolerant transfer recovery by itself." }, { "id": "F33-RA", "feature": "F33", "stack": "RA", "status": "N", "reason": "The selected default DTP/DTCP policies use retransmission limits and inactivity timers. The sender inactivity handler flushes retransmission and closed-window queues; the receiver handler resets receive state. This provides transport recovery within its configured bounds, not contact-aware suspension and resumption of reliable transfer across prolonged interruptions.", "method": "Primary independent report or pinned recovery-policy source inspection; no local execution", "source_label": "IRATI default DTP recovery policy and configuration", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/dtp-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/dtp.c", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/default.dif" ], "editorial_references": [ "round661.html" ], "qualification": "No for the selected policies. Enlarging lifetimes or retry timeouts alone does not meet F33. Other RINA policies may implement different recovery semantics; no general architectural impossibility is claimed. Source inspection only, not an outage experiment." }, { "id": "F34-PN", "feature": "F34", "stack": "PN", "status": "N", "reason": "The selected PRP stack carries PRP protocol units and E2E items over carriers. Using Ethernet as a carrier is not an Ethernet service for attached unmodified hosts. The selected wire and carrier specifications do not provide a multi-hop bridge transporting arbitrary endpoint Ethernet frames.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [], "editorial_references": [ "round464.html#prp-sources", "round464.html", "round464-sources.json" ], "qualification": "No Ethernet pseudowire, TAP bridge or Ethernet application adapter is selected. This does not rule out building such an additional service." }, { "id": "F34-PI", "feature": "F34", "stack": "PI", "status": "N", "reason": "The selected PRP stack carries PRP protocol units and E2E items over carriers. Using Ethernet as a carrier is not an Ethernet service for attached unmodified hosts. The selected wire and carrier specifications do not provide a multi-hop bridge transporting arbitrary endpoint Ethernet frames.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [], "editorial_references": [ "round464.html#prp-sources", "round464.html", "round464-sources.json" ], "qualification": "No Ethernet pseudowire, TAP bridge or Ethernet application adapter is selected. This does not rule out building such an additional service." }, { "id": "F34-IP", "feature": "F34", "stack": "IP", "status": "N", "reason": "IP routes network-layer datagrams rather than exposing a multi-hop Ethernet broadcast domain to attached endpoints.", "method": "Primary specification analysis; architectural capability, no runtime test", "source_label": "Pinned primary specification; selected-composition architectural assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round464.html", "round464-sources.json" ], "qualification": "Ethernet on individual links is not a transparent Ethernet service across the routed network. No bridging, VXLAN or Ethernet pseudowire is selected." }, { "id": "F34-BP", "feature": "F34", "stack": "BP", "status": "N", "reason": "BP/TCPCL in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9172.html", "https://www.rfc-editor.org/rfc/rfc9173.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-CG", "feature": "F34", "stack": "CG", "status": "N", "reason": "BP/SABR/TCPCL in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9172.html", "https://www.rfc-editor.org/rfc/rfc9173.html", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-LT", "feature": "F34", "stack": "LT", "status": "N", "reason": "BP/LTP/AOS in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html", "https://www.rfc-editor.org/rfc/rfc9172.html", "https://www.rfc-editor.org/rfc/rfc9173.html", "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-LP", "feature": "F34", "stack": "LP", "status": "N", "reason": "Direct-peer libp2p over QUIC delivers routed datagrams or transport data rather than an Ethernet frame service across multiple forwarding hops.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://github.com/libp2p/specs/blob/master/quic/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Known numeric peers and Peer IDs; no content-routing, object-transfer or pubsub module is selected. The existence of Ethernet beneath the stack does not make it an Ethernet bridge. No TAP service, pseudowire or Ethernet-carrying application is selected." }, { "id": "F34-TO", "feature": "F34", "stack": "TO", "status": "N", "reason": "Tor onion-service transport delivers its own routed packets, streams or messages rather than exposing a transparent multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://spec.torproject.org/tor-spec/relay-cells.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "No Ethernet pseudowire, bridge or application tunnel is selected. An IPv6 TUN interface, AX.25 link service or encrypted stream is not itself Ethernet bridging." }, { "id": "F34-I2", "feature": "F34", "stack": "I2", "status": "N", "reason": "I2P destination/tunnel transport delivers its own routed packets, streams or messages rather than exposing a transparent multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "No Ethernet pseudowire, bridge or application tunnel is selected. An IPv6 TUN interface, AX.25 link service or encrypted stream is not itself Ethernet bridging." }, { "id": "F34-YG", "feature": "F34", "stack": "YG", "status": "N", "reason": "Yggdrasil IPv6 overlay delivers its own routed packets, streams or messages rather than exposing a transparent multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "No Ethernet pseudowire, bridge or application tunnel is selected. An IPv6 TUN interface, AX.25 link service or encrypted stream is not itself Ethernet bridging." }, { "id": "F34-CJ", "feature": "F34", "stack": "CJ", "status": "N", "reason": "cjdns IPv6 overlay delivers its own routed packets, streams or messages rather than exposing a transparent multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "No Ethernet pseudowire, bridge or application tunnel is selected. An IPv6 TUN interface, AX.25 link service or encrypted stream is not itself Ethernet bridging." }, { "id": "F34-MQ", "feature": "F34", "stack": "MQ", "status": "N", "reason": "Multipath QUIC delivers routed datagrams or transport data rather than an Ethernet frame service across multiple forwarding hops.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc9001.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Selected multipath-21 manages paths for QUIC connections; it adds no content-object service. The existence of Ethernet beneath the stack does not make it an Ethernet bridge. No TAP service, pseudowire or Ethernet-carrying application is selected." }, { "id": "F34-SC", "feature": "F34", "stack": "SC", "status": "N", "reason": "SCION in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-RT", "feature": "F34", "stack": "RT", "status": "N", "reason": "Reticulum exposes its own packet/message and endpoint service over the selected serial or LoRa mesh. It does not expose a multi-hop Ethernet bridge carrying attached hosts' Ethernet frames unchanged.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://reticulum.network/manual/understanding.html" ], "editorial_references": [ "round472.html", "round472-sources.json" ], "qualification": "The selected composition includes no Ethernet tunneling or bridge extension. Carrier independence and mesh relaying alone do not provide Ethernet service; this does not deny that an additional application could transport encapsulated data." }, { "id": "F34-NS", "feature": "F34", "stack": "NS", "status": "N", "reason": "Nostr in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-MT", "feature": "F34", "stack": "MT", "status": "N", "reason": "Meshtastic exposes its own packet/message and endpoint service over the selected serial or LoRa mesh. It does not expose a multi-hop Ethernet bridge carrying attached hosts' Ethernet frames unchanged.", "method": "Primary documentary assessment; no new runtime test", "source_label": "Primary protocol documentation and declared composition; bounded documentary assessment", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [ "round472.html", "round472-sources.json" ], "qualification": "The selected composition includes no Ethernet tunneling or bridge extension. Carrier independence and mesh relaying alone do not provide Ethernet service; this does not deny that an additional application could transport encapsulated data." }, { "id": "F34-GN", "feature": "F34", "stack": "GN", "status": "N", "reason": "GNUnet CADET delivers its own routed packets, streams or messages rather than exposing a transparent multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "No Ethernet pseudowire, bridge or application tunnel is selected. An IPv6 TUN interface, AX.25 link service or encrypted stream is not itself Ethernet bridging." }, { "id": "F34-ND", "feature": "F34", "stack": "ND", "status": "N", "reason": "NDN in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NDN-packet-spec/current/data.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-AX", "feature": "F34", "stack": "AX", "status": "N", "reason": "AX.25/NET/ROM delivers its own routed packets, streams or messages rather than exposing a transparent multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary and source assessment; no new runtime test", "source_label": "Primary specification or selected-version source; bounded composition assessment", "sources": [ "https://linux-ax25.in-berlin.de/wiki/NET/ROM", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round470.html", "round470-sources.json" ], "qualification": "No Ethernet pseudowire, bridge or application tunnel is selected. An IPv6 TUN interface, AX.25 link service or encrypted stream is not itself Ethernet bridging." }, { "id": "F34-BA", "feature": "F34", "stack": "BA", "status": "Y", "reason": "The selected batman-adv mesh forwards Ethernet frames and exposes a virtual Ethernet service across its mesh nodes, keeping upper-layer protocols independent of internal mesh paths.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/Documentation/networking/batman-adv.rst" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Mesh nodes need the Linux module and interface setup; MTU, frame handling and broadcast-domain limits remain. No unbounded LAN scale or encryption is inferred." }, { "id": "F34-BL", "feature": "F34", "stack": "BL", "status": "N", "reason": "IPv6/Babel delivers routed datagrams or transport data rather than an Ethernet frame service across multiple forwarding hops.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Babel maintains prefix reachability for IPv6 datagrams; no application content protocol or cryptographic payload layer is selected. The existence of Ethernet beneath the stack does not make it an Ethernet bridge. No TAP service, pseudowire or Ethernet-carrying application is selected." }, { "id": "F34-RI", "feature": "F34", "stack": "RI", "status": "N", "reason": "6LoWPAN/IPv6/RPL/UDP/DTLS delivers routed datagrams or transport data rather than an Ethernet frame service across multiple forwarding hops.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Selected endpoint leaves use non-storing RPL and pairwise DTLS PSKs; no CoAP, MQTT, object-security or content-service layer is selected. The existence of Ethernet beneath the stack does not make it an Ethernet bridge. No TAP service, pseudowire or Ethernet-carrying application is selected." }, { "id": "F34-HP", "feature": "F34", "stack": "HP", "status": "N", "reason": "HIPv2/ESP with application UDP delivers routed datagrams or transport data rather than an Ethernet frame service across multiple forwarding hops.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "HIP identifies hosts and ESP protects host-to-host packets; no content-service or application-authentication wrapper is selected. The existence of Ethernet beneath the stack does not make it an Ethernet bridge. No TAP service, pseudowire or Ethernet-carrying application is selected." }, { "id": "F34-CX", "feature": "F34", "stack": "CX", "status": "N", "reason": "CCNx in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-LI", "feature": "F34", "stack": "LI", "status": "N", "reason": "LISP in the selected composition delivers its own packets, content objects or events; it does not expose a multi-hop Ethernet frame service to attached hosts.", "method": "Primary documentary capability assessment; no new runtime experiment", "source_label": "Primary protocol specification or pinned implementation; selected-composition assessment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html" ], "editorial_references": [ "round468.html", "round468-sources.json" ], "qualification": "Ethernet or another link beneath the selected stack is not an Ethernet bridge service above it. No added pseudowire, Ethernet tunnel or application bridge is selected." }, { "id": "F34-IL", "feature": "F34", "stack": "IL", "status": "N", "reason": "ILNPv6/TCP delivers routed datagrams or transport data rather than an Ethernet frame service across multiple forwarding hops.", "method": "Selected-composition primary documentary assessment; no runtime experiment", "source_label": "Primary selected transport/routing specifications and declared profile boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html" ], "editorial_references": [ "round469.html", "round469-sources.json" ], "qualification": "Identifier/Locator separation and DNS NID/L64 records address participants and their locations; no content-reference, IPsec or application-security layer is selected. The existence of Ethernet beneath the stack does not make it an Ethernet bridge. No TAP service, pseudowire or Ethernet-carrying application is selected." }, { "id": "F34-TS", "feature": "F34", "stack": "TS", "status": "N", "reason": "The selected Linux TUN and WireGuard profile transports IP packets. It does not expose an Ethernet frame bridge with transparent broadcast and multicast link service.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/features/site-to-site", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "Even the documented site-to-site service routes subnets at layer 3. An added layer-2 tunnel is outside the selected composition." }, { "id": "F34-RA", "feature": "F34", "stack": "RA", "status": "N", "reason": "The selected composition exposes application flow allocation and SDU I/O over normal DIFs. Its bottom Ethernet shim supplies a carrier; it does not expose a selected transparent multi-hop Ethernet bridge to unchanged attached endpoints.", "method": "Selected-service boundary assessment using primary API documentation; no execution", "source_label": "IRATI application API: registration, flow allocation and SDU exchange", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Application-API.md", "https://github.com/IRATI/stack/wiki/Application-API" ], "editorial_references": [ "round653.html" ], "qualification": "An added bridge or Ethernet-over-RINA service would be a different composition. Using Ethernet underneath and supporting application flows does not establish frame learning, broadcast forwarding or transparent attachment." }, { "id": "F36-PN", "feature": "F36", "stack": "PN", "status": "Y", "reason": "The protocol author explicitly confirms client negotiation of capacity, QoS and bandwidth reservation with the aggregators up to the rendezvous, with the opposite client negotiating its own half. Requested transport quality therefore participates in the agreed allocation of transport resources rather than only in packet priority marking. This supports architectural Yes for the selected PRP composition, using the same documentary capability level as the RINA assessment.", "method": "Author clarification and scoped local specification review; documentary capability, no execution test", "source_label": "Author clarification preserved in round581; inspected prp-spec working documents pinned in round646-sources.json", "sources": [], "editorial_references": [ "round646.html#F36-PN", "round581.html", "round581-sources.json", "round646-sources.json" ], "qualification": "Credit rests on the preserved author clarification in round581-sources.json, not a new executable or wire qualification. Each side negotiates its own half. Application API, rejection/counteroffer mapping, atomic reservation, capacity accounting and stale-agreement handling remain profile obligations; no numerical QoS guarantee or completed implementation is inferred. For PRP over IP, this is PRP-layer resource negotiation and does not reserve capacity in unparticipating IP routers." }, { "id": "F36-PI", "feature": "F36", "stack": "PI", "status": "Y", "reason": "The protocol author explicitly confirms client negotiation of capacity, QoS and bandwidth reservation with the aggregators up to the rendezvous, with the opposite client negotiating its own half. Requested transport quality therefore participates in the agreed allocation of transport resources rather than only in packet priority marking. This supports architectural Yes for the selected PRP composition, using the same documentary capability level as the RINA assessment.", "method": "Author clarification and scoped local specification review; documentary capability, no execution test", "source_label": "Author clarification preserved in round581; inspected prp-spec working documents pinned in round646-sources.json", "sources": [], "editorial_references": [ "round646.html#F36-PI", "round581.html", "round581-sources.json", "round646-sources.json" ], "qualification": "Credit rests on the preserved author clarification in round581-sources.json, not a new executable or wire qualification. Each side negotiates its own half. Application API, rejection/counteroffer mapping, atomic reservation, capacity accounting and stale-agreement handling remain profile obligations; no numerical QoS guarantee or completed implementation is inferred. For PRP over IP, this is PRP-layer resource negotiation and does not reserve capacity in unparticipating IP routers." }, { "id": "F36-IP", "feature": "F36", "stack": "IP", "status": "N", "reason": "The selected IP datagram service supplies no application flow-admission and resource-reservation exchange. Priority marking alone fails F36. Integrated Services describes an additional reservation setup protocol carrying a flowspec into admission control; that extension is not selected here. This is not a claim that the IP ecosystem cannot offer application-requested QoS.", "method": "Primary specification and implementation documentation review; no runtime experiment", "source_label": "RFC 1633, RFC 7567, RFC 2475 or IRATI Ethernet tutorial, as linked", "sources": [ "https://www.rfc-editor.org/rfc/rfc1633.html#section-3" ], "editorial_references": [ "round650.html" ], "qualification": "Selected composition only: no RSVP/IntServ is added. DiffServ provisioning in F38 does not itself provide application-requested admission." }, { "id": "F36-BP", "feature": "F36", "stack": "BP", "status": "N", "reason": "The selected basic BPv7/TCPCLv4 service accepts messages with lifetimes and can retain, forward or expire them. RFC 9171 leaves forwarding decisions to routing policy; it supplies no application-requested service allocation mechanism. This column selects aggregate gateway exits and optional AQM/DiffServ, not CGR/SABR contact-volume admission. ION classOfService priority and lifetime parameters alone do not establish that additional allocation behavior.", "method": "Documentary plausibility with selected-version source corroboration", "source_label": "BPv7; CCSDS SABR 734.3-B-1; ION selected pin; GNUnet 0.20 ATS", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c" ], "editorial_references": [ "round705.html" ], "qualification": "No applies to this declared basic BP composition, not all BP routing implementations. The CG and LT columns explicitly add SABR and are assessed separately. Expiration, storage acceptance, transport flow control and queue priority are not by themselves F36 service allocation. No new runtime test." }, { "id": "F36-CG", "feature": "F36", "stack": "CG", "status": "Y", "reason": "The application supplies a bundle lifespan through the BP send interface. SABR 3.2.6.9 rejects routes predicted to miss that expiry and depleted routes; 3.2.6.8 and 3.2.8.1.2 account for available volume and debit the selected contacts when enqueuing a bundle. Thus the requested delivery time bound affects admission to a planned route and allocation of its capacity, beyond merely marking priority. ION BPv7 at the selected source pin corroborates the lifespan API and CGR checks against expirationTime and contact MTV.", "method": "Documentary plausibility with selected-version source corroboration", "source_label": "BPv7; CCSDS SABR 734.3-B-1; ION selected pin; GNUnet 0.20 ATS", "sources": [ "https://public.ccsds.org/Pubs/734x3b1.pdf", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/cgr/libcgr.c" ], "editorial_references": [ "round705.html" ], "qualification": "Architectural Yes for deadline-aware per-bundle route admission and local contact-volume accounting. A single common priority level suffices (SABR 3.2.6.8.1), so this witness does not depend on unresolved BPv7 propagation of priority, critical or custody metadata. It is not a distributed hard reservation, guaranteed deadline, or complete executable binding: unknown downstream backlog and contact-plan errors remain, and no candidate means CGR makes no forwarding selection (3.2.7); storage, expiry or supplementary routing policy still applies. No synchronous end-to-end service acceptance is claimed." }, { "id": "F36-LT", "feature": "F36", "stack": "LT", "status": "Y", "reason": "The application supplies a bundle lifespan through the BP send interface. SABR 3.2.6.9 rejects routes predicted to miss that expiry and depleted routes; 3.2.6.8 and 3.2.8.1.2 account for available volume and debit the selected contacts when enqueuing a bundle. Thus the requested delivery time bound affects admission to a planned route and allocation of its capacity, beyond merely marking priority. ION BPv7 at the selected source pin corroborates the lifespan API and CGR checks against expirationTime and contact MTV. In this column the credited mechanism belongs to its explicitly selected BP/SABR layer, not to LTP alone.", "method": "Documentary plausibility with selected-version source corroboration", "source_label": "BPv7; CCSDS SABR 734.3-B-1; ION selected pin; GNUnet 0.20 ATS", "sources": [ "https://public.ccsds.org/Pubs/734x3b1.pdf", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/library/libbp.c", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/cgr/libcgr.c" ], "editorial_references": [ "round705.html" ], "qualification": "Architectural Yes for deadline-aware per-bundle route admission and local contact-volume accounting. A single common priority level suffices (SABR 3.2.6.8.1), so this witness does not depend on unresolved BPv7 propagation of priority, critical or custody metadata. It is not a distributed hard reservation, guaranteed deadline, or complete executable binding: unknown downstream backlog and contact-plan errors remain, and no candidate means CGR makes no forwarding selection (3.2.7); storage, expiry or supplementary routing policy still applies. No synchronous end-to-end service acceptance is claimed. LTP all-red reliability and the unqualified LTP/Encapsulation/AOS integration do not supply an independent QoS guarantee." }, { "id": "F36-LP", "feature": "F36", "stack": "LP", "status": "N", "reason": "The libp2p resource manager admits local resource usage against configured limits. Its scoped memory, stream and connection budgets do not negotiate network capacity, delay or reliability requirements with transport resource owners. QUIC receive credit and stream reliability do not supply that service contract.", "method": "Primary QUIC/libp2p documentation and explicit IP policy selection", "source_label": "libp2p resource management, multipath-21 and IETF transport policies", "sources": [ "https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/README.md", "https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html#section-4" ], "editorial_references": [ "round683.html" ], "qualification": "Selected composition only. Local resource accounting, scheduling preferences and operator DiffServ provisioning are distinct from F36. No additional reservation protocol or QoS wrapper is selected." }, { "id": "F36-TO", "feature": "F36", "stack": "TO", "status": "N", "reason": "The selected Tor application interface requests a destination connection, with stream isolation and onion-service error reporting. It does not convey application capacity, delay or reliability requirements into network resource reservation and flow admission. Circuit creation and SENDME flow control establish and regulate communication, rather than accepting an application service-quality contract.", "method": "Primary Tor specification and explicitly selected IP policy review", "source_label": "Tor Specifications and RFC 7567", "sources": [ "https://spec.torproject.org/socks-extensions.html", "https://spec.torproject.org/tor-spec/flow-control.html", "https://spec.torproject.org/tor-spec/create-created-cells.html" ], "editorial_references": [ "round678.html" ], "qualification": "Operator bandwidth limits and local priority are separate from application-requested QoS. Neither optional Conflux linking nor the selected IP AQM adds a reservation interface; no RSVP/IntServ extension is selected." }, { "id": "F36-I2", "feature": "F36", "stack": "I2", "status": "N", "reason": "The ECIES tunnel specification defines router-level bandwidth requests and admission, but explicitly leaves application bandwidth requirements without an I2CP/SAM option. I2CP GetBandwidthLimits reads limits rather than requesting a network allocation. The selected composition therefore lacks the application-to-network service request required by F36.", "method": "Primary client-interface and reservation architecture review", "source_label": "I2P ECIES/I2CP specifications; COLIBRI CoNEXT 2021", "sources": [ "https://www.i2p.net/en/docs/specs/tunnel-creation-ecies/", "https://i2p.net/en/docs/specs/i2cp/", "https://i2p.net/en/get-involved/roadmap/" ], "editorial_references": [ "round685.html" ], "qualification": "Scoped to the documented client interface. This does not deny tunnel-level negotiation or rest on absence of an implementation. The proposal status note is historical; later implementation work does not by itself supply an application request interface." }, { "id": "F36-YG", "feature": "F36", "stack": "YG", "status": "N", "reason": "Yggdrasil exposes an IPv6 datagram service over the selected TCP/TLS private-IP peerings. Peering-interface priority chooses a preferred attachment; it does not negotiate an application service contract. The declared application UDP path has no request-to-admission mapping for capacity, delay or reliability. Local AQM and DiffServ provisioning do not add one.", "method": "Primary configuration and IP service-policy review; explicit optional mechanisms", "source_label": "Project peering documentation and RFC 7567/2475", "sources": [ "https://yggdrasil-network.github.io/configurationref.html", "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [ "round680.html" ], "qualification": "Selected composition only; no RSVP/IntServ, application QoS wrapper or alternate transport is added. This does not deny operator priority controls." }, { "id": "F36-CJ", "feature": "F36", "stack": "CJ", "status": "N", "reason": "cjdns exposes an IPv6 datagram service over the selected UDP private-IP peerings. The UDP-interface DSCP setting marks outer traffic; marking alone does not perform application admission or resource reservation. The declared application UDP path has no request-to-admission mapping for capacity, delay or reliability. Local AQM and DiffServ provisioning do not add one.", "method": "Primary configuration and IP service-policy review; explicit optional mechanisms", "source_label": "Project peering documentation and RFC 7567/2475", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md", "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md", "https://github.com/cjdelisle/cjdns/blob/master/client/cjdroute2.c" ], "editorial_references": [ "round680.html" ], "qualification": "Selected composition only; no RSVP/IntServ, application QoS wrapper or alternate transport is added. This does not deny operator priority controls." }, { "id": "F36-MQ", "feature": "F36", "stack": "MQ", "status": "N", "reason": "Multipath-21 establishes and manages paths and permits per-path loss/congestion control. Application packet scheduling is not specified by the draft, and the selected composition has no application QoS request mapped to network admission and reservation. QUIC receive credit and stream reliability do not supply that service contract.", "method": "Primary QUIC/libp2p documentation and explicit IP policy selection", "source_label": "libp2p resource management, multipath-21 and IETF transport policies", "sources": [ "https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21", "https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21", "https://www.rfc-editor.org/rfc/rfc9000.html#section-4" ], "editorial_references": [ "round683.html" ], "qualification": "Selected composition only. Local resource accounting, scheduling preferences and operator DiffServ provisioning are distinct from F36. No additional reservation protocol or QoS wrapper is selected." }, { "id": "F36-SC", "feature": "F36", "stack": "SC", "status": "Y", "reason": "With COLIBRI explicitly selected, an application requests and renews bandwidth through an extended SCION daemon. Reservation services admit the end-to-end request against segment capacity; participating ASes and the destination can refuse it. Accepted allocations are enforced through gateway policing and traffic monitoring.", "method": "Primary client-interface and reservation architecture review", "source_label": "I2P ECIES/I2CP specifications; COLIBRI CoNEXT 2021", "sources": [ "https://netsec.ethz.ch/publications/papers/2021_conext_colibri.pdf", "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round685.html" ], "qualification": "Architectural capability documented in the 2021 paper, sections 3.2-3.4 and 4.3. Requires participating infrastructure, available segment reservations, synchronized clocks and renewal. It is not a property of an unextended SCION UDP stack, nor a current deployment, interoperability or performance certification." }, { "id": "F36-RT", "feature": "F36", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link establishment carries public keys and MTU/mode signalling, not an application capacity or delay request admitted against transit resources. Link.request timeouts and Resource transfer control govern endpoint exchanges; they do not allocate service along the serial transport path.", "method": "Versioned native source and official API review", "source_label": "Reticulum 1.5.5 and selected Meshtastic firmware source", "sources": [ "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Link.py", "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Resource.py", "https://reticulum.network/manual/reference.html" ], "editorial_references": [ "round686.html" ], "qualification": "Selected native Link/serial composition only. Reliable transfer, local interface budgets and application response limits are useful but do not constitute network QoS admission. No IP reservation layer or custom application protocol is selected." }, { "id": "F36-NS", "feature": "F36", "stack": "NS", "status": "N", "reason": "NIP-01 exchanges events, subscriptions and relay responses; it supplies no application QoS request mapped into network flow admission and reserved resources. The selected TCP/IP service and the AQM/DiffServ witnesses do not add that exchange. Subscription limits, relay acceptance and reliable TCP delivery do not establish an application-requested capacity or delay service.", "method": "Primary protocol review with explicit native IP policy selection", "source_label": "NIP-01 and IETF transport service architecture", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round677.html" ], "qualification": "No RSVP/IntServ or additional Nostr extension is selected. This verdict concerns admission/allocation from application requirements, not whether the operator can prioritize transport traffic." }, { "id": "F36-MT", "feature": "F36", "stack": "MT", "status": "N", "reason": "Meshtastic packet priority is a local-device field, not transmitted over the air. The selected firmware uses it to order or replace queued packets; want_ack enables reliability behavior. Neither mechanism carries an application capacity/delay request to transit nodes for resource admission or allocation.", "method": "Pinned firmware schema, queue and router source review", "source_label": "Meshtastic firmware 8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/mesh.pb.h", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/MeshPacketQueue.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/mesh.pb.h" ], "editorial_references": [ "round687.html" ], "qualification": "Selected standalone LoRa composition only. Local queue acceptance, acknowledgments, retransmission and duty-cycle errors do not form an end-to-end QoS service contract. No custom reservation application or external network service is selected." }, { "id": "F36-GN", "feature": "F36", "stack": "GN", "status": "Y", "reason": "GNUnet 0.20 ATS accepts higher-service bandwidth preferences through GNUNET_ATS_performance_change_preference. Its selected proportional allocator checks available network quotas before admitting an address and distributes remaining bandwidth according to application preferences. ATS communicates allocations to TRANSPORT. This supplies a request-to-resource-allocation path rather than only packet priority marking.", "method": "Documentary plausibility with selected-version source corroboration", "source_label": "BPv7; CCSDS SABR 734.3-B-1; ION selected pin; GNUnet 0.20 ATS", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/ats/ats.html", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round705.html" ], "qualification": "Yes is scoped to local ATS-managed peer transport allocation, including a directly connected CADET peer in the selected UDP/CORE composition. It does not establish end-to-end reservation across arbitrary CADET relays, strict bandwidth/latency guarantees or channel-by-channel isolation. Preferences share administrator quotas and can be only partly satisfied; insufficient quota can prevent activation. Proportional bandwidth allocation, not every latency optimization of other ATS plugins, is credited. Source inspection, not a new runtime measurement. The separate application-suggest API is not used as the legacy proportional-path witness." }, { "id": "F36-ND", "feature": "F36", "stack": "ND", "status": "N", "reason": "NDN Interests express content matching, freshness, forwarding hints, lifetime and hop limits. The selected NFD/packet-format composition does not map an application capacity, delay or reliability request to network flow admission and resource allocation. InterestLifetime is a timeout, not an admitted delay service.", "method": "Primary packet semantics and forwarding-policy review", "source_label": "NDN packet format v0.3 and CCNx RFC 8569", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html" ], "editorial_references": [ "round689.html" ], "qualification": "ApplicationParameters can carry custom data but do not define a QoS contract. Local management of forwarding strategies or caches is distinct from application-requested network service. No custom reservation extension is selected." }, { "id": "F36-AX", "feature": "F36", "stack": "AX", "status": "N", "reason": "Linux 6.12 NET/ROM exposes retry, acknowledgment, busy and idle timers through nr_setsockopt. Connection acceptance checks the listening socket, backlog and allocation, then negotiates a transport window and optional timeout. This is endpoint transport setup and flow control, not network admission/allocation driven by requested communication capacity, delay or reliability. The selected classic AX.25/NET/ROM composition supplies no additional service reservation layer.", "method": "Bounded documentary assessment of selected service interface and admission semantics", "source_label": "Linux v6.12 control/transport interfaces; RPL RFC 6550 and OF0 RFC 6552", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/nr_out.c" ], "editorial_references": [ "round704.html" ], "qualification": "No is scoped to the selected Linux/classic NET/ROM composition. Window/timeout negotiation and retransmission reliability remain credited where applicable; generic socket priority does not satisfy F36. No claim about every radio stack or extension and no runtime trial." }, { "id": "F36-BA", "feature": "F36", "stack": "BA", "status": "N", "reason": "The selected native Ethernet BATMAN_IV service forwards frames through a virtual mesh interface. Linux 6.12 exposes mesh, interface and VLAN configuration and routing telemetry, rather than application service requests used for flow admission and resource allocation. Advertised gateway bandwidth and throughput metrics describe routing/configuration; they are not a service allocation contract. Gateway mode is off in the selected profile.", "method": "Bounded documentary assessment of selected service interface and admission semantics", "source_label": "Linux v6.12 control/transport interfaces; RPL RFC 6550 and OF0 RFC 6552", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/include/uapi/linux/batman_adv.h", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/netlink.c", "https://docs.kernel.org/networking/batman-adv.html" ], "editorial_references": [ "round704.html" ], "qualification": "No applies to the declared batman-adv composition. Generic host queue settings, packet priority or an added reservation layer are not an application-requested network service. This does not deny mesh forwarding or administrative traffic controls and does not decide F37/F38." }, { "id": "F36-BL", "feature": "F36", "stack": "BL", "status": "N", "reason": "Babel exchanges routing information and selects feasible routes from metrics; route selection is not application-requested service admission or resource reservation. The selected datagram application/service and operator transport policies add no such exchange.", "method": "Primary RFC review and explicit optional IP transport policy selection", "source_label": "HIP/Babel specifications and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html", "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round682.html" ], "qualification": "Selected composition only. No RSVP/IntServ or other application reservation protocol is included. Peer authorization, route availability and priority marking are not sufficient for F36." }, { "id": "F36-RI", "feature": "F36", "stack": "RI", "status": "N", "reason": "RPL permits routing instances with different optimization goals, but RFC 6550 section 3.1.3 leaves mapping an application traffic service to an instance outside its scope. The selected OF0 computes rank and chooses parents from provisioned/link parameters; it ignores metric containers. This is routing optimization, not application-requested flow admission and resource allocation. The declared UDP/DTLS and 6LoWPAN composition adds no such service-mapping or reservation mechanism.", "method": "Bounded documentary assessment of selected service interface and admission semantics", "source_label": "Linux v6.12 control/transport interfaces; RPL RFC 6550 and OF0 RFC 6552", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-3.1.3", "https://www.rfc-editor.org/rfc/rfc6552.html#section-1", "https://www.rfc-editor.org/rfc/rfc6552.html#section-5" ], "editorial_references": [ "round704.html" ], "qualification": "No concerns this explicit OF0/UDP/DTLS profile, not all RPL objective functions or IEEE 802.15.4 scheduling extensions. Routing constraints and link-security configuration do not supply the missing application-to-service allocation contract. No energy or performance test is claimed." }, { "id": "F36-HP", "feature": "F36", "stack": "HP", "status": "N", "reason": "HIP establishes authenticated host associations and ESP security state; these do not request capacity, delay or reliability from network admission control. The selected datagram application/service and operator transport policies add no such exchange.", "method": "Primary RFC review and explicit optional IP transport policy selection", "source_label": "HIP/Babel specifications and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html#section-3" ], "editorial_references": [ "round682.html" ], "qualification": "Selected composition only. No RSVP/IntServ or other application reservation protocol is included. Peer authorization, route availability and priority marking are not sufficient for F36." }, { "id": "F36-CX", "feature": "F36", "stack": "CX", "status": "N", "reason": "CCNx Interests request named content. Lifetime, hop limits and content restrictions do not request an admitted network quality service. The selected core composition has no application QoS allocation contract.", "method": "Primary packet semantics and forwarding-policy review", "source_label": "NDN packet format v0.3 and CCNx RFC 8569", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.1" ], "editorial_references": [ "round689.html" ], "qualification": "No custom reservation extension is selected; local policy and failure reporting do not establish one." }, { "id": "F36-LI", "feature": "F36", "stack": "LI", "status": "N", "reason": "LISP EID-to-RLOC mapping and locator priorities/weights steer datagrams; the inner UDP application does not request admission against a reserved capacity or delay budget.", "method": "Primary RFC review with explicit optional transport mechanisms", "source_label": "RFC 9300/6741 and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc9300.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round681.html" ], "qualification": "No application-requested reservation protocol is selected. Traffic engineering, TCP reliability, packet marking and operator provisioning do not by themselves meet F36." }, { "id": "F36-IL", "feature": "F36", "stack": "IL", "status": "N", "reason": "ILNPv6 Locator selection and updates preserve identifier-bound transport across attachments; the selected TCP interface does not request admission against a reserved capacity or delay budget.", "method": "Primary RFC review with explicit optional transport mechanisms", "source_label": "RFC 9300/6741 and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc6741.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc6741.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round681.html" ], "qualification": "No application-requested reservation protocol is selected. Traffic engineering, TCP reliability, packet marking and operator provisioning do not by themselves meet F36." }, { "id": "F36-TS", "feature": "F36", "stack": "TS", "status": "N", "reason": "The selected standard TUN client carries application IP traffic through WireGuard, directly or through DERP fallback. Tailscale network grants select sources, destinations, protocols and ports; these permissions do not request capacity or delay and reserve network resources for the application. Optional IP AQM and DiffServ provisioning likewise do not supply that application request/admission exchange.", "method": "Primary Tailscale documentation and explicitly selected IP policy review", "source_label": "Tailscale grants and IETF transport policy architecture", "sources": [ "https://tailscale.com/docs/reference/syntax/grants", "https://tailscale.com/docs/concepts/what-is-tailscale", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round679.html" ], "qualification": "No RSVP/IntServ or application QoS extension is selected. Access permission, Tailnet Lock, direct-path selection and application capabilities are not treated as service-quality reservation. This is a verdict for the declared stack, not all possible host traffic-control extensions." }, { "id": "F36-RA", "feature": "F36", "stack": "RA", "status": "Y", "reason": "RINA exposes requested service quality at flow allocation and maps it to QoS cubes; application and lower-layer flow requests use the same model. Credit is architectural, not a guaranteed capacity or delay result.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Documentary architectural credit for the declared RINA composition. IRATI is a reference implementation, but no release, policy configuration, executable integration or performance result is qualified here. Detailed linked QoS/congestion pages could not be fetched; the retrieved project overview states the credited mechanisms. Other RINA capabilities remain separately assessed." }, { "id": "F37-PN", "feature": "F37", "stack": "PN", "status": "Y", "reason": "The author confirms that PRP control-plane denials include saturation and identify the affected point on the trajectory. Each endpoint negotiates priority and traffic with participants up to the rendezvous, enabling control directed at the reported segment; each aggregator also schedules packets autonomously with reserved control-plane capacity. Together these supply localized feedback and the ability to adjust traffic under the revised F37. Credit is architectural and does not depend on a new wire command or an intermediate aggregate controller.", "method": "Author-attributed architectural capability; no runtime test", "source_label": "Protocol-author clarifications and approved criterion reformulation, 2026-10-25", "sources": [], "editorial_references": [ "round648.html", "round647-sources.json", "round581-sources.json", "round648.html" ], "qualification": "Author-confirmed architecture, with verbatim statements retained in round647-sources.json. No particular encoding, scheduling algorithm, automatic controller, queue-disposal rule, response time or validated implementation is inferred. Reserved control capacity is not an unconditional guarantee under arbitrary overload. Each endpoint controls its half up to the rendezvous. For PRP over IP the mechanism concerns participating PRP adjacencies, not congestion localization or capacity reservation at every underlying IP router." }, { "id": "F37-PI", "feature": "F37", "stack": "PI", "status": "Y", "reason": "The author confirms that PRP control-plane denials include saturation and identify the affected point on the trajectory. Each endpoint negotiates priority and traffic with participants up to the rendezvous, enabling control directed at the reported segment; each aggregator also schedules packets autonomously with reserved control-plane capacity. Together these supply localized feedback and the ability to adjust traffic under the revised F37. Credit is architectural and does not depend on a new wire command or an intermediate aggregate controller.", "method": "Author-attributed architectural capability; no runtime test", "source_label": "Protocol-author clarifications and approved criterion reformulation, 2026-10-25", "sources": [], "editorial_references": [ "round648.html", "round647-sources.json", "round581-sources.json", "round648.html" ], "qualification": "Author-confirmed architecture, with verbatim statements retained in round647-sources.json. No particular encoding, scheduling algorithm, automatic controller, queue-disposal rule, response time or validated implementation is inferred. Reserved control capacity is not an unconditional guarantee under arbitrary overload. Each endpoint controls its half up to the rendezvous. For PRP over IP the mechanism concerns participating PRP adjacencies, not congestion localization or capacity reservation at every underlying IP router." }, { "id": "F37-IP", "feature": "F37", "stack": "IP", "status": "Y", "reason": "Select router-local active queue management under RFC 7567, using congestion-dependent dropping for non-ECN traffic. The router observes pressure at its own queue and adjusts admission/forwarded traffic there. This is local action at the affected segment, not an assertion that an endpoint learns its location from a generic loss or ECN signal.", "method": "Primary specification and implementation documentation review; no runtime experiment", "source_label": "RFC 1633, RFC 7567, RFC 2475 or IRATI Ethernet tutorial, as linked", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2" ], "editorial_references": [ "round650.html" ], "qualification": "Optional router AQM explicitly selected as an architectural witness. Dropping contains local queue pressure but does not force an unresponsive source to reduce its offered load, recover consumed upstream bandwidth or guarantee delivery. No application TCP or ECN feedback loop is added; no runtime test." }, { "id": "F37-BP", "feature": "F37", "stack": "BP", "status": "Y", "reason": "Secure DTN explicitly selects AQM on its IPv4 transport. Router-local queue pressure causes local dropping at the affected egress. This supplies a localized congestion-control action for the TCPCL transport path.", "method": "Primary RFC review and explicit composition selection", "source_label": "IETF TCPCLv4, AQM and DiffServ specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round688.html" ], "qualification": "Optional underlay witness, not a claim that BP or CGR diagnoses all congested contacts. No bundle-storage control, disconnected-contact feedback, payload inspection or global delivery guarantee follows. Existing implementation qualifications remain." }, { "id": "F37-CG", "feature": "F37", "stack": "CG", "status": "Y", "reason": "DTN/CGR-SABR explicitly selects AQM on its IPv4 transport. Router-local queue pressure causes local dropping at the affected egress. This supplies a localized congestion-control action for the TCPCL transport path.", "method": "Primary RFC review and explicit composition selection", "source_label": "IETF TCPCLv4, AQM and DiffServ specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round688.html" ], "qualification": "Optional underlay witness, not a claim that BP or CGR diagnoses all congested contacts. No bundle-storage control, disconnected-contact feedback, payload inspection or global delivery guarantee follows. Existing implementation qualifications remain." }, { "id": "F37-LT", "feature": "F37", "stack": "LT", "status": "?", "reason": "Not yet established under the revised segment-targeted congestion criterion. Local and endpoint-directed control are both eligible; do not apply the former aggregate-controller requirement.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify the localized congestion signal or local observation, affected link/region, controller and available traffic adjustment. Endpoint-directed control and intermediate autonomous control are both admissible. Separate capacity negotiation from a response to saturation; distinguish architectural evidence from execution." }, { "id": "F37-LP", "feature": "F37", "stack": "LP", "status": "Y", "reason": "Select router-local AQM in the existing IP transport carrying libp2p UDP packets. Queue pressure is observed at the affected router and congestion-dependent dropping acts there.", "method": "Primary QUIC/libp2p documentation and explicit IP policy selection", "source_label": "libp2p resource management, multipath-21 and IETF transport policies", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html#section-4" ], "editorial_references": [ "round683.html" ], "qualification": "Optional IP-layer witness, not inferred from generic QUIC end-to-end loss, RTT or path choice. It requires no encrypted stream inspection and guarantees neither delivery nor recovery of upstream capacity. No runtime or universal deployment claim." }, { "id": "F37-TO", "feature": "F37", "stack": "TO", "status": "Y", "reason": "Explicitly select router-local active queue management in the IPv4 transport carrying Tor TCP/TLS links. RFC 7567 describes congestion-dependent dropping based on the affected router queue. The controller acts at that segment; the onion-service application need not learn its location.", "method": "Primary Tor specification and explicitly selected IP policy review", "source_label": "Tor Specifications and RFC 7567", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2" ], "editorial_references": [ "round678.html" ], "qualification": "Optional IP-layer architectural witness, not proof that every Tor relay path deploys AQM. Ordinary TCP loss or circuit SENDME alone is not credited as localization. Local queue control does not restore consumed upstream capacity or guarantee delivery." }, { "id": "F37-I2", "feature": "F37", "stack": "I2", "status": "Y", "reason": "The selected IPv4 underlay carrying I2P TCP/NTCP2 uses optional router-local AQM. The affected egress queue observes its own pressure and applies congestion-dependent dropping at that location.", "method": "Primary specifications and explicit IP policy composition", "source_label": "IETF AQM and DiffServ; I2P and SCION transport documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.i2p.net/en/docs/specs/tunnel-implementation/" ], "editorial_references": [ "round684.html" ], "qualification": "The witness belongs to the explicitly selected IP composition. No endpoint identification of every congested hop, encrypted-payload inspection, ECN support or overlay-wide congestion guarantee is required. Local queue action does not recover upstream capacity or force an unresponsive sender to reduce its rate." }, { "id": "F37-YG", "feature": "F37", "stack": "YG", "status": "Y", "reason": "Select AQM on the local IP egress queue carrying each Yggdrasil TCP/TLS peering. Queue-pressure observation and congestion-dependent dropping act at the affected link, including when that queue belongs to a host forwarding encrypted overlay traffic.", "method": "Primary configuration and IP service-policy review; explicit optional mechanisms", "source_label": "Project peering documentation and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [ "round680.html" ], "qualification": "Optional transport-layer witness. The existing private adjacency topology is retained; no routed public underlay is required. This does not bound hidden overlay queues, expose the bottleneck to applications, guarantee delivery or compel an unresponsive sender to slow down." }, { "id": "F37-CJ", "feature": "F37", "stack": "CJ", "status": "Y", "reason": "Select AQM on the local IP egress queue carrying each cjdns UDP peering. Queue-pressure observation and congestion-dependent dropping act at the affected link, including when that queue belongs to a host forwarding encrypted overlay traffic.", "method": "Primary configuration and IP service-policy review; explicit optional mechanisms", "source_label": "Project peering documentation and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md" ], "editorial_references": [ "round680.html" ], "qualification": "Optional transport-layer witness. The existing private adjacency topology is retained; no routed public underlay is required. This does not bound hidden overlay queues, expose the bottleneck to applications, guarantee delivery or compel an unresponsive sender to slow down." }, { "id": "F37-MQ", "feature": "F37", "stack": "MQ", "status": "Y", "reason": "Select router-local AQM in the existing IP transport carrying Multipath QUIC UDP packets. Queue pressure is observed at the affected router and congestion-dependent dropping acts there.", "method": "Primary QUIC/libp2p documentation and explicit IP policy selection", "source_label": "libp2p resource management, multipath-21 and IETF transport policies", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21", "https://www.rfc-editor.org/rfc/rfc9000.html#section-4" ], "editorial_references": [ "round683.html" ], "qualification": "Optional IP-layer witness, not inferred from generic QUIC end-to-end loss, RTT or path choice. It requires no encrypted stream inspection and guarantees neither delivery nor recovery of upstream capacity. No runtime or universal deployment claim." }, { "id": "F37-SC", "feature": "F37", "stack": "SC", "status": "Y", "reason": "The selected IPv4 underlay carrying SCION UDP uses optional router-local AQM. The affected egress queue observes its own pressure and applies congestion-dependent dropping at that location.", "method": "Primary specifications and explicit IP policy composition", "source_label": "IETF AQM and DiffServ; I2P and SCION transport documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round684.html" ], "qualification": "The witness belongs to the explicitly selected IP composition. No endpoint identification of every congested hop, encrypted-payload inspection, ECN support or overlay-wide congestion guarantee is required. Local queue action does not recover upstream capacity or force an unresponsive sender to reduce its rate." }, { "id": "F37-RT", "feature": "F37", "stack": "RT", "status": "?", "reason": "Not yet established under the revised segment-targeted congestion criterion. Local and endpoint-directed control are both eligible; do not apply the former aggregate-controller requirement.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify the localized congestion signal or local observation, affected link/region, controller and available traffic adjustment. Endpoint-directed control and intermediate autonomous control are both admissible. Separate capacity negotiation from a response to saturation; distinguish architectural evidence from execution." }, { "id": "F37-NS", "feature": "F37", "stack": "NS", "status": "Y", "reason": "Explicitly select router-local AQM in the IPv4 transport carrying the WebSocket connections. Under RFC 7567, the router observes its own queue pressure and applies congestion-dependent dropping at that segment. This is localized control even though the Nostr application does not learn which router acted.", "method": "Primary protocol review with explicit native IP policy selection", "source_label": "NIP-01 and IETF transport service architecture", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2" ], "editorial_references": [ "round677.html" ], "qualification": "Optional IP-layer architectural witness, not a NIP-01 feature or a claim that every public relay path deploys AQM. It controls the local queue; it does not recover upstream capacity or guarantee delivery. Ordinary end-to-end TCP loss alone is not the qualifying mechanism." }, { "id": "F37-MT", "feature": "F37", "stack": "MT", "status": "Y", "reason": "Meshtastic observes activity on the local LoRa channel and delays transmission while it is busy. RadioInterface.getTxDelayMsec adjusts the contention window using measured channel utilization; RadioLibInterface schedules the delay and retries channel activity detection before sending. This couples local congestion observation to action in the affected radio region.", "method": "Versioned native source and official API review", "source_label": "Reticulum 1.5.5 and selected Meshtastic firmware source", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/RadioInterface.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/RadioLibInterface.cpp", "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [ "round686.html" ], "qualification": "Pinned firmware source, with real LoRa as already selected. Local shared-medium control is not end-to-end bandwidth reservation, identification of every remote bottleneck or a guarantee against hidden terminals and overload. Relayed-packet timing also uses SNR; not every transmission uses the same delay formula." }, { "id": "F37-GN", "feature": "F37", "stack": "GN", "status": "Y", "reason": "GNUnet 0.20 CORE try_transmission checks the encrypted message queue for a specific neighbour and stops feeding it at MAX_ENCRYPTED_MESSAGE_QUEUE_SIZE (4). GSC_NEIGHBOURS_get_queue_length reads that neighbour message queue, rather than a generic end-to-end loss signal. Transport quota tracking delays further sends, and readiness/excess-bandwidth callbacks invoke GSC_SESSIONS_solicit for the affected peer. At an overlay relay this is local congestion response for an identified outgoing segment, also controlling forwarding traffic.", "method": "Selected-version source path and documentary plausibility", "source_label": "GNUnet 0.20.0 CORE, legacy TRANSPORT and proportional ATS", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round706.html" ], "qualification": "Architectural/source Yes for local queue saturation and backpressure in the selected CORE/legacy TRANSPORT path. It does not locate hidden IP-underlay bottlenecks, report a complete congested trajectory to the endpoint, prove fair or lossless behavior, or establish a measured response time. The quota announced by a remote neighbour is not the witness: IGNORE_INBOUND_QUOTA is enabled in this version. The queue observation plus associated feeding control, not static rate shaping alone, qualifies." }, { "id": "F37-ND", "feature": "F37", "stack": "ND", "status": "N", "reason": "In the selected NFD 24.07 direct-Ethernet composition, EthernetTransport and its unicast/multicast subclasses do not override Transport::getSendQueueLength, whose default is QUEUE_UNSUPPORTED. GenericLinkService::checkCongestionLevel returns immediately for this negative value, so its queue-based congestion marking cannot observe these Ethernet outputs. Multicast v5 suppresses repeated Interests by elapsed-time/backoff rules, not observed segment saturation. The selected forwarding path therefore lacks the localized congestion observation and associated traffic adjustment required by F37.", "method": "Pinned inheritance, queue-observation and strategy-source audit", "source_label": "NFD 24.07 a1480a7c: Transport, Ethernet faces, GenericLinkService and multicast v5", "sources": [ "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/transport.hpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/generic-link-service.cpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/ethernet-transport.hpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/unicast-ethernet-transport.hpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/multicast-ethernet-transport.hpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/ethernet-transport.cpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/multicast-strategy.cpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/retx-suppression-exponential.cpp" ], "editorial_references": [ "round707.html" ], "qualification": "No is restricted to the pinned direct-Ethernet faces and selected multicast v5 strategy. It is not a claim that NDN lacks congestion mechanisms generally: other transports, strategies, consumer algorithms or additional link queue controls may differ. Merely enabling a marking option does not supply unsupported queue telemetry. Packet-injection errors, receive-drop counters and elapsed-time retransmission suppression are not an identified congestion-control feedback loop. No IP AQM layer is selected. Source-level decision, not a congestion experiment; F38 remains separately Pending." }, { "id": "F37-AX", "feature": "F37", "stack": "AX", "status": "?", "reason": "Not yet established under the revised segment-targeted congestion criterion. Local and endpoint-directed control are both eligible; do not apply the former aggregate-controller requirement.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify the localized congestion signal or local observation, affected link/region, controller and available traffic adjustment. Endpoint-directed control and intermediate autonomous control are both admissible. Separate capacity negotiation from a response to saturation; distinguish architectural evidence from execution." }, { "id": "F37-BA", "feature": "F37", "stack": "BA", "status": "?", "reason": "Not yet established under the revised segment-targeted congestion criterion. Local and endpoint-directed control are both eligible; do not apply the former aggregate-controller requirement.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify the localized congestion signal or local observation, affected link/region, controller and available traffic adjustment. Endpoint-directed control and intermediate autonomous control are both admissible. Separate capacity negotiation from a response to saturation; distinguish architectural evidence from execution." }, { "id": "F37-BL", "feature": "F37", "stack": "BL", "status": "Y", "reason": "Select router-local AQM in the existing IPv6 forwarding interfaces of the Babel-routed network. Local queue-pressure observation triggers congestion-dependent dropping at the affected segment.", "method": "Primary RFC review and explicit optional IP transport policy selection", "source_label": "HIP/Babel specifications and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round682.html" ], "qualification": "Explicit optional IP-layer witness. This is not a claim that IP / Babel itself reports the bottleneck location or that every deployment enables AQM. No measured response time, delivery guarantee or recovery of upstream capacity is inferred." }, { "id": "F37-RI", "feature": "F37", "stack": "RI", "status": "?", "reason": "Not yet established under the revised segment-targeted congestion criterion. Local and endpoint-directed control are both eligible; do not apply the former aggregate-controller requirement.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify the localized congestion signal or local observation, affected link/region, controller and available traffic adjustment. Endpoint-directed control and intermediate autonomous control are both admissible. Separate capacity negotiation from a response to saturation; distinguish architectural evidence from execution." }, { "id": "F37-HP", "feature": "F37", "stack": "HP", "status": "Y", "reason": "Select router-local AQM in the IP forwarding layer carrying HIP control and ESP-protected user traffic. Local queue-pressure observation triggers congestion-dependent dropping at the affected segment.", "method": "Primary RFC review and explicit optional IP transport policy selection", "source_label": "HIP/Babel specifications and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html#section-3" ], "editorial_references": [ "round682.html" ], "qualification": "Explicit optional IP-layer witness. This is not a claim that HIPv2 / ESP itself reports the bottleneck location or that every deployment enables AQM. No measured response time, delivery guarantee or recovery of upstream capacity is inferred." }, { "id": "F37-CX", "feature": "F37", "stack": "CX", "status": "Y", "reason": "A congested CCNx forwarder can discard an Interest and return Congestion to its preceding hop. That hop can select another available next hop or clear the pending state and propagate the failure.", "method": "Primary packet semantics and forwarding-policy review", "source_label": "NDN packet format v0.3 and CCNx RFC 8569", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-10.3.7" ], "editorial_references": [ "round689.html" ], "qualification": "Explicit optional behavior from sections 2.4.4 and 10.3. Not a specified queue estimator, continuous rate controller or guarantee of an alternative path. Executable integration remains unqualified." }, { "id": "F37-LI", "feature": "F37", "stack": "LI", "status": "Y", "reason": "Select router-local AQM in the outer IPv4 transport carrying LISP encapsulation. Queue pressure is observed locally and congestion-dependent dropping adjusts traffic at that affected queue.", "method": "Primary RFC review with explicit optional transport mechanisms", "source_label": "RFC 9300/6741 and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.rfc-editor.org/rfc/rfc9300.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round681.html" ], "qualification": "Optional architectural mechanism under RFC 7567, not universal deployment. No endpoint bottleneck-location report, ECN implementation or measured reaction time is assumed. It does not guarantee delivery or recover upstream capacity." }, { "id": "F37-IL", "feature": "F37", "stack": "IL", "status": "Y", "reason": "Select router-local AQM in the IPv6-compatible ILNPv6 forwarding plane, whose core routers route on Locator prefixes. Queue pressure is observed locally and congestion-dependent dropping adjusts traffic at that affected queue.", "method": "Primary RFC review with explicit optional transport mechanisms", "source_label": "RFC 9300/6741 and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2", "https://www.rfc-editor.org/rfc/rfc6741.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round681.html" ], "qualification": "Optional architectural mechanism under RFC 7567, not universal deployment. No endpoint bottleneck-location report, ECN implementation or measured reaction time is assumed. It does not guarantee delivery or recover upstream capacity." }, { "id": "F37-TS", "feature": "F37", "stack": "TS", "status": "Y", "reason": "Explicitly select router-local AQM on the routed IP transport carrying the outer WireGuard UDP traffic or the DERP connection. A router observes its own queue pressure and performs congestion-dependent dropping at the affected segment under RFC 7567. This controls a localized transport queue without requiring Tailscale to expose the bottleneck location.", "method": "Primary Tailscale documentation and explicitly selected IP policy review", "source_label": "Tailscale grants and IETF transport policy architecture", "sources": [ "https://www.rfc-editor.org/rfc/rfc7567.html#section-2" ], "editorial_references": [ "round679.html" ], "qualification": "Optional underlay mechanism, not a WireGuard congestion controller or universal public-network deployment. Direct and relayed paths can use it. It does not guarantee inner-flow fairness, responsive UDP senders, delivery or recovery of bandwidth already consumed upstream." }, { "id": "F37-RA", "feature": "F37", "stack": "RA", "status": "Y", "reason": "RINA specifies per-layer congestion control, including controllers over aggregates at lower layers. The controlled region is the DIF rather than necessarily the full final-endpoint path. No measured speedup is inferred. Reassessment under the revised F37: per-layer feedback and traffic adjustment target the affected DIF region, so this existing Yes is retained; exact physical-hop identification is not required.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Documentary architectural credit for the declared RINA composition. IRATI is a reference implementation, but no release, policy configuration, executable integration or performance result is qualified here. Detailed linked QoS/congestion pages could not be fetched; the retrieved project overview states the credited mechanisms. Other RINA capabilities remain separately assessed." }, { "id": "F38-PN", "feature": "F38", "stack": "PN", "status": "Y", "reason": "The author states that each PRP aggregator sees its own adjacencies and transiting clients. Each adjacency represents an interface with control-plane priority, and transiting participants can negotiate access priorities within its resource budget. Together with previously clarified autonomous adjacency scheduling, this establishes local resource administration and negotiated access/priority conditions at each aggregator without requiring a uniform policy along the complete trajectory. The architectural Yes credits independent transport scopes, not an inferred nested-domain service.", "method": "Author-attributed architectural capability; no runtime test", "source_label": "Protocol-author clarification and approved F38 reformulation, 2026-10-25", "sources": [], "editorial_references": [ "round649.html", "round649-sources.json", "round647-sources.json", "round649.html" ], "qualification": "Direct author clarification, preserved in round649-sources.json; no new normative wire or executable qualification. Negotiation operates within the available budget and accepted agreements; it does not imply that every requested priority is granted. No scheduler, numerical QoS guarantee, topology-hiding guarantee or arbitrary override of existing obligations is inferred. PRP over IP credits participating PRP aggregators and their budgets, not administrative control over unrelated IP transit infrastructure. Independent HS2 and implementation gates are unchanged." }, { "id": "F38-PI", "feature": "F38", "stack": "PI", "status": "Y", "reason": "The author states that each PRP aggregator sees its own adjacencies and transiting clients. Each adjacency represents an interface with control-plane priority, and transiting participants can negotiate access priorities within its resource budget. Together with previously clarified autonomous adjacency scheduling, this establishes local resource administration and negotiated access/priority conditions at each aggregator without requiring a uniform policy along the complete trajectory. The architectural Yes credits independent transport scopes, not an inferred nested-domain service.", "method": "Author-attributed architectural capability; no runtime test", "source_label": "Protocol-author clarification and approved F38 reformulation, 2026-10-25", "sources": [], "editorial_references": [ "round649.html", "round649-sources.json", "round647-sources.json", "round649.html" ], "qualification": "Direct author clarification, preserved in round649-sources.json; no new normative wire or executable qualification. Negotiation operates within the available budget and accepted agreements; it does not imply that every requested priority is granted. No scheduler, numerical QoS guarantee, topology-hiding guarantee or arbitrary override of existing obligations is inferred. PRP over IP credits participating PRP aggregators and their budgets, not administrative control over unrelated IP transit infrastructure. Independent HS2 and implementation gates are unchanged." }, { "id": "F38-IP", "feature": "F38", "stack": "IP", "status": "Y", "reason": "Select independently administered DiffServ domains. RFC 2475 defines boundary classification and conditioning, including policing and shaping, under domain provisioning policies and inter-domain traffic agreements. Domains can enforce their own access to service classes and resource priorities without imposing one uniform policy across the whole path.", "method": "Primary specification and implementation documentation review; no runtime experiment", "source_label": "RFC 1633, RFC 7567, RFC 2475 or IRATI Ethernet tutorial, as linked", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3" ], "editorial_references": [ "round650.html" ], "qualification": "Explicit optional IP-layer DiffServ witness, not universal default Internet service. Service-class admission is not cryptographic peer authorization. Inter-domain agreements must be compatible; no guaranteed global QoS, dynamic application reservation or added stateful firewall is inferred." }, { "id": "F38-BP", "feature": "F38", "stack": "BP", "status": "Y", "reason": "Secure DTN explicitly selects DiffServ enforcement in its existing IPv4 transport. Independent domains classify transport aggregates and apply local policing, shaping and forwarding treatment under compatible agreements.", "method": "Primary RFC review and explicit composition selection", "source_label": "IETF TCPCLv4, AQM and DiffServ specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round688.html" ], "qualification": "Applies to TCP transport aggregates, not individually visible encrypted bundles. This requires enforcement, not only marking. It does not establish application-requested reservation or BPv7/SABR priority propagation." }, { "id": "F38-CG", "feature": "F38", "stack": "CG", "status": "Y", "reason": "DTN/CGR-SABR explicitly selects DiffServ enforcement in its existing IPv4 transport. Independent domains classify transport aggregates and apply local policing, shaping and forwarding treatment under compatible agreements.", "method": "Primary RFC review and explicit composition selection", "source_label": "IETF TCPCLv4, AQM and DiffServ specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round688.html" ], "qualification": "Applies to TCP transport aggregates, not individually visible encrypted bundles. This requires enforcement, not only marking. It does not establish application-requested reservation or BPv7/SABR priority propagation." }, { "id": "F38-LT", "feature": "F38", "stack": "LT", "status": "Y", "reason": "The selected AOS layer gives local management control over the actual transmission order of virtual channels within a master channel and master channels sharing a physical channel. CCSDS 732.0-B-4 sections 4.2.5.2-3 and 4.2.6.2-3 require the multiplexers to apply management-defined ordering and project-defined algorithms considering priority, release rate and timing. The controlled resource is the local outgoing channel; the enforcement point is its frame multiplexer. Different administered links can use different scheduling policies without imposing one network-wide policy.", "method": "Normative local-resource and enforcement-point audit", "source_label": "CCSDS 732.0-B-4, October 2021, sections 4.2.5 and 4.2.6", "sources": [ "https://public.ccsds.org/Pubs/732x0b4.pdf" ], "editorial_references": [ "round708.html" ], "qualification": "Yes is architectural and restricted to the selected AOS channel-management and multiplexing functions. It does not assert a particular scheduler implementation, per-bundle fairness, cryptographic admission, distributed reservation, hard end-to-end QoS, or an integrated flight test. Project management supplies the scheduling algorithm and channel configuration. F37 congestion feedback remains separately Pending; a local transmission scheduler is not evidence of congestion observation." }, { "id": "F38-LP", "feature": "F38", "stack": "LP", "status": "Y", "reason": "Select independently administered DiffServ policies in the existing IP transport carrying libp2p. Operators classify visible transport aggregates and enforce local service-class resources using policing, shaping and forwarding treatment.", "method": "Primary QUIC/libp2p documentation and explicit IP policy selection", "source_label": "libp2p resource management, multipath-21 and IETF transport policies", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://github.com/libp2p/go-libp2p/blob/master/p2p/host/resource-manager/README.md", "https://www.rfc-editor.org/rfc/rfc9000.html#section-4" ], "editorial_references": [ "round683.html" ], "qualification": "Explicit optional IP mechanism with enforcement, not merely an endpoint preference. Different domain policies may coexist under compatible agreements. No per-stream visibility, global QoS, application reservation or change to cryptographic identity/admission is assumed." }, { "id": "F38-TO", "feature": "F38", "stack": "TO", "status": "Y", "reason": "Tor link throttling gives each participating operator control over local read and write bandwidth through token buckets. The mainline implementation additionally separates relayed-traffic budgets and applies local priority treatment to traffic classes, including directory traffic. Independently configured relays enforce these resource limits on their own connections, so different budgets and priorities can coexist along an onion-service path.", "method": "Primary Tor specification and explicitly selected IP policy review", "source_label": "Tor Specifications and RFC 7567", "sources": [ "https://spec.torproject.org/tor-spec/flow-control.html" ], "editorial_references": [ "round678.html" ], "qualification": "The transport scope is the operator-controlled Tor instance and its links. This is local resource policy, not final-client authentication, an application reservation or unrestricted freedom to violate the Tor protocol. Operators need not use identical bandwidth budgets; no global QoS guarantee or nesting requirement is inferred." }, { "id": "F38-I2", "feature": "F38", "stack": "I2", "status": "Y", "reason": "Independent operators of the IPv4 underlay carrying I2P classify transport aggregates and enforce local resource policies through DiffServ policing, shaping and forwarding classes. Different domain policies coexist under compatible agreements.", "method": "Primary specifications and explicit IP policy composition", "source_label": "IETF AQM and DiffServ; I2P and SCION transport documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.i2p.net/en/docs/specs/tunnel-implementation/" ], "editorial_references": [ "round684.html" ], "qualification": "Optional enforcement is explicit in the profile. Header marking alone is insufficient. This establishes local policy autonomy, not application-level reservation, globally guaranteed QoS or visibility into individual protected conversations." }, { "id": "F38-YG", "feature": "F38", "stack": "YG", "status": "Y", "reason": "Select DiffServ classification and conditioning on the existing private-IP peering interfaces. Each Yggdrasil node or local transport operator can administer its outgoing link resources, police or shape peering aggregates and assign service classes independently of other operators.", "method": "Primary configuration and IP service-policy review; explicit optional mechanisms", "source_label": "Project peering documentation and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [ "round680.html" ], "qualification": "Optional IP transport policy with enforcement, not merely an overlay preference. Host-side conditioners are within RFC 2475 scope. Adjacent policies must respect their agreements; no nested domains, public Internet, inner-flow visibility or end-to-end QoS guarantee is assumed." }, { "id": "F38-CJ", "feature": "F38", "stack": "CJ", "status": "Y", "reason": "Select DiffServ classification and conditioning on the existing private-IP peering interfaces. Each cjdns node or local transport operator can administer its outgoing link resources, police or shape peering aggregates and assign service classes independently of other operators.", "method": "Primary configuration and IP service-policy review; explicit optional mechanisms", "source_label": "Project peering documentation and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md" ], "editorial_references": [ "round680.html" ], "qualification": "Optional IP transport policy with enforcement, not merely an overlay preference. Host-side conditioners are within RFC 2475 scope. Adjacent policies must respect their agreements; no nested domains, public Internet, inner-flow visibility or end-to-end QoS guarantee is assumed." }, { "id": "F38-MQ", "feature": "F38", "stack": "MQ", "status": "Y", "reason": "Select independently administered DiffServ policies in the existing IP transport carrying Multipath QUIC. Operators classify visible transport aggregates and enforce local service-class resources using policing, shaping and forwarding treatment.", "method": "Primary QUIC/libp2p documentation and explicit IP policy selection", "source_label": "libp2p resource management, multipath-21 and IETF transport policies", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath-21", "https://www.rfc-editor.org/rfc/rfc9000.html#section-4" ], "editorial_references": [ "round683.html" ], "qualification": "Explicit optional IP mechanism with enforcement, not merely an endpoint preference. Different domain policies may coexist under compatible agreements. No per-stream visibility, global QoS, application reservation or change to cryptographic identity/admission is assumed." }, { "id": "F38-SC", "feature": "F38", "stack": "SC", "status": "Y", "reason": "Independent operators of the IPv4 underlay carrying SCION classify transport aggregates and enforce local resource policies through DiffServ policing, shaping and forwarding classes. Different domain policies coexist under compatible agreements.", "method": "Primary specifications and explicit IP policy composition", "source_label": "IETF AQM and DiffServ; I2P and SCION transport documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round684.html" ], "qualification": "Optional enforcement is explicit in the profile. Header marking alone is insufficient. This establishes local policy autonomy, not application-level reservation, globally guaranteed QoS or visibility into individual protected conversations." }, { "id": "F38-RT", "feature": "F38", "stack": "RT", "status": "Y", "reason": "Each Reticulum interface can independently configure its announce bandwidth cap. Interface.process_announce_queue enforces spacing from packet size, interface bitrate and that cap, selects lower-hop announcements first and discards stale queued entries. Local operators therefore enforce different resource policies on connected transport scopes.", "method": "Versioned native source and official API review", "source_label": "Reticulum 1.5.5 and selected Meshtastic firmware source", "sources": [ "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Interfaces/Interface.py", "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Resource.py", "https://reticulum.network/manual/reference.html" ], "editorial_references": [ "round686.html" ], "qualification": "Witness is native announcement traffic on serial transport interfaces, not arbitrary per-application data reservations. Configuration must reflect the interface bitrate. Independent per-interface enforcement satisfies the criterion without requiring recursive RINA scopes or a network-wide uniform budget." }, { "id": "F38-NS", "feature": "F38", "stack": "NS", "status": "Y", "reason": "Explicitly select independently administered DiffServ domains in the IPv4 transport. Domain operators classify and condition traffic at their boundaries and enforce service-class resources through policing, shaping and per-hop treatment. Compatible inter-domain agreements allow different local policies along the WebSocket path.", "method": "Primary protocol review with explicit native IP policy selection", "source_label": "NIP-01 and IETF transport service architecture", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3" ], "editorial_references": [ "round677.html" ], "qualification": "Optional IP-layer composition witness, not uniform Internet deployment or a Nostr relay QoS guarantee. Classification can use the transport aggregate without inspecting TLS-encrypted events. Service-class access is not cryptographic author authorization, and this supplies no application reservation exchange." }, { "id": "F38-MT", "feature": "F38", "stack": "MT", "status": "Y", "reason": "Each node enforces local packet-access decisions through its ignore policy, and its transmission queue orders packets by local priority and can evict lower-priority entries when full. Local clients can supply priority; unset values are assigned by local firmware. Operators can apply their own access policies while interoperating with neighboring nodes.", "method": "Pinned firmware schema, queue and router source review", "source_label": "Meshtastic firmware 8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/MeshPacketQueue.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/MeshPacketQueue.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/mesh.pb.h" ], "editorial_references": [ "round687.html" ], "qualification": "Native node/radio scope, not recursively nested domains or negotiated end-to-end bandwidth. Compatible radio settings and trust provisioning remain required. A local priority value is not propagated as a binding policy for other relays. Ignoring a sender prevents local handling, not reception energy consumption or RF interference." }, { "id": "F38-GN", "feature": "F38", "stack": "GN", "status": "Y", "reason": "Each GNUnet operator configures local ATS network-scope bandwidth budgets. The selected proportional allocator admits addresses within these budgets and apportions resources by application bandwidth preferences. TRANSPORT sends the locally assigned outbound quota to its clients; transport_api_core updates a per-neighbour bandwidth tracker and delays subsequent messages when the quota is exhausted. CORE also schedules according to message priority and available bandwidth. Operators can enforce different budgets and priorities at adjacent relay scopes without a uniform network-wide policy.", "method": "Selected-version source path and documentary plausibility", "source_label": "GNUnet 0.20.0 CORE, legacy TRANSPORT and proportional ATS", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/ats/ats.html", "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round706.html" ], "qualification": "Yes concerns operator-controlled local admission to budgeted peer transport and outbound scheduling, not authority over remote resources or a hard end-to-end agreement. The selected source ignores remote receive-quota announcements (IGNORE_INBOUND_QUOTA); remote-quota enforcement is explicitly not credited. Locally assigned outbound quota enforcement remains active. Trusted local services, correct configured budgets and the declared proportional ATS composition are assumed. No runtime or adversarial-client isolation test." }, { "id": "F38-ND", "feature": "F38", "stack": "ND", "status": "?", "reason": "Not yet assessed under the revised independent transport-scope policy criterion. Adjacent and nested scopes are both eligible; the former requirement for nested domains and hidden internal organization no longer applies.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify independently administered transport scopes, local access/priority policy and resource enforcement. Explain how different local conditions can coexist along a communication. Do not require nesting, topology abstraction or RINA-style layers. Distinguish local policy authority from the ability merely to request QoS." }, { "id": "F38-AX", "feature": "F38", "stack": "AX", "status": "?", "reason": "Not yet assessed under the revised independent transport-scope policy criterion. Adjacent and nested scopes are both eligible; the former requirement for nested domains and hidden internal organization no longer applies.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify independently administered transport scopes, local access/priority policy and resource enforcement. Explain how different local conditions can coexist along a communication. Do not require nesting, topology abstraction or RINA-style layers. Distinguish local policy authority from the ability merely to request QoS." }, { "id": "F38-BA", "feature": "F38", "stack": "BA", "status": "?", "reason": "Not yet assessed under the revised independent transport-scope policy criterion. Adjacent and nested scopes are both eligible; the former requirement for nested domains and hidden internal organization no longer applies.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify independently administered transport scopes, local access/priority policy and resource enforcement. Explain how different local conditions can coexist along a communication. Do not require nesting, topology abstraction or RINA-style layers. Distinguish local policy authority from the ability merely to request QoS." }, { "id": "F38-BL", "feature": "F38", "stack": "BL", "status": "Y", "reason": "Select independently administered DiffServ policies in the existing IPv6 forwarding interfaces of the Babel-routed network. Domain/interface owners classify, police and shape traffic and enforce local service-class resource priorities. These policies operate on the existing local links and do not change the selected hierarchy or routing filters.", "method": "Primary RFC review and explicit optional IP transport policy selection", "source_label": "HIP/Babel specifications and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round682.html" ], "qualification": "Optional transport policy with actual conditioning/enforcement selected, not marking alone. Compatible inter-domain agreements remain necessary. This does not provide application reservation, global QoS or new cryptographic authorization." }, { "id": "F38-RI", "feature": "F38", "stack": "RI", "status": "?", "reason": "Not yet assessed under the revised independent transport-scope policy criterion. Adjacent and nested scopes are both eligible; the former requirement for nested domains and hidden internal organization no longer applies.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "Evaluation queued", "sources": [], "editorial_references": [ "round645.html" ], "qualification": "Identify independently administered transport scopes, local access/priority policy and resource enforcement. Explain how different local conditions can coexist along a communication. Do not require nesting, topology abstraction or RINA-style layers. Distinguish local policy authority from the ability merely to request QoS." }, { "id": "F38-HP", "feature": "F38", "stack": "HP", "status": "Y", "reason": "Select independently administered DiffServ policies in the IP forwarding layer carrying HIP control and ESP-protected user traffic. Domain/interface owners classify, police and shape traffic and enforce local service-class resource priorities. ESP payload decryption is unnecessary for classification of the visible transport aggregate.", "method": "Primary RFC review and explicit optional IP transport policy selection", "source_label": "HIP/Babel specifications and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html#section-3" ], "editorial_references": [ "round682.html" ], "qualification": "Optional transport policy with actual conditioning/enforcement selected, not marking alone. Compatible inter-domain agreements remain necessary. This does not provide application reservation, global QoS or new cryptographic authorization." }, { "id": "F38-CX", "feature": "F38", "stack": "CX", "status": "Y", "reason": "CCNx forwarders can enforce local ACLs on name prefixes and incoming interfaces, refusing prohibited Interests independently and optionally reporting Prohibited to the preceding hop.", "method": "Primary packet semantics and forwarding-policy review", "source_label": "NDN packet format v0.3 and CCNx RFC 8569", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-10.3.6" ], "editorial_references": [ "round689.html" ], "qualification": "Native local access enforcement under section 10.3.6; not identity authentication, bandwidth reservation or globally uniform policy. Neighboring policies must permit the intended traffic." }, { "id": "F38-LI", "feature": "F38", "stack": "LI", "status": "Y", "reason": "Select independently administered DiffServ domains in the outer IPv4 transport carrying LISP encapsulation. Each domain enforces its own service-class resources through classification, policing, shaping and forwarding treatment. RFC 9300 specifies DSCP handling at encapsulation/decapsulation; domains can condition the outer packets.", "method": "Primary RFC review with explicit optional transport mechanisms", "source_label": "RFC 9300/6741 and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc9300.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round681.html" ], "qualification": "Explicit optional transport policy, with compatible inter-domain agreements. Marking alone is not the evidence: local conditioning and resource enforcement are selected. No global QoS guarantee, application reservation or cryptographic access control is inferred." }, { "id": "F38-IL", "feature": "F38", "stack": "IL", "status": "Y", "reason": "Select independently administered DiffServ domains in the IPv6-compatible ILNPv6 forwarding plane, whose core routers route on Locator prefixes. Each domain enforces its own service-class resources through classification, policing, shaping and forwarding treatment. RFC 6741 retains the Traffic Class field and compatibility with deployed IPv6 routers; no additional tunnel is introduced.", "method": "Primary RFC review with explicit optional transport mechanisms", "source_label": "RFC 9300/6741 and RFC 7567/2475", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc6741.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc1633.html#section-5" ], "editorial_references": [ "round681.html" ], "qualification": "Explicit optional transport policy, with compatible inter-domain agreements. Marking alone is not the evidence: local conditioning and resource enforcement are selected. No global QoS guarantee, application reservation or cryptographic access control is inferred." }, { "id": "F38-TS", "feature": "F38", "stack": "TS", "status": "Y", "reason": "Explicitly select independently administered DiffServ domains in the outer IP transport. Each domain can classify, police and shape the tunnel or relay-connection aggregate and assign its own forwarding treatment within compatible inter-domain agreements. Enforcement uses domain-controlled resources rather than requiring uniform tailnet policy to manage the entire transport path.", "method": "Primary Tailscale documentation and explicitly selected IP policy review", "source_label": "Tailscale grants and IETF transport policy architecture", "sources": [ "https://www.rfc-editor.org/rfc/rfc2475.html#section-2.3" ], "editorial_references": [ "round679.html" ], "qualification": "Optional underlay witness, separate from Tailscale grants and cryptographic peer admission. Outer aggregate classification requires no decryption or propagation of inner DSCP markings. It does not promise per-application treatment inside a tunnel, public DERP provisioning or global QoS." }, { "id": "F38-RA", "feature": "F38", "stack": "RA", "status": "Y", "reason": "A DIF provides communication to upper processes, which can themselves implement a wider DIF. Routing, transport and management policies belong to each scope, with internal addressing hidden from applications. Reassessment under revised F38: per-DIF administration and resource policies supply independent local transport conditions. Recursive nesting remains the RINA mechanism, not a requirement imposed on other columns.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://csr.bu.edu/rina/about.html", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Documentary architectural credit for the declared RINA composition. IRATI is a reference implementation, but no release, policy configuration, executable integration or performance result is qualified here. Detailed linked QoS/congestion pages could not be fetched; the retrieved project overview states the credited mechanisms. Other RINA capabilities remain separately assessed." }, { "id": "F39-PN", "feature": "F39", "stack": "PN", "status": "Y", "reason": "The protocol author states that PRP endpoints are processes and use the same identity and topological-path abstraction for IPC on the same machine or across machines. Local delivery and remote transport are selected beneath that application abstraction.", "method": "Architectural mechanism and primary-source review; author declarations explicitly attributed", "source_label": "Protocol author clarification: local and remote IPC", "sources": [], "editorial_references": [ "round690.html", "round690.html" ], "qualification": "Architectural Yes based on the protocol author clarification accepted for this criterion. Local zero-copy is a possible implementation optimization, not a measured or verified property. No executable local/remote equivalence test is asserted." }, { "id": "F39-PI", "feature": "F39", "stack": "PI", "status": "Y", "reason": "The protocol author states that PRP endpoints are processes and use the same identity and topological-path abstraction for IPC on the same machine or across machines. Local delivery and remote transport are selected beneath that application abstraction.", "method": "Architectural mechanism and primary-source review; author declarations explicitly attributed", "source_label": "Protocol author clarification: local and remote IPC", "sources": [], "editorial_references": [ "round690.html", "round690.html" ], "qualification": "Architectural Yes based on the protocol author clarification accepted for this criterion. Local zero-copy is a possible implementation optimization, not a measured or verified property. No executable local/remote equivalence test is asserted." }, { "id": "F39-IP", "feature": "F39", "stack": "IP", "status": "N", "reason": "The selected IP-only service addresses interfaces and delivers datagrams; it supplies no logical process-reference and IPC service independent of host addressing. Ordinary IP local delivery does not add that missing abstraction.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc4291.html#section-2.1", "https://www.rfc-editor.org/rfc/rfc8200.html#section-3" ], "editorial_references": [ "round691.html" ], "qualification": "No TCP/UDP application service or naming layer is selected. The verdict does not deny loopback or delivery to an address assigned to the same host; it concerns the full F39 application contract." }, { "id": "F39-BP", "feature": "F39", "stack": "BP", "status": "Y", "reason": "BPv7 transmission uses a destination EID. Dispatch delivers to a locally registered endpoint or forwards through a convergence layer; the application uses the same bundle service in both cases.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.3" ], "editorial_references": [ "round691.html" ], "qualification": "Architectural BP-layer credit, including asynchronous IPC. Routing and convergence-layer choices remain beneath this interface; complete composition testing and zero-copy are not claimed." }, { "id": "F39-CG", "feature": "F39", "stack": "CG", "status": "Y", "reason": "BPv7 transmission uses a destination EID. Dispatch delivers to a locally registered endpoint or forwards through a convergence layer; the application uses the same bundle service in both cases.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.3" ], "editorial_references": [ "round691.html" ], "qualification": "Architectural BP-layer credit, including asynchronous IPC. Routing and convergence-layer choices remain beneath this interface; complete composition testing and zero-copy are not claimed." }, { "id": "F39-LT", "feature": "F39", "stack": "LT", "status": "Y", "reason": "BPv7 transmission uses a destination EID. Dispatch delivers to a locally registered endpoint or forwards through a convergence layer; the application uses the same bundle service in both cases.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc9171.html#section-3.3" ], "editorial_references": [ "round691.html" ], "qualification": "Architectural BP-layer credit, including asynchronous IPC. Routing and convergence-layer choices remain beneath this interface; complete composition testing and zero-copy are not claimed." }, { "id": "F39-LP", "feature": "F39", "stack": "LP", "status": "Y", "reason": "The application opens a stream using a Peer ID and protocol ID. BasicHost resolves the peer through its peerstore and network dialer. The selected QUIC transport supports distinct peers on the same machine using loopback, and peers on different machines, beneath that same stream interface.", "method": "Primary documentation, pinned source and explicit architectural composition; no runtime test", "source_label": "Peer-ID stream API and identity-derived virtual-address delivery", "sources": [ "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/host/basic/basic_host.go", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/transport/quic/conn_test.go" ], "editorial_references": [ "round692.html" ], "qualification": "Source-supported composition: provision the known peer addresses in the peerstore, including a usable local address for a co-resident peer. BasicHost.NewStream accepts only the logical peer reference; transport setup remains below that call. The v0.50.0 TestStreams fixture exercises QUIC loopback transport, but was inspected rather than executed here. No special shared-memory IPC, zero-copy, self-dial to the same peer identity or process-migration claim." }, { "id": "F39-TO", "feature": "F39", "stack": "TO", "status": "N", "reason": "The selected onion-service composition uses introduction and rendezvous circuits followed by relay streams. Its onion name abstracts location, but the specified path does not select host-local delivery when the client and service are co-resident. The final connection to the service process is not a substitute for that missing local-path selection.", "method": "Primary onion-service protocol path; selected-composition assessment", "source_label": "Tor v3 rendezvous specification, protocol overview", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [ "round697.html" ], "qualification": "No applies to the complete F39 criterion, not to the ability of co-resident applications to communicate through Tor. Directly connecting to the backend would require a different endpoint reference or an extra dispatch mechanism. No such mechanism is selected here. This is a specification-based assessment, not a runtime test or a claim about every possible Tor extension." }, { "id": "F39-I2", "feature": "F39", "stack": "I2", "status": "Y", "reason": "Java I2P ClientManager.distributeMessage looks up the receiving Destination among connected clients. For another local client it invokes DistributeLocal and receiveMessage; otherwise it submits the message to the remote client-message path. Applications keep the Destination reference and I2CP/streaming interface when the peer is local or remote.", "method": "Pinned primary implementation: local destination dispatch and remote fallback", "source_label": "Java I2P 2.6.0 ClientManager.distributeMessage / DistributeLocal; ClientMessagePool.add", "sources": [ "https://github.com/i2p/i2p.i2p/blob/63326dc48b954fcaceae544daa57d9dd9a0c6f4d/router/java/src/net/i2p/router/client/ClientManager.java", "https://github.com/i2p/i2p.i2p/blob/63326dc48b954fcaceae544daa57d9dd9a0c6f4d/router/java/src/net/i2p/router/ClientMessagePool.java", "https://github.com/i2p/i2p.website/blob/main/content/en/docs/api/streaming.md" ], "editorial_references": [ "round698.html" ], "qualification": "Source-level architectural credit for distinct clients sharing one router, not sending to the same client connection, which the code rejects. The local router is trusted with this delivery; local and tunneled cryptographic protection are not asserted equivalent. No runtime test, zero-copy, automatic sharing across isolated routers, or post-quantum qualification follows. Other criterion-specific compositions remain unchanged." }, { "id": "F39-YG", "feature": "F39", "stack": "YG", "status": "Y", "reason": "The selected UDP application uses the identity-derived Yggdrasil IPv6 address and service port. That virtual address is independent of the physical peering address. A destination assigned to the local host is delivered by its local IP route; another node is reached through the TUN interface and Yggdrasil routing, without changing the application reference format or UDP API.", "method": "Primary documentation, pinned source and explicit architectural composition; no runtime test", "source_label": "Peer-ID stream API and identity-derived virtual-address delivery", "sources": [ "https://yggdrasil-network.github.io/implementation.html", "https://man7.org/linux/man-pages/man8/ip-route.8.html" ], "editorial_references": [ "round692.html" ], "qualification": "Constructive architectural assessment for ordinary local-host UDP sockets and the selected native-node address profile. The service must bind the virtual address or wildcard, and local policy must permit it. This is node identity plus service port, not a separate cryptographic identity for each process. No process migration, local cryptographic isolation, zero-copy or newly executed runtime test is claimed." }, { "id": "F39-CJ", "feature": "F39", "stack": "CJ", "status": "Y", "reason": "The selected UDP application addresses a cjdns key-derived IPv6 endpoint and service port, independently of its underlay locator. Ordinary host routing delivers a locally assigned virtual address locally; a remote virtual address goes through the cjdns TUN and key-based routing. The same logical endpoint form and UDP interface cover both cases.", "method": "Primary documentation, pinned source and explicit architectural composition; no runtime test", "source_label": "Peer-ID stream API and identity-derived virtual-address delivery", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md", "https://man7.org/linux/man-pages/man8/ip-route.8.html" ], "editorial_references": [ "round692.html" ], "qualification": "Constructive architectural assessment for the declared native cjdns-node addresses, not devices behind imported IP tunnels. Bind the service to the virtual address or wildcard and allow it in local policy. The identity belongs to the node; the port distinguishes its service. Local delivery need not traverse CryptoAuth, and no local security equivalence, zero-copy, process migration or runtime certification is inferred." }, { "id": "F39-MQ", "feature": "F39", "stack": "MQ", "status": "N", "reason": "The selected QUIC composition initiates communication with numeric IP/UDP endpoints. Connection IDs preserve an existing connection across path changes; they are not a logical peer discovery and local/remote IPC naming service.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-5.1", "https://www.rfc-editor.org/rfc/rfc9000.html#section-7" ], "editorial_references": [ "round691.html" ], "qualification": "Local QUIC communication is possible. The missing element is the full location-independent application reference, not a requirement for shared memory or bypassing the network stack. Multipath does not supply that naming layer." }, { "id": "F39-SC", "feature": "F39", "stack": "SC", "status": "N", "reason": "The selected SCION/UDP application endpoint includes the destination ISD-AS, host address and UDP port. Path selection and the optional reservation service do not replace that location-bearing endpoint with a logical process reference for transparent local and remote IPC.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round691.html" ], "qualification": "Intra-AS and same-host communication are not denied. No additional service-name or IPC abstraction is selected. The verdict applies to this declared numeric-endpoint composition." }, { "id": "F39-RT", "feature": "F39", "stack": "RT", "status": "Y", "reason": "Reticulum applications use destination identities and the Link API for both co-resident and remote applications. Native shared-instance clients connect through Unix-domain sockets; the transport routes between local client interfaces or the configured serial network beneath the same application interface.", "method": "Official manual and version-pinned native local-interface source review", "source_label": "Reticulum 1.5.5 native shared-instance transport", "sources": [ "https://reticulum.network/manual/using.html", "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Interfaces/LocalInterface.py", "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round694.html" ], "qualification": "Explicit optional native profile selected for F39. Reticulum 1.5.5 LocalInterface.py creates AF_UNIX clients/listeners and registers local_client_interfaces; Transport.py handles their destination paths and forwarding. The shared instance and applications need a compatible configuration and permissions. The earlier standalone C08 witness remains separate. No local TCP, external broker, LXMF layer, zero-copy, runtime test or security-equivalence claim is introduced." }, { "id": "F39-NS", "feature": "F39", "stack": "NS", "status": "Y", "reason": "NIP-01 provides live event publication and subscriptions by author key. The selected relay broadcasts accepted events internally, matches each connection subscription, and writes to that subscriber WebSocket. With the relay and applications co-resident, this is local publish/subscribe IPC; a remote subscriber uses the same author reference and subscription through its network connection.", "method": "Native pub/sub specification, pinned relay dispatch and host-local IP delivery", "source_label": "NIP-01 EVENT/REQ author subscriptions; nostr-rs-relay server.rs and subscription.rs; Linux local routes", "sources": [ "https://github.com/scsibug/nostr-rs-relay/blob/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/server.rs", "https://github.com/scsibug/nostr-rs-relay/blob/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/src/subscription.rs", "https://github.com/nostr-protocol/nips/blob/master/01.md", "https://man7.org/linux/man-pages/man8/ip-route.8.html" ], "editorial_references": [ "round699.html" ], "qualification": "Yes is bounded to native relay-mediated publish/subscribe and the explicitly co-hosted relay leg. Provisioning the relay endpoint is required; applications do not encode the publishing peer physical location. Use a newly published event after subscription so the witness is live communication, not retrieval of an old stored event. No direct connection, request/reply protocol, confidentiality, exactly-once delivery, zero-copy or runtime validation is claimed. A deployment using only off-host relays does not supply this local-delivery witness." }, { "id": "F39-MT", "feature": "F39", "stack": "MT", "status": "Y", "reason": "Router.sendLocal checks the destination node number: a local destination goes to deliverLocal, while a remote destination goes to send and the radio interface. MeshModule.callModules dispatches the received packet to the selected application port. With native meshtasticd, a separate local client reaches the daemon-hosted service or a remote node service through the same Client API and node/port reference.", "method": "Pinned native daemon entry point, API server, local/radio dispatch and module port delivery", "source_label": "Meshtastic native meshtasticd; Router.sendLocal; MeshModule.callModules; ServerAPI; NodeInfoModule", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/main.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/MeshModule.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/api/ServerAPI.h", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/NodeInfoModule.cpp", "https://meshtastic.org/docs/development/device/client-api/", "https://meshtastic.org/docs/development/device/module-api/", "https://meshtastic.org/docs/meshtasticd/" ], "editorial_references": [ "round700.html" ], "qualification": "Source-based Yes for a client process communicating with a service hosted inside the native daemon. This is not arbitrary OS-process registration or a guarantee of multiple concurrent external clients; the API server documents a single active TCP connection. Module callbacks are not counted as separate processes. The local API is trusted and does not imply identical local/remote cryptographic protection. Keep service policies and throttles; no zero-copy, runtime test or new production qualification of the selected Alpha is claimed." }, { "id": "F39-GN", "feature": "F39", "stack": "GN", "status": "Y", "reason": "CADET channels address a peer identity and service port. GNUnet 0.20.0 GCCH_channel_local_new compares the destination with the local peer identity: it binds a loopback channel to the local listening client or obtains a remote tunnel using the same channel request.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round691.html" ], "qualification": "Source inspection of src/cadet/gnunet-service-cadet_channel.c, lines 659-720, from the previously retained 0.20.0 source. Local service registration is required. This credits the native channel capability, not permission to bypass admission; the separate F16 no-listening-port configuration remains scoped to F16. No runtime or zero-copy claim." }, { "id": "F39-ND", "feature": "F39", "stack": "ND", "status": "Y", "reason": "A producer registers a name prefix and receives matching Interests through its application face; the consumer expresses an Interest by name and receives Data through the same API. NFD prefix routing selects a local Unix-socket producer face or a remote Ethernet path. The consumer does not name the producer host or change its IPC interface.", "method": "Primary application API, forwarding documentation and pinned source; bounded architectural witness", "source_label": "NDN prefix registration and CCNx named forwarding", "sources": [ "https://docs.named-data.net/ndn-cxx/current/examples.html", "https://docs.named-data.net/NFD/current/manpages/nfdc-route.html", "https://docs.named-data.net/NDN-packet-spec/current/interest.html" ], "editorial_references": [ "round695.html" ], "qualification": "Bounded request/reply IPC with a single producer for the chosen prefix and a cache miss. Use a globally scoped prefix such as /example/testApp, not the special /localhost scope. The official examples contain a /localhost prose label but the shown code uses /example and appends a version. MustBeFresh alone does not ensure contact with a live producer. No guarantee of arbitrary process addressing, fresh execution, exactly-once effects, duplex sessions, zero-copy or runtime conformance is claimed." }, { "id": "F39-AX", "feature": "F39", "stack": "AX", "status": "Y", "reason": "Linux NET/ROM connects using a destination callsign/SSID through AF_NETROM. nr_route_frame detects a locally assigned destination and queues locally originated traffic for loopback; otherwise it selects the remote node route. nr_rx_frame finds the listening socket by the same destination callsign.", "method": "Primary specifications, pinned source and explicit local-delivery composition; no runtime test", "source_label": "NET/ROM local dispatch, LISP EID separation and Tailscale Linux address assignment", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/nr_route.c", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/nr_loopback.c" ], "editorial_references": [ "round693.html" ], "qualification": "Linux v6.12 source-supported capability. A configured callsign/SSID must identify the intended listening service; UID/callsign and device provisioning remain administrative. This does not provide arbitrary per-process cryptographic identities or unlimited service multiplexing. Native circuit handling serves local and remote clients without an added BBS or IP service. No radio deployment, executable test or zero-copy claim." }, { "id": "F39-BA", "feature": "F39", "stack": "BA", "status": "N", "reason": "batman-adv exposes a virtual Ethernet switch and bridges frames. The selected L2-only composition has no application IPC service or logical process references for local and remote delivery.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://docs.kernel.org/networking/batman-adv.html" ], "editorial_references": [ "round691.html" ], "qualification": "Additional protocols can be carried over this bridge, but are not part of this column. A virtual shared link is distinct from a common process communication abstraction." }, { "id": "F39-BL", "feature": "F39", "stack": "BL", "status": "N", "reason": "Babel supplies routes for the selected numeric-address IPv6 datagram service. It does not add a logical process-reference API that hides local versus remote host addressing.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html", "https://www.rfc-editor.org/rfc/rfc4291.html#section-2.1" ], "editorial_references": [ "round691.html" ], "qualification": "Locally routed IPv6 packets remain possible. No application transport or process-naming service is selected; control-plane routing alone does not meet F39." }, { "id": "F39-RI", "feature": "F39", "stack": "RI", "status": "N", "reason": "The selected RPL/IPv6/UDP/DTLS composition uses numeric peer addresses and transport ports. RPL computes network routes; DTLS protects the exchange. Neither adds location-independent process naming and local-versus-remote IPC selection.", "method": "Primary specifications and retained implementation-source review; no runtime test", "source_label": "Native IPC naming, local dispatch and selected service boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc768.html" ], "editorial_references": [ "round691.html" ], "qualification": "The same UDP API can carry local or remote traffic, but the caller still supplies a host-addressed endpoint. This is not a denial of loopback. No CoAP naming, broker or extra IPC wrapper is selected." }, { "id": "F39-HP", "feature": "F39", "stack": "HP", "status": "Y", "reason": "RFC 5338 describes assigning HITs to internal virtual interfaces and using them in ordinary socket calls, binding services to a selected HIT, and applications connecting to a local HIT. The same HIT-and-port reference addresses a co-resident service or a remote host service while the HIP layer handles remote locators.", "method": "Primary RFC application and socket semantics; explicit local-HIT case", "source_label": "RFC 5338 section 5; HIPv2 identity/locator separation", "sources": [ "https://datatracker.ietf.org/doc/html/rfc5338#section-5", "https://www.rfc-editor.org/rfc/rfc7401.html", "https://datatracker.ietf.org/doc/html/rfc6317#section-4.1.1" ], "editorial_references": [ "round696.html" ], "qualification": "Architectural/documentary credit based on the explicit local-HIT case, not a newly executed HIPv2 deployment. Use the chosen local HIT for UDP replies as well as requests to avoid the documented wildcard/multiple-HIT ambiguity. RFC 5338 permits relaxed local security processing; this does not assert identical local/remote protection or change the selected remote ESP suite. No zero-copy, process migration or independent per-process key ownership is required or claimed." }, { "id": "F39-CX", "feature": "F39", "stack": "CX", "status": "Y", "reason": "A CCNx Interest names the requested producer service data independently of its host. With the prefix bound to one producer and no cached match, Athena resolves the name through its FIB and sends to the selected local or remote UDP link; the response follows pending-Interest state. The application retains the same named request/reply exchange.", "method": "Primary application API, forwarding documentation and pinned source; bounded architectural witness", "source_label": "NDN prefix registration and CCNx named forwarding", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-3", "https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena.c", "https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_FIB.c", "https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_TransportLinkModuleUDP.c" ], "editorial_references": [ "round695.html" ], "qualification": "Architectural and pinned-source witness, not an executed application deployment. Athena _processInterest checks the cache then uses athenaFIB_Lookup and the transport adapter; its UDP module distinguishes local links. The configured prefix denotes one producer service in this witness. A cached Content Object alone does not establish live IPC, and no generic RPC, arbitrary duplex stream, exactly-once semantics, zero-copy or producer-process authentication is inferred." }, { "id": "F39-LI", "feature": "F39", "stack": "LI", "status": "Y", "reason": "The selected UDP application addresses an EID and port. LISP keeps EIDs separate from underlay RLOCs; the application does not select the remote tunnel endpoint. A locally assigned EID follows ordinary local delivery, while remote delivery uses the configured EID routing and EID-to-RLOC mapping beneath the same UDP interface.", "method": "Primary specifications, pinned source and explicit local-delivery composition; no runtime test", "source_label": "NET/ROM local dispatch, LISP EID separation and Tailscale Linux address assignment", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-3", "https://www.rfc-editor.org/rfc/rfc9300.html#section-4", "https://man7.org/linux/man-pages/man8/ip-route.8.html" ], "editorial_references": [ "round693.html" ], "qualification": "Architectural composition of RFC 9300 with ordinary host local delivery. EIDs remain provisioned host addresses and may have site-local subnet structure; they are not process keys or a promise of transparent process migration. The service binds its EID or wildcard and policy permits access. No executable LISP integration or local security-equivalence test is claimed." }, { "id": "F39-IL", "feature": "F39", "stack": "IL", "status": "Y", "reason": "RFC 6741 preserves the socket API for applications using logical names and separates transport identifiers from locators. The public ILNP implementation explicitly handles reception from its own identifier as loopback in ilnp6_rcv. Its address configuration installs host-local routes using the loopback device, while TCP retains the ordinary connect and receive interface. Together these support local and remote IPC through the same participant-name/service-port abstraction.", "method": "Architectural inference from RFC socket/name semantics and pinned explicit ILNP local-reception path", "source_label": "RFC 6741 sections 10.5 and 14; ilnp-public-1 ilnp6_rcv, addrconf_dst_alloc and TCP socket path", "sources": [ "https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/ilnp6.c", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/route.c", "https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/tcp_ipv6.c", "https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/ip6_input.c", "https://ilnp.github.io/ilnp-public-1/" ], "editorial_references": [ "round701.html" ], "qualification": "Architectural Yes inferred from the RFC application model and explicit source mechanisms, not a newly executed local TCP session or validation of every prototype code path. The service vector must be assigned locally and recognized by the ILNP stack; resolver and ILCC prerequisites remain. No numeric localhost substitution, ordinary IPv6 fallback, migration of a running process, zero-copy or production-readiness claim is used as the witness. The historical prototype is supporting evidence, not a replacement for the selected RFC profile." }, { "id": "F39-TS", "feature": "F39", "stack": "TS", "status": "Y", "reason": "The standard Linux TUN client assigns the node a stable tailnet address independently of its physical network address. A socket service at that virtual address and port can be reached locally through host routing or remotely through Tailscale using the same endpoint reference and socket interface.", "method": "Primary specifications, pinned source and explicit local-delivery composition; no runtime test", "source_label": "NET/ROM local dispatch, LISP EID separation and Tailscale Linux address assignment", "sources": [ "https://tailscale.com/kb/1033/ip-and-dns-addresses", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/router/osrouter/router_linux.go", "https://man7.org/linux/man-pages/man8/ip-route.8.html" ], "editorial_references": [ "round693.html" ], "qualification": "Documentary and pinned-source composition for the selected standard Linux TUN mode, not tsnet. router_linux.go reconciles LocalAddrs and assigns them to the TUN interface; normal local IP delivery supplies the co-resident path. The service must bind the virtual address or wildcard. Address stability lasts while registration is retained and the administrator does not change it. Node-plus-port naming is credited, not per-process cryptographic identity, local WireGuard traversal, grant enforcement equivalence, zero-copy or runtime certification." }, { "id": "F39-RA", "feature": "F39", "stack": "RA", "status": "Y", "reason": "RINA models networking as IPC and hides internal addresses behind application names and flow allocation. In the pinned IRATI flow allocator, a remote destination receives a CDAP flow-create request; a destination registered at the same IPC process is passed directly to the local flow allocator under the same flow-allocation operation.", "method": "Architectural mechanism and primary-source review; author declarations explicitly attributed", "source_label": "RINA architecture and pinned IRATI flow allocator", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc", "https://csr.bu.edu/rina/about.html", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc" ], "editorial_references": [ "round690.html" ], "qualification": "Architectural documentation and pinned implementation branches support the common abstraction. No runtime equivalence, zero-copy optimization or performance measurement was executed. IRATI remains the selected implementation reference." }, { "id": "C01-PN", "feature": "C01", "stack": "PN", "status": "Y", "reason": "PRP separates participant identity from volatile carrier locators and paths. Lifecycle sections 3.1/3.4 and 7 permit multiple eligible paths and authenticated replacement bound to the existing relationship. A destination can therefore retain its participant identity reference while traffic uses an authorized path through another attachment after the original becomes unavailable.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "Pinned architecture/lifecycle source and ILNP experimental RFCs", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-relationship-lifecycle-v1.md" ], "editorial_references": [ "round489-sources.json", "round489.html", "round489-sources.json" ], "qualification": "Architectural witness: the same destination identity reference, two usable authorized destination attachments, and an alternative path acquired and validated before the old path fails. No replacement application address, external name redirection or changed participant identity is required. Route selectors and trajectories may change. This does not prove discovery after all paths disappear, simultaneous movement, arbitrary filtering immunity or a carrier-specific handover implementation. The current worktree is pinned for semantic evidence; no new wire/HS2 integration acceptance is inferred." }, { "id": "C01-PI", "feature": "C01", "stack": "PI", "status": "Y", "reason": "PRP separates participant identity from volatile carrier locators and paths. Lifecycle sections 3.1/3.4 and 7 permit multiple eligible paths and authenticated replacement bound to the existing relationship. A destination can therefore retain its participant identity reference while traffic uses an authorized path through another attachment after the original becomes unavailable.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "Pinned architecture/lifecycle source and ILNP experimental RFCs", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-relationship-lifecycle-v1.md" ], "editorial_references": [ "round489-sources.json", "round489.html", "round489-sources.json" ], "qualification": "Architectural witness: the same destination identity reference, two usable authorized destination attachments, and an alternative path acquired and validated before the old path fails. No replacement application address, external name redirection or changed participant identity is required. Route selectors and trajectories may change. This does not prove discovery after all paths disappear, simultaneous movement, arbitrary filtering immunity or a carrier-specific handover implementation. The changed UDP/IP locator is a carrier locator, not the stable PRP destination reference; the new IP attachment must itself be reachable. The current worktree is pinned for semantic evidence; no new wire/HS2 integration acceptance is inferred." }, { "id": "C01-IP", "feature": "C01", "stack": "IP", "status": "Y", "reason": "A bounded native IPv4 configuration can keep one destination address reachable after its old final attachment fails. Assign the private /32 to a persistent logical host interface, provision two physical access paths and host routes to that same /32, and use weak-host receive semantics. When the old access is lost, the routing administrator selects the surviving path; datagrams still carry the original destination address and arrive through the other physical interface.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 1122 weak-host semantics, configured IPv4 routes and Babel local-route origination", "sources": [ "https://www.rfc-editor.org/rfc/rfc1122.html#section-3.3.4.2", "https://www.rfc-editor.org/rfc/rfc1812.html#section-7.4", "https://docs.kernel.org/6.12/networking/ip-sysctl.html" ], "editorial_references": [ "round536.html", "round536-sources.json" ], "qualification": "This is an infrastructure-administered, preprovisioned witness, not ordinary subscriber address portability. Both paths must deliver to the same host, whose address remains assigned; routers need authorized host routes and a usable return path. The selected private deployment permits these local routes. No BGP capability is assigned to an unprivileged endpoint, and no global provider-independent /32 advertisement is assumed. Route replacement can be administrative; automatic failure detection, seamless sessions and a recovery deadline are not credited. Weak-host behavior is permitted rather than required by RFC 1122 and is documented by Linux; strong-host or filtering configurations can reject the alternate ingress. This is final-attachment recovery, not merely BGP transit repair. No Mobile IP, tunnel, DNS or application redirection. No runtime experiment; F23 is unchanged." }, { "id": "C01-BP", "feature": "C01", "stack": "BP", "status": "Y", "reason": "A singleton bundle destination can keep its EID and NODE-ID credentials while replacing its IP attachment. A bounded witness uses TCPCL active-only polling: after losing the old access, the destination establishes a fresh authenticated TCP/TLS session to a provisioned reachable relay, which can deliver bundles to the same EID through that session. The bundle sender does not substitute the destination EID.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "BP destination identity, TCPCL active-only polling and SABR contact routing", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://www.rfc-editor.org/rfc/rfc9174.html#section-3.5", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4" ], "editorial_references": [ "round533.html", "round533-sources.json" ], "qualification": "The relay must associate the authenticated node with the unchanged destination and select its live session for forwarding; these routing and contact policies are provisioned, not discovered automatically by BP. Both accesses must permit the new connection and retain the same credentials and endpoint registration. Bundle lifetime, storage and retry policy limit recovery. Neither the old IP address nor its TCP connection is preserved. No unrestricted new-contact discovery, seamless stream, arbitrary partition recovery or runtime qualification is inferred." }, { "id": "C01-CG", "feature": "C01", "stack": "CG", "status": "Y", "reason": "SABR can compute a route to the same destination node after its contact with one neighbor ends and a contact through another becomes usable. Constructive witness: the supplied plan ends A-to-D and provides B-to-D plus a feasible route to B. The singleton destination EID and its configured node-number mapping remain unchanged; only the contact sequence and convergence-layer attachment change.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "BP destination identity, TCPCL active-only polling and SABR contact routing", "sources": [ "https://public.ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4" ], "editorial_references": [ "round533.html", "round533-sources.json" ], "qualification": "This is planned destination reattachment, not merely alternate transit to an unchanged final contact. The plan must accurately represent the lost and replacement contacts, ranges, timing and capacity; unexpected loss requires corresponding plan correction or another usable planned opportunity. Contact-plan distribution and EID-to-node mapping are supplied by operators. No automatic mapping of every RFC 9758 encoding to historical CBHE is assumed: retain an explicit correct mapping for the configured private-domain EID. Numeric TCPCL contacts, NODE-ID trust and final-pair BPSec keys remain provisioned. Storage, expiration and connectivity limits apply. The Yes is documentary plausibility of ordinary singleton forwarding, not qualification of custody, critical metadata, a complete executable BPv7/SABR integration or a runtime handover test." }, { "id": "C01-LT", "feature": "C01", "stack": "LT", "status": "Y", "reason": "The selected BPv7/SABR/LTP composition can retain a singleton destination EID while switching the destination node's final contact from neighbor A to neighbor B. The supplied plan ends A-to-D and provides a usable route via B-to-D. SABR selects the contact sequence for the same destination node; each adjacent transfer uses the configured LTP engine and Encapsulation/AOS binding. Neither the bundle sender's destination EID nor its final-pair BPSec keys need replacement.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "libp2p native peerstore and address updates; BP/SABR over configured LTP contacts", "sources": [ "https://public.ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc5326.html#section-2", "https://www.rfc-editor.org/rfc/rfc5326.html#section-5", "https://ccsds.org/Pubs/734x1b1.pdf" ], "editorial_references": [ "round535.html", "round535-sources.json" ], "qualification": "This is a planned change of final attachment, with correct EID-to-node, peer-to-engine and channel mappings already supplied and permitted for both contacts. LTP itself is an adjacent-link transfer protocol, not an independent end-to-end locator service. Fresh LTP sessions on different adjacencies are allowed; retention, expiration, capacity, return-path and contact timing constraints remain. Unplanned failures require a corrected plan or another usable planned opportunity. No automatic contact discovery, unrestricted identifier allocation, migration of an in-progress LTP session, or mission-wide conformance is inferred. The verdict is documentary plausibility at the selected composition's service boundary; complete executable BPv7/SABR/LTP/Encapsulation/AOS integration remains unqualified." }, { "id": "C01-LP", "feature": "C01", "stack": "LP", "status": "Y", "reason": "A libp2p peer can preserve its Peer ID when its old IPv4/QUIC attachment becomes unavailable. A bounded witness advertises a second reachable numeric QUIC listen address through Identify Push while connectivity still exists. The remote peer stores that locator under the same authenticated Peer ID and can dial it after the first attachment fails. go-libp2p v0.50.0 consumes Identify addresses into the peerstore and obtains candidate dial addresses by Peer ID.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "libp2p native peerstore and address updates; BP/SABR over configured LTP contacts", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/identify/README.md", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/protocol/identify/id.go", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/net/swarm/swarm_dial.go" ], "editorial_references": [ "round535.html", "round535-sources.json" ], "qualification": "The stable destination is the Peer ID, not the full transport multiaddress. The alternative must be listening, permitted by ConnectionGater, accepted by address filters and learned before losing the only communication path; it must remain in the peerstore until redial. Native Identify exchange is used, with no DHT, DNS, relay service or application redirection added. If no usable locator is known, the dialer returns an address error: arbitrary movement after total disconnection is not credited. A fresh authenticated QUIC connection and new streams are allowed. Unlike QUIC connection-ID continuity alone, this witness includes a native peer-identity-to-locator repository and address-update mechanism. No runtime mobility or universal implementation claim." }, { "id": "C01-TO", "feature": "C01", "stack": "TO", "status": "Y", "reason": "A v3 onion address is derived from the service identity key rather than its network attachment. After losing one IPv4 access connection, the same service can reconnect through another usable attachment, rebuild introduction circuits and publish current introduction information. A client uses the unchanged onion address to retrieve the service descriptor and establish a new rendezvous circuit.", "method": "Primary specification review; no runtime experiment", "source_label": "Tor onion-service protocol and pinned Reticulum 1.5.5 announcement routing", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [ "round526.html", "round526-sources.json" ], "qualification": "Preserve the service identity and configured client-authorization material, restore permitted Tor connectivity and allow fresh descriptors to propagate through the public directory system. This protocol-native lookup discovers routing/introduction information; it does not ask the sender to replace the destination onion address or follow an application redirect. Stale descriptors, blocked access, guard policy and unavailable relays can delay or prevent recovery. New circuits/streams are allowed; uninterrupted existing streams, simultaneous migration, OnionBalance and Conflux execution are not credited. Documentary architectural witness, not a mobility test." }, { "id": "C01-I2", "feature": "C01", "stack": "I2", "status": "Y", "reason": "An I2P client can retain its Destination while its co-located router changes its external NTCP2 attachment. Replacement inbound tunnels are advertised in an updated LeaseSet for that same Destination; a sender with the known destination key can obtain usable tunnel entry points without adopting another destination identity. Pinned Java source separates external-address/RouterInfo updates from the client session and requests new LeaseSets as tunnel membership changes.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "I2P LeaseSets and GNUnet CADET identity/path separation", "sources": [ "https://www.i2p.net/en/docs/overview/network-database/", "https://raw.githubusercontent.com/i2p/i2p.i2p/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/transport/ntcp/NTCPTransport.java", "https://raw.githubusercontent.com/i2p/i2p.i2p/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/tunnel/pool/TunnelPool.java" ], "editorial_references": [ "round534.html", "round534-sources.json" ], "qualification": "The witness retains destination keys and uses reachable numeric NTCP2 peers at the replacement access, valid clocks and successful multi-hop tunnel construction. The signed LeaseSet and its lookup must become usable before delivery; stale leases, failed tunnel construction or isolation can prevent recovery. A fresh application session is permitted by C01. No preservation of the old TCP connection, automatic recovery from arbitrary partitions or bounded handover time is claimed. The selected netDb lookup is native location resolution, not an external naming service that substitutes the destination. This does not depend on MetaLeaseSets or multiple interchangeable destination identities. No runtime experiment; the cited Java implementation corroborates the routing mechanism, not the separate i2pd post-quantum configuration." }, { "id": "C01-YG", "feature": "C01", "stack": "YG", "status": "Y", "reason": "Yggdrasil derives the endpoint IPv6 address from its node key, independently of TCP/TLS peering locators. A destination that retains its key can move from an unavailable access peering to another configured peering; routing and pathfinding still target the same key-derived IPv6 address. The pinned Ironwood code manages peer removal/addition and discovers paths by destination public key.", "method": "Primary specification review; no runtime experiment", "source_label": "Yggdrasil documentation and pinned Ironwood/cjdns path management", "sources": [ "https://yggdrasil-network.github.io/implementation.html", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go" ], "editorial_references": [ "round527.html", "round527-sources.json" ], "qualification": "Witness: retain the destination key and native-node address, replace its failed adjacent private-IPv4 TCP/TLS connection with an authorized configured numeric peer in the same reachable mesh, and allow routing convergence. The sender keeps its destination IPv6 address. No public peers, DNS, routed-subnet addresses or automatic remote-peer discovery are added. Stale paths, unavailable topology and admission failures can delay or prevent recovery. Fresh sessions are allowed; existing UDP socket survival or seamless handover is not required or demonstrated. No runtime or global-scale result." }, { "id": "C01-CJ", "feature": "C01", "stack": "CJ", "status": "Y", "reason": "A native cjdns endpoint retains its key-derived IPv6 address when its UDP/CryptoAuth access peering changes. In the pinned SessionManager, sessions are indexed by IPv6 identity, getSession can update paths for an existing identity, and ordinary outgoing traffic uses an available path or requests lookup. An updated route label therefore need not change the sender's destination address.", "method": "Primary specification review; no runtime experiment", "source_label": "Yggdrasil documentation and pinned Ironwood/cjdns path management", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c", "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/doc/peering.md", "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/InterfaceController.c" ], "editorial_references": [ "round527.html", "round527-sources.json" ], "qualification": "Witness: preserve the destination key, establish a new authorized numeric peering after loss of the old attachment, and obtain a usable route through the selected pathfinder/route-server system. Outer IPv4 locators and forwarding labels can change while the application retains the same cjdns IPv6 destination. Routing infrastructure must learn the new reachability; possession of the key alone is insufficient. No imported IP tunnel, custom label override or public discovery is introduced. New sessions may be needed after expiry; stale-label recovery, convergence delay and uninterrupted delivery remain unmeasured." }, { "id": "C01-MQ", "feature": "C01", "stack": "MQ", "status": "N", "reason": "The selected Multipath QUIC composition routes packets to numeric IP/UDP peer addresses. Connection IDs allow an established connection to survive address changes, but they are not independently routable destination addresses. Multipath-21 explicitly excludes address discovery and management. If the destination attachment loses its address, connection/path continuity mechanisms do not make that same numeric destination reachable at the replacement attachment.", "method": "Primary specification review; no runtime experiment", "source_label": "RFC 9000 and selected multipath-21 address-management boundary", "sources": [ "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html", "https://www.rfc-editor.org/rfc/rfc9000.html#section-5.1", "https://www.rfc-editor.org/rfc/rfc9000.html#section-9" ], "editorial_references": [ "round530.html", "round530-sources.json" ], "qualification": "This No distinguishes stable destination addressing from migration of an established connection. QUIC can validate another path and preserve connection state while using a changed peer address; that remains credited in F23 and does not satisfy C01's unchanged-address condition. Recovery of transit to an unchanged IP prefix is also insufficient under this criterion. No Mobile IP, LISP, application naming/redirection or destination-address mapping layer is selected. Prevalidated paths and preferred addresses do not turn a connection ID into a network address. The finding concerns the selected multipath-21 draft, not every future QUIC extension or independent infrastructure arrangement. No runtime experiment." }, { "id": "C01-SC", "feature": "C01", "stack": "SC", "status": "Y", "reason": "Within one SCION AS, the complete ISD-AS/local-address tuple can remain unchanged when the destination loses one physical attachment and uses another administratively provisioned attachment. The selected IPv4 underlay can route the retained local host address through the alternative access. SCION inter-domain forwarding still targets the same AS, and its inbound forwarding derives the final underlay destination from the unchanged host address.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "SCION endpoint tuple and final underlay delivery; NIP-01 stable event retrieval", "sources": [ "https://docs.scion.org/en/latest/overview.html", "https://raw.githubusercontent.com/scionproto/scion/v0.12.0/router/dataplane.go", "https://www.rfc-editor.org/rfc/rfc1122.html#section-3.3.4.2", "https://www.rfc-editor.org/rfc/rfc1812.html#section-7.4" ], "editorial_references": [ "round537.html", "round537-sources.json" ], "qualification": "Constructive composition witness: preserve the local IPv4 address on a persistent logical interface, the application's UDP port and the ISD-AS, with authorized routes through both accesses, weak-host reception and a usable return path. Route repair or administrative selection must reach the replacement physical interface. This relies on the selected IP underlay for intra-AS delivery; SCION does not itself supply intra-AS mobility. Merely selecting another AS ingress would be insufficient without this final-attachment configuration. Moving into another AS with a changed tuple is not covered. No autonomous endpoint route-origination authority, automatic arbitrary relocation, deadline or uninterrupted session is inferred; F23-SC remains No. No runtime experiment." }, { "id": "C01-RT", "feature": "C01", "stack": "RT", "status": "Y", "reason": "A Reticulum SINGLE destination retains its hash when the same identity and destination name are announced through another authorized interface. Destination.announce can select an interface; the pinned Transport code can replace the stored next hop and receiving interface from a fresh valid announcement. Thus a failed destination attachment can be replaced by another serial attachment without the sender substituting the destination hash.", "method": "Primary specification review; no runtime experiment", "source_label": "Tor onion-service protocol and pinned Reticulum 1.5.5 announcement routing", "sources": [ "https://reticulum.network/manual/networks.html#destinations-not-addresses", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Destination.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round526.html", "round526-sources.json" ], "qualification": "Retain the destination identity/name, provision the alternate serial path and IFAC credentials, and emit an accepted fresh announcement through reachable transport nodes. Update acceptance depends on timestamps, hop count, unresponsive/expired-path state and announce rate limits; propagation is not instantaneous. The sender may discover the path again and establish a fresh Link with the same destination. This is destination-attachment recovery, not merely transit repair, and does not imply survival of an existing Link, simultaneous multipath, an availability deadline or global-scale capacity. Source review only." }, { "id": "C01-NS", "feature": "C01", "stack": "NS", "status": "Y", "reason": "At Nostr's selected content-retrieval boundary, the unchanged destination reference is the exact regular-event ID. After losing its old Internet attachment, the publisher can reconnect from another access and publish the same signed event through the configured relay pool. A reader's unchanged REQ ids filter can then retrieve that event without substituting its reference or following an external redirect.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "SCION endpoint tuple and final underlay delivery; NIP-01 stable event retrieval", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round510.html", "round537.html", "round537-sources.json" ], "qualification": "This is content reachability, consistent with the named-content interpretation used for NDN/CCNx and F29-NS, not direct routing to a live author by public key. Witness an event unavailable at the reader until the publisher reconnects and an accepting relay receives it, so recovery is not credited solely from an old cached copy. Both parties already know the selected relay pool; new WSS connections and REQ messages are allowed. Verify the returned ID/signature. Relay acceptance, retention and connectivity are required; no global relay discovery, inter-relay forwarding or subscription continuity is inferred. F23-NS remains No. No runtime experiment." }, { "id": "C01-MT", "feature": "C01", "stack": "MT", "status": "Y", "reason": "A Meshtastic destination can retain its NodeID and confirmed public key while losing its old radio adjacency and joining another reachable relay neighborhood. The packet destination is separate from the learned next hop. In the selected firmware, an unsuccessful directed delivery clears the next-hop preference on the final retry and sends through managed flooding, permitting discovery of the same destination through its new adjacency without application address replacement.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Meshtastic directed/flooded forwarding and NET/ROM destination/neighbor route separation", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [ "round531.html", "round531-sources.json" ], "qualification": "Bounded documentary witness: the same configured device moves within a connected, compatible LoRa mesh with relaying CLIENT nodes, matching channel/radio settings and sufficient hop budget. The alternative must reach the new neighborhood and allow replies; finite retries, airtime and loss can delay or prevent an individual delivery. A subsequent transmission is allowed. No claim of seamless sessions, recovery through a persistent partition, arbitrary global reachability or automatic authorization. NodeID addressing alone does not authenticate a peer: the selected confirmed-key policy remains necessary. No MQTT, IP bridge or store-and-forward extension is added. No runtime experiment." }, { "id": "C01-GN", "feature": "C01", "stack": "GN", "status": "Y", "reason": "CADET addresses a remote peer by its public-key identity and service port, separately from its UDP locator and intermediate path. A bounded witness keeps that identity and service while replacing the destination's IPv4/UDP attachment with a usable configured contact. GNUnet TRANSPORT and CADET can establish authenticated low-level connectivity and a new path to the same peer; the caller does not substitute another peer identity.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "I2P LeaseSets and GNUnet CADET identity/path separation", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round534.html", "round534-sources.json" ], "qualification": "The selected GNUnet 0.20.0 witness assumes that usable HELLO/contact information for the replacement attachment is supplied, admitted and validated, and that the peer remains connected to the mesh. It does not infer automatic discovery of arbitrary new public addresses, NAT traversal or a GNS directory. New connections or channels are allowed; continuous old-channel delivery is not required. CADET source separates lost connection bindings from the destination tunnel and considers replacement paths, but this is not an executed mobility test or a guarantee that every candidate path is chosen. Final-peer policy and port availability must still permit communication; an F16-specific outgoing-only configuration is not evidence that any unsolicited incoming service is exposed." }, { "id": "C01-ND", "feature": "C01", "stack": "ND", "status": "Y", "reason": "NDN requests name data rather than a producer attachment. In the already selected connected-tree witness, root-prefix Multicast forwarding explores provisioned Ethernet branches. After the original producer attachment is lost, the same producer can serve the unchanged content name and signing key through another provisioned tree attachment with a local prefix registration. Re-expressed Interests can reach that new attachment without changing the consumer's destination name.", "method": "Primary specification review; no runtime experiment", "source_label": "NDN/NFD management and forwarding; CCNx RFC 8569 and pinned Athena FIB", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-route.html", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/fw/multicast-strategy.cpp" ], "editorial_references": [ "round528.html", "round528-sources.json" ], "qualification": "The stable destination is a content name, not a live host identifier. Keep the remaining tree connected, preconfigure usable faces and root-prefix next hops, and authorize the producer registration at the new attachment. Interest lifetime/hop limits must cover the route. For a direct producer-recovery witness use an uncached named object and allow stale PIT entries/suppression to clear before retrying. Matching cached Data is otherwise legitimate but is not the sole evidence here. No NLSR, global directory, automatic attachment provisioning, PIT migration or seamless producer mobility is added. Existing trust-anchor validation remains; no runtime or capacity result." }, { "id": "C01-AX", "feature": "C01", "stack": "AX", "status": "Y", "reason": "A NET/ROM node hosting the destination can retain its callsign/SSID when its previous crosslink attachment is replaced by a reachable configured neighbor. NODES advertisements and route aging update routes keyed by that same destination callsign. Linux NET/ROM looks up the destination node separately from the selected next-hop neighbor and AX.25 interface, so routing can deliver to the replacement attachment without changing the address used by the sender.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Meshtastic directed/flooded forwarding and NET/ROM destination/neighbor route separation", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c", "https://manpages.debian.org/testing/ax25-tools/netromd.8.en.html", "https://deb.debian.org/debian/pool/main/a/ax25-tools/ax25-tools_0.0.10-rc5+git20230513+d3e6d4f.orig.tar.gz" ], "editorial_references": [ "round531.html", "round531-sources.json" ], "qualification": "The witness is the same NET/ROM node and local endpoint, not an AX.25-only terminal changing gateways. It uses the selected Linux NET/ROM and netromd composition with administrator-configured ports, permitted neighbors, announcements and appropriate route quality/aging. Old routes must expire, fail over or be updated and a viable path must converge within hop limits. A fresh transport circuit is allowed; no uninterrupted circuit or bounded recovery-time guarantee. Callsigns are not cryptographically authenticated and no public-radio licensing permission is inferred. No IP tunnel or additional mobility protocol. No runtime experiment." }, { "id": "C01-BA", "feature": "C01", "stack": "BA", "status": "Y", "reason": "The selected native Ethernet service can preserve a client MAC address when the client loses its attachment to one batman-adv node and attaches to another reachable node in the same mesh and VLAN. The translation table maps that client address to its serving originator. Learning the client at the new node triggers roaming notification and translation-table updates, allowing traffic for the unchanged destination MAC to follow the new serving node.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "batman-adv translation-table roaming and RPL DAO target/parent separation", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/translation-table.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c", "https://downloads.open-mesh.org/batman/papers/batman-adv_v_intro.pdf" ], "editorial_references": [ "round532.html", "round532-sources.json" ], "qualification": "Documentary witness for Linux 6.12 BATMAN_IV: a client keeps its locally administered unicast MAC and VLAN, reconnects through an already configured local Ethernet attachment, and transmits a frame so the new serving node learns it. Relays and destination remain reachable; client isolation and other forwarding policies must permit delivery. Notification, table-version reconciliation and route convergence can require retries. This is client attachment recovery, not only repair of an intermediate mesh link. No IP address mobility, cryptographic MAC authentication, cross-mesh roaming, seamless-session guarantee or automatic port authorization is inferred. The old attachment may fail without destroying the whole mesh; arbitrary partitions or simultaneous node failures are not guaranteed recoverable. No runtime experiment." }, { "id": "C01-BL", "feature": "C01", "stack": "BL", "status": "Y", "reason": "An administratively authorized Babel node can keep its locally provisioned IPv6 address or attached destination prefix while changing its physical neighbor attachment. It originates that same local route through the new eligible adjacency; Babel updates and route selection propagate a usable path to the unchanged destination. This supplies a constructive last-attachment witness without changing the sender's numeric destination or adding a host-mobility protocol.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 1122 weak-host semantics, configured IPv4 routes and Babel local-route origination", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.7", "https://www.rfc-editor.org/rfc/rfc8966.html#section-1.1", "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-E" ], "editorial_references": [ "round536.html", "round536-sources.json" ], "qualification": "The destination is on the same authorized Babel node or on its retained local link, and the new access admits that node's route origination. The address remains assigned and the destination prefix must be accepted by the relevant filters. No concurrent conflicting origin is introduced. This uses the column's general local-ULA Babel service; it does not assert that the separate G01 fixed-hierarchy filters admit arbitrary relocation. Reconvergence and stale-route removal are required; no timing bound or lossless session is guaranteed. Administrative route-origination authority is explicitly allowed for this C01 witness and is precisely why F23-BL remains No under its stricter ordinary-endpoint rule. Moving an unprivileged host between unrelated prefixes is not covered. No runtime experiment." }, { "id": "C01-RI", "feature": "C01", "stack": "RI", "status": "Y", "reason": "Within the configured RPL domain, a leaf can keep its provisioned IPv6 destination address when its old parent adjacency fails and an eligible alternative parent becomes reachable. DAO Target and Transit Information separate the destination address from its parent relationship. Updated path information lets the non-storing root rebuild its downward source route to the unchanged target; the sender does not need an alternative destination address.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "batman-adv translation-table roaming and RPL DAO target/parent separation", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.4", "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.2", "https://www.rfc-editor.org/rfc/rfc6775.html#section-5.5" ], "editorial_references": [ "round532.html", "round532-sources.json" ], "qualification": "Bounded composition witness: the same ULA remains valid across both attachments in the same configured domain; link access and keys are provisioned for the replacement neighbor, OF0 admits a valid parent, and required 6LoWPAN registration succeeds. DAO information must reach the root and stale path state must be repaired before delivery. A fresh DTLS handshake or retransmission is allowed. This is a last-hop parent change, not just transit failover. No movement to an unrelated prefix/domain, address conflict, permanent partition, bounded handover latency or uninterrupted session is covered. Registration failure and finite route lifetimes remain real limits. This is documentary plausibility, not a claim of a tested integrated implementation." }, { "id": "C01-HP", "feature": "C01", "stack": "HP", "status": "Y", "reason": "The selected HIP mobility extension keeps the Host Identity Tag as the communication reference while a host changes its IP attachment. LOCATOR_SET in UPDATE informs the peer of the new locator, with address verification before normal use. RFC 8046 describes both break-before-make and make-before-break movement without application address replacement.", "method": "Primary documentary reassessment; no runtime test", "source_label": "Selected routing and HIP specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-3.2.1" ], "editorial_references": [ "round493.html", "round493-sources.json" ], "qualification": "This covers an established association with one moving host and a reachable peer, using the selected RFC 8046 mobility procedures. It is not simultaneous mobility, automatic reachability of an unknown first-contact locator, or lossless handover. An operational alternative attachment and successful control exchange are required; no runtime test is claimed." }, { "id": "C01-CX", "feature": "C01", "stack": "CX", "status": "Y", "reason": "RFC 8569 separates the requested content name from the network endpoint supplying it. The selected name-prefix FIB can point the unchanged name toward another producer attachment; Athena exposes route addition/deletion for a name independently of that name's value. After the old attachment fails, infrastructure configuration can direct a fresh Interest to the same named content and trusted producer key at the alternate attachment.", "method": "Primary specification review; no runtime experiment", "source_label": "NDN/NFD management and forwarding; CCNx RFC 8569 and pinned Athena FIB", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-1.3", "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.4", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_FIB.c" ], "editorial_references": [ "round528.html", "round528-sources.json" ], "qualification": "Bounded configured recovery: provision reachable IPv4/UDP forwarder links and update the affected name-prefix routes, remove stale next hops and allow PIT state to expire or retry. The consumer retains the same exact name and validation requirements; it neither substitutes the new underlay address nor follows an application redirect. This credits name-level reachability, not persistence of an address for a particular host. Static FIB administration is required; no dynamic producer discovery or mobility protocol is silently added. Use uncached content to demonstrate the alternate producer attachment. No uninterrupted-session or complete executable-composition claim." }, { "id": "C01-LI", "feature": "C01", "stack": "LI", "status": "Y", "reason": "LISP separates the destination EID from RLOCs naming network attachment points. An authorized destination-site reattachment can preserve the EID while replacing the serving RLOC mapping. Map registration, lookup and cache-update mechanisms allow the sender's ITR to encapsulate toward the new RLOC without requiring the sending application to substitute its destination EID.", "method": "Primary specification review; no runtime experiment", "source_label": "LISP RFC 9300 and RFC 9301 mapping and attachment semantics", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-13", "https://www.rfc-editor.org/rfc/rfc9301.html#section-6", "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.2" ], "editorial_references": [ "round529.html", "round529-sources.json" ], "qualification": "Bounded infrastructure-managed witness: provision the same destination EID behind an authorized serving ETR at the new attachment, ensure local delivery and underlay reachability, update the Map-Server registration, and refresh the source ITR cache through the defined mapping procedures. This changes the destination's EID-to-attachment binding rather than only repairing transit to one unchanged locator. The mapping service returns encapsulation locators to the ITR, not a replacement destination for the application. Administrative authority and convergence are required; stale caches and unavailable control services can prevent recovery. No arbitrary host roaming, LISP-MN, LISP-SEC or uninterrupted session is credited. F23-LI remains No for autonomous mobility of the selected ordinary endpoint." }, { "id": "C01-IL", "feature": "C01", "stack": "IL", "status": "Y", "reason": "ILNP binds the selected TCP communication to the Node Identifier, while the Locator may change. In the selected overlapping-attachment scenario, the moving destination learns the new Locator and sends Locator Updates to its correspondent before leaving the old attachment. The correspondent continues addressing the same Identifier through the new attachment without application redirection.", "method": "Primary documentary review and bounded selected-composition inference; no execution", "source_label": "HIP, ILNP, Babel and SCION specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-6.2", "https://www.rfc-editor.org/rfc/rfc6743.html" ], "editorial_references": [ "round494.html", "round494-sources.json" ], "qualification": "The stable destination reference is the Identifier, not an unchanged Identifier-Locator vector: the wire Locator changes. Credit covers an existing session with unchanged NIDs, overlapping authorized attachments and a stationary reachable correspondent. DNS updates serve future sessions but are not the mechanism preserving this communication. No simultaneous-movement or lossless-handover result is claimed." }, { "id": "C01-TS", "feature": "C01", "stack": "TS", "status": "Y", "reason": "The same Tailscale destination IP remains usable when its device changes physical attachment. Direct-path discovery and DERP fallback can reach that registered destination through a new authorized path.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "Credits overlay address continuity, not continuity of the public underlay IP. Policy, registration and available connectivity remain prerequisites." }, { "id": "C01-RA", "feature": "C01", "stack": "RA", "status": "Y", "reason": "The configured upper IPC endpoint ue.internet keeps address 1 in internet.DIF while its lower provider attachment changes. Enrollment through the new provider and link-state forwarding permit return traffic to reach that same address after the old attachment is disconnected; application redirection or an externally supplied replacement address is unnecessary.", "method": "Primary tutorial, configuration and implementation-source assessment; no execution", "source_label": "IRATI native bootstrap and two-provider mobility documentation", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/internet.dif", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/ipcm.conf", "https://raw.githubusercontent.com/wiki/IRATI/stack/tutorial10/ue/internet.dif", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcm/addons/mobility-manager.cc" ], "editorial_references": [ "round658.html" ], "qualification": "Documentary and source-level evidence, not a local rerun. The witness uses a configured two-interface make-before-break handover. Abrupt outage recovery, lossless operation, simultaneous movement of both peers and arbitrary provider admission are not established. Local privileged setup is disclosed; it is not infrastructure route-administration authority. This is an inference from the stable address configuration and documented bidirectional echo-flow continuity, not a separate forced-failure test." }, { "id": "C02-PN", "feature": "C02", "stack": "PN", "status": "Y", "reason": "Architectural capability in the explicitly selected path S → A → B → D: A is transit-only, not a destination rendezvous, and D is not its adjacent peer. Member Route Intent sections 2/4/5 exposes the requested adjacent target B; nested direct/E2E protection (wire-v4 5/7/12) keeps deeper control and endpoint content opaque to A. This composition does not require A to receive D’s final identity or locator. A combined rendezvous role, collusion, prior external knowledge and a shorter path with D adjacent to A are not credited by this positive.", "method": "Documentary composition analysis; no packet capture", "source_label": "Architectural composition of scoped route intent and nested protected layers", "sources": [], "editorial_references": [ "index.html#prp-transit-profile" ], "qualification": "Trace a concrete multi-hop implementation through establishment, lookup and data. Confirm first hop is transit-only, discovery terminates beyond it, and no deeper identity is copied into its state. ROUTE-001 remains open; no integrated execution is certified." }, { "id": "C02-PI", "feature": "C02", "stack": "PI", "status": "Y", "reason": "Architectural capability in the explicitly selected path S → A → B → D: A is transit-only, not a destination rendezvous, and D is not its adjacent peer. Member Route Intent sections 2/4/5 exposes the requested adjacent target B; nested direct/E2E protection (wire-v4 5/7/12) keeps deeper control and endpoint content opaque to A. This composition does not require A to receive D’s final identity or locator. A combined rendezvous role, collusion, prior external knowledge and a shorter path with D adjacent to A are not credited by this positive.", "method": "Documentary composition analysis; no packet capture", "source_label": "Architectural composition of scoped route intent and nested protected layers", "sources": [], "editorial_references": [ "index.html#prp-transit-profile" ], "qualification": "Trace a concrete multi-hop implementation through establishment, lookup and data. Confirm first hop is transit-only, discovery terminates beyond it, and no deeper identity is copied into its state. ROUTE-001 remains open; no integrated execution is certified." }, { "id": "C02-IP", "feature": "C02", "stack": "IP", "status": "N", "reason": "Ordinary selected IP headers expose routable source/destination addresses and forwarding metadata. This baseline supplies no endpoint-location or established-control concealment.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-BP", "feature": "C02", "stack": "BP", "status": "N", "reason": "BPSec prohibits encrypting the primary block, which carries bundle destination information. A forwarding BP node sees that block after terminating hop-local TCPCL/TLS. Payload confidentiality and protection against a passive link observer do not conceal the destination from this intermediary. No bundle-in-bundle encapsulation is selected.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9172.html#section-3.8" ], "editorial_references": [], "qualification": "" }, { "id": "C02-CG", "feature": "C02", "stack": "CG", "status": "N", "reason": "A forwarding BPA reads the primary-block destination identifier. Payload confidentiality does not hide that destination from this intermediary.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-LT", "feature": "C02", "stack": "LT", "status": "N", "reason": "A forwarding BPA reads the destination in the primary block even when payload confidentiality is enabled.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "RFC 9171, BPv7", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-LP", "feature": "C02", "stack": "LP", "status": "N", "reason": "The selected direct QUIC/libp2p composition exposes the remote endpoint IP locator to the first IP forwarder. Payload encryption does not hide that locator. No relay or onion-routing composition is selected.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9" ], "editorial_references": [], "qualification": "" }, { "id": "C02-TO", "feature": "C02", "stack": "TO", "status": "Y", "reason": "Onion-service circuits meet through rendezvous; the first relay does not directly receive the final destination. Collusion/correlation are excluded.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/rend-spec/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-I2", "feature": "C02", "stack": "I2", "status": "Y", "reason": "Select a non-colluding first participant that is not the outbound tunnel endpoint. Remaining tunnel protection hides delivery instructions after that participant processes its own layer; its state supplies the next hop, not the final client destination. Destination lookups also use tunnels. This excludes zero/one-hop shortcuts, a co-resident lookup role and collusion.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://i2p.net/en/docs/specs/tunnel-message/" ], "editorial_references": [], "qualification": "Trace construction, lookup and data together with at least two outbound remote hops and no direct destination lookup at the first participant. Inventory all decrypted state and correlate it with the final destination. This is documentary role analysis, not measured anonymity." }, { "id": "C02-YG", "feature": "C02", "stack": "YG", "status": "N", "reason": "The traffic wire format encodes source and final destination public keys outside the encrypted payload. An adjacent forwarding participant can read the destination after link decryption. Payload encryption alone does not hide it from that role.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/traffic.go" ], "editorial_references": [], "qualification": "" }, { "id": "C02-CJ", "feature": "C02", "stack": "CJ", "status": "N", "reason": "In the documented DHT routing composition, a lookup recipient receives the final IPv6 target in tar. When that recipient is the first adjacent router, the final target is known to it despite encrypted transport. Thus the composition does not guarantee C02; this is not a claim that every switch sees every destination.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/doc/Whitepaper.md#the-router" ], "editorial_references": [], "qualification": "" }, { "id": "C02-MQ", "feature": "C02", "stack": "MQ", "status": "N", "reason": "In the selected direct IPv4/IPv6/QUIC composition, the first IP forwarder sees the final endpoint locator. Encryption and multipath do not conceal that destination; no relay or onion layer is selected.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://datatracker.ietf.org/doc/html/rfc1812#section-5.2.1", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-SC", "feature": "C02", "stack": "SC", "status": "N", "reason": "SCION forwarding uses an ISD-AS plus local endpoint address and packet-carried path. The selected plain SCION/UDP profile does not hide the final destination from a forwarding node.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-RT", "feature": "C02", "stack": "RT", "status": "N", "reason": "The Link request carries the destination hash so forwarding nodes can establish the path. An anonymous initiator does not conceal that final destination reference from the first forwarder.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html#link-establishment-in-detail" ], "editorial_references": [], "qualification": "" }, { "id": "C02-NS", "feature": "C02", "stack": "NS", "status": "N", "reason": "In basic NIP-01, the publisher's first relay terminates WebSocket sessions and sends matching events directly to subscribing clients. That relay observes those final recipient connections and network locators; the composition adds no onion-routing layer between relay and subscriber. Broadcast does not imply that the publisher knows the complete audience, nor that subscribers expose a civil identity.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "C02-MT", "feature": "C02", "stack": "MT", "status": "N", "reason": "The unencrypted packet header carries the final destination node number. The first relay therefore receives a destination identifier even when it cannot decrypt the direct-message payload.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [], "qualification": "" }, { "id": "C02-GN", "feature": "C02", "stack": "GN", "status": "N", "reason": "The CADET connection-create message carries the whole path of peer identities from origin to final destination. A forwarding peer decrypts its CORE adjacency traffic and parses this list in handle_connection_create. The first relay can therefore read the final peer identity, even though it cannot decrypt the end-to-end application payload. This does not imply knowledge of the final peer physical address or civil identity.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "src/cadet/cadet_protocol.h: GNUNET_CADET_ConnectionCreateMessage; src/cadet/gnunet-service-cadet_core.c: handle_connection_create", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-ND", "feature": "C02", "stack": "ND", "status": "N", "reason": "The selected NDN profile exposes the requested Name to the first forwarder; known content/key names and local forwarding state are not protected by an anonymity layer. Returned ECDSA-signed Data requires a visible KeyLocator, which identifies the signing key by name or digest. A routed producer request therefore does not have a mechanism concealing its named target and producer provenance from that intermediary. This does not mean a Name is a host locator, that the signer is necessarily the serving node, or that the forwarder always knows a physical producer location. A cache can answer without contacting the producer, but absence of a live producer destination is not evidence that a contacted final endpoint is concealed. Consumer non-identification in C06 is a distinct property. No onion-routing or name-encryption extension is selected.", "method": "Selected-profile inference from primary packet specifications; no capture", "source_label": "NDN v0.3 Interest names and SignatureSha256WithEcdsa KeyLocator", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://docs.named-data.net/NDN-packet-spec/current/signature.html#signaturesha256withecdsa" ], "editorial_references": [], "qualification": "" }, { "id": "C02-AX", "feature": "C02", "stack": "AX", "status": "N", "reason": "The network header exposes the destination-node callsign to the first forwarding node.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "C02-BA", "feature": "C02", "stack": "BA", "status": "N", "reason": "The unicast header exposes the destination originator MAC, and the encapsulated Ethernet header retains the final client destination. This profile selects no encryption or destination-concealing wrapper.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "Linux v6.12 batman-adv packet formats", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h" ], "editorial_references": [], "qualification": "" }, { "id": "C02-BL", "feature": "C02", "stack": "BL", "status": "N", "reason": "The first IPv6 router reads the final destination address from the base header; no destination-concealing overlay is selected.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-RI", "feature": "C02", "stack": "RI", "status": "N", "reason": "End-to-end DTLS protects application records, not the IPv6 destination used by the selected RPL forwarders. The first routing intermediary can determine the destination from the packet and its forwarding context.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-9" ], "editorial_references": [ "round262-sources.json" ], "qualification": "6LoWPAN header compression is not encryption against a forwarding intermediary. Link access control does not conceal a destination from an authorized router." }, { "id": "C02-HP", "feature": "C02", "stack": "HP", "status": "N", "reason": "The selected host-to-host ESP path retains outer IPv4/IPv6 source and destination locators. A first transit router can see the final host locator; HIP identity separation and encrypted payload do not hide that destination.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [ "round262-sources.json" ], "qualification": "No anonymity relay or destination-concealing tunnel is selected. This does not claim that every ESP data packet carries the explicit Host Identity." }, { "id": "C02-CX", "feature": "C02", "stack": "CX", "status": "N", "reason": "The first CCNx forwarder sees the requested name and matching restrictions. Returned signed objects disclose producer KeyId. The selected composition adds no mechanism concealing the named target and producer provenance from that intermediary.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4" ], "editorial_references": [ "round262-sources.json" ], "qualification": "A content name is not necessarily a host locator, and the signer may differ from the serving cache. A cache hit without contacting the producer is not proof that a contacted final endpoint is concealed." }, { "id": "C02-LI", "feature": "C02", "stack": "LI", "status": "N", "reason": "The inner IPv4 destination EID is present in the unencrypted encapsulated packet. The first intermediary can inspect it; adding an outer RLOC does not conceal the final destination.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-IL", "feature": "C02", "stack": "IL", "status": "N", "reason": "Source and destination NIDs and Locators occupy readable header fields in the selected profile. With no encryption or destination-hiding relay selected, a first intermediary can read the final destination information.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "C02-TS", "feature": "C02", "stack": "TS", "status": "N", "reason": "The first DERP relay terminates its client transport and reads the destination node public key in FrameSendPacket. The final peer selector is therefore visible to that intermediary despite payload encryption.", "method": "Official documentation and pinned source inspection; no runtime test", "source_label": "Tailscale control plane and DERP source 566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://tailscale.com/docs/concepts/control-data-planes", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round586.html", "round586-sources.json" ], "qualification": "This counterexample uses the selected relayed path, not direct communication. It reveals a node key, not necessarily a civil identity; TLS only hides the frame from external carrier observers." }, { "id": "C02-RA", "feature": "C02", "stack": "RA", "status": "?", "reason": "The C06 counterexample concerns a member of the supporting routed DIF. It does not by itself settle C02: the first access intermediary can belong only to a narrower lower DIF and see a provider/core destination rather than the final host. Recursion changes the observation scope.", "method": "Observation-boundary review; no verdict change", "source_label": "IRATI recursive DIF and directory scope", "sources": [ "https://github.com/IRATI/stack/wiki/Software-architecture-overview", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c" ], "editorial_references": [ "round667.html" ], "qualification": "Trace the first intermediary in the complete selected Ethernet/Wi-Fi and mobility composition, including directory membership, enrollment and established forwarding fields. Determine whether its own decrypted state identifies the final destination. Do not substitute an arbitrary higher-layer transit observer for the first intermediary." }, { "id": "C03-PN", "feature": "C03", "stack": "PN", "status": "Y", "reason": "For established protected adjacency traffic, wire-v4 sections 5–6 encrypt the complete route-record list, including control kinds and routing selectors. Bootstrap is outside this criterion. The visible nonce/ciphertext/tag structure does not prove statistical indistinguishability; timing and volume remain separate observations.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "" }, { "id": "C03-PI", "feature": "C03", "stack": "PI", "status": "Y", "reason": "For established protected adjacency traffic, wire-v4 sections 5–6 encrypt the complete route-record list, including control kinds and routing selectors. Bootstrap is outside this criterion. The visible nonce/ciphertext/tag structure does not prove statistical indistinguishability; timing and volume remain separate observations.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "" }, { "id": "C03-IP", "feature": "C03", "stack": "IP", "status": "N", "reason": "Ordinary selected IP headers expose routable source/destination addresses and forwarding metadata. This baseline supplies no endpoint-location or established-control concealment.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-BP", "feature": "C03", "stack": "BP", "status": "Y", "reason": "With TLS selected, RFC 9174 section 4.4.3 protects session negotiation and all later TCPCL messaging. Public Contact Headers precede this protection and are outside established-traffic C03. Outer TCP/TLS framing remains visible.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.3" ], "editorial_references": [], "qualification": "" }, { "id": "C03-CG", "feature": "C03", "stack": "CG", "status": "Y", "reason": "In established TLS-protected TCPCL traffic, convergence-layer messages and carried bundles are encrypted on the observed adjacency. Bootstrap and traffic-shape inference remain outside this credit.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9174, TCPCLv4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "C03-LT", "feature": "C03", "stack": "LT", "status": "N", "reason": "LTP control headers remain exposed in this profile. BPSec payload protection does not encrypt those headers; no link-confidentiality layer is selected.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "LTP specification, RFC 5326", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-LP", "feature": "C03", "stack": "LP", "status": "Y", "reason": "RFC 9001 protects established QUIC frame contents with AEAD and protects packet numbers and selected header bits. This credits protected control contents under the same framing exception used for TLS columns: connection IDs, the fixed bit and optional spin bit remain visible. It does not mean all headers are concealed or that QUIC is unrecognizable.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html#section-5.4" ], "editorial_references": [], "qualification": "" }, { "id": "C03-TO", "feature": "C03", "stack": "TO", "status": "Y", "reason": "Tor transports cells inside established TLS channels; relay command, stream identifier and length are additionally inside onion-encrypted relay bodies. A passive link observer does not receive these Tor control fields in cleartext. Outer IP/TCP/TLS framing and traffic patterns remain observable; bootstrap and statistical protocol recognition are outside C03.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/tor-spec/cell-packet-format" ], "editorial_references": [], "qualification": "" }, { "id": "C03-I2", "feature": "C03", "stack": "I2", "status": "Y", "reason": "NTCP2 protects data-phase contents with AEAD and obfuscates the two-byte frame length with SipHash. These protect established protocol fields within C03; bootstrap is excluded and statistical indistinguishability is not claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "" }, { "id": "C03-YG", "feature": "C03", "stack": "YG", "status": "Y", "reason": "The selected TLS peer transport encrypts Yggdrasil traffic carried by the established peer connection. This credits control-field confidentiality against a passive link observer, not concealment from the TLS peer or invisibility of TCP/TLS framing.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-CJ", "feature": "C03", "stack": "CJ", "status": "Y", "reason": "The selected UDP peering uses outer point-to-point CryptoAuth. Its established data encryption wraps switch headers and control traffic, concealing those inner fields from a passive link observer. Outer IP/UDP framing, lengths and CryptoAuth session framing remain visible; authorized neighbors can read their decrypted control state.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/master/doc/Whitepaper.md" ], "editorial_references": [], "qualification": "Pin executable cjdns and capture established UDP peering, including switch errors and router queries. Verify outer encryption on every selected path and inventory unencrypted framing. The whitepaper supplies architecture; no runtime capture or protocol-indistinguishability result is claimed." }, { "id": "C03-MQ", "feature": "C03", "stack": "MQ", "status": "Y", "reason": "RFC 9001 protects established QUIC frame contents with AEAD and protects packet numbers and selected header bits. This credits protected control contents under the same framing exception used for TLS columns: connection IDs, the fixed bit and optional spin bit remain visible. It does not mean all headers are concealed or that QUIC is unrecognizable.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html#section-5.4" ], "editorial_references": [], "qualification": "" }, { "id": "C03-SC", "feature": "C03", "stack": "SC", "status": "N", "reason": "The selected UDP/SCION stack exposes its common, address and path headers without an outer encrypted tunnel. Header fields and hop information are available on the link; authentication of forwarding fields does not encrypt them.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-RT", "feature": "C03", "stack": "RT", "status": "Y", "reason": "The serial profile now explicitly enables secret IFAC with no public credential advertisement. Transport.handle_outgoing_ifac masks header and payload; Link payload encryption alone does not. The IFAC flag and tag remain visible. This credits control-field protection against a passive observer without the interface secret, not protocol invisibility or protection against an authorized interface peer.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py" ], "editorial_references": [], "qualification": "Verify the selected serial configuration, secret handling and transmitted bytes. Quantify leakage and key-strength assumptions separately. No capture or cryptographic security audit was performed; IFAC changes no path/Link lifecycle semantics." }, { "id": "C03-NS", "feature": "C03", "stack": "NS", "status": "Y", "reason": "The selected WSS connection places WebSocket control frames and Nostr messages inside TLS. They are protected from passive link observation after establishment, although the relay reads them. TCP/TLS framing remains visible; masking alone would not provide this protection.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc6455.html#section-10.6" ], "editorial_references": [], "qualification": "" }, { "id": "C03-MT", "feature": "C03", "stack": "MT", "status": "N", "reason": "Established encrypted messages still carry clear routing fields, including sender, destination, hop flags and relay/next-hop hints. Payload encryption does not hide those protocol-control fields. Bootstrap is not the reason for this negative.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [], "qualification": "" }, { "id": "C03-GN", "feature": "C03", "stack": "GN", "status": "Y", "reason": "Established CORE traffic encrypts and authenticates the carried protocol messages, including CADET routing/control contents, on each adjacency. GSC_KX_encrypt_and_transmit protects the inner message region and handle_encrypted verifies before dispatch. Outer IPv4/UDP addresses, lengths and CORE framing remain visible. This uses the same framing exception as the TLS/QUIC columns: protection from a passive observer without link keys, not concealment from the relay itself or protocol invisibility.", "method": "Pinned release-source analysis and primary protocol review; no runtime execution", "source_label": "src/core/gnunet-service-core_kx.c: GSC_KX_encrypt_and_transmit and handle_encrypted", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/core/core.html" ], "editorial_references": [], "qualification": "Capture established UDP/CORE traffic with and without endpoint keys, map exposed framing, and confirm inner CADET control fields are encrypted. Bootstrap and authorized relay inspection remain outside this positive result." }, { "id": "C03-ND", "feature": "C03", "stack": "ND", "status": "N", "reason": "Named Data and its TLV control elements remain visible; the signature does not encrypt these fields.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NDN packet format v0.3 Data packet", "sources": [ "https://docs.named-data.net/NDN-packet-spec/0.3/data.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-AX", "feature": "C03", "stack": "AX", "status": "N", "reason": "Network and transport headers expose callsigns, circuit fields, sequence numbers and flags during established communication.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "C03-BA", "feature": "C03", "stack": "BA", "status": "N", "reason": "Packet type, TTL, destination and translation-table version are exposed in the native unicast header. The selected plain Ethernet carriers provide no encryption of established control fields.", "method": "Pinned primary-source inspection and selected-profile inference; no execution", "source_label": "Linux v6.12 batman-adv packet formats", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h" ], "editorial_references": [], "qualification": "" }, { "id": "C03-BL", "feature": "C03", "stack": "BL", "status": "N", "reason": "IPv6 headers and base Babel UDP control messages remain visible. The profile excludes the separate Babel DTLS/MAC extensions.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-RI", "feature": "C03", "stack": "RI", "status": "Y", "reason": "RFC 6550 sections 3.2.3 and 10.1 explicitly allow unsecured-mode RPL to rely on link-layer security. The previously unspecified access-controlled link is now bound to encrypted IEEE 802.15.4 data frames, rather than authentication alone. Linux v6.12 defines ENC_MIC128 as level 7. Its llsec_key_alloc selects ccm(aes), and llsec_do_encrypt_auth separates the MAC header as associated data from the payload passed to crypto_aead_encrypt when the ENC bit is set. The TX path invokes this function before transmission. Thus the 6LoWPAN dispatch/compression/fragment fields and the carried IPv6, ICMPv6 and RPL control fields are inside the encrypted MAC payload. This includes established DIS/DIO/DAO/DAO-ACK traffic when carried in the configured protected data frames. The positive finding uses the same visible-outer-framing allowance as C03-MQ/LP.", "method": "Explicit configuration selection and clear/encrypted field mapping; no runtime execution", "source_label": "RFC 6550 and Linux v6.12 link-security source, reviewed 2026-10-22", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-10.1", "https://github.com/torvalds/linux/blob/v6.12/net/mac802154/llsec.c", "https://github.com/torvalds/linux/blob/v6.12/net/mac802154/tx.c", "https://github.com/torvalds/linux/blob/v6.12/include/linux/ieee802154.h" ], "editorial_references": [ "round425.html", "round425-sources.json", "round425-fields.json" ], "qualification": "This is a documentary mechanism/configuration witness, not a complete Linux RPL/DTLS executable qualification or radio capture. All relevant adjacencies and multicast transmissions must use the selected encryption policy; access control, MIC-only levels 1-3, or a mix of protected data with plaintext RPL controls does not satisfy it. Frame-control fields, MAC addresses, auxiliary security headers, frame counters/key selectors, sizes and timing remain observable. MAC acknowledgements and other link-management frames are not claimed hidden; the inspected Linux path even marks control-frame security support as incomplete. A locally captured pre-encryption TX packet is not proof of plaintext over the air. Link-key holders and forwarding routers can read RPL and IP routing information. No active-probe defense, endpoint-location anonymity, PQ protection, unprivileged operation, or traffic-analysis resistance is inferred. Keys and frame-counter lifecycle require correct provisioning. C02/F14, C04, D01 and the complete-stack execution evidence are unchanged; this is not an assertion that RPL unsecured mode encrypts itself." }, { "id": "C03-HP", "feature": "C03", "stack": "HP", "status": "N", "reason": "Established HIP UPDATE signaling carries control parameters such as sequence/acknowledgment and locator updates outside ESP payload encryption. HIP_MAC and signatures authenticate these messages without concealing their control contents.", "method": "Documentary mechanism inventory; no traffic-analysis experiment", "source_label": "Primary packet-format, signaling and padding specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-5.3.5" ], "editorial_references": [ "round263-sources.json" ], "qualification": "This finding uses post-establishment signaling, not bootstrap or merely an exposed outer framing bit. ESP still encrypts user payload. No outer control-encryption tunnel is selected." }, { "id": "C03-CX", "feature": "C03", "stack": "CX", "status": "N", "reason": "Established CCNx Interests and Content Objects retain visible names, TLV control fields and validation metadata in the selected UDP profile. Content signatures provide authenticity without encrypting those control contents.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc8609.html#section-3" ], "editorial_references": [ "round262-sources.json" ], "qualification": "The finding concerns established traffic, not initial bootstrap. No name-encryption or encrypted-session extension is selected." }, { "id": "C03-LI", "feature": "C03", "stack": "LI", "status": "N", "reason": "The selected IPv4/UDP/LISP data header and control messages are readable on the wire. Control-message authentication is not encryption of established protocol fields.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-IL", "feature": "C03", "stack": "IL", "status": "N", "reason": "The ILNPv6 header, Nonce Destination Option and ICMP Locator Updates remain visible. Nonce validation is not confidentiality of protocol control fields; optional IPsec is excluded.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "C03-TS", "feature": "C03", "stack": "TS", "status": "N", "reason": "On the selected direct UDP path, established WireGuard packets expose their message type, receiver index and counter. Encrypting the inner packet does not conceal all protocol control fields.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "DERP TLS can hide these fields from a passive carrier on that segment; it does not remove the direct-path counterexample in this selected profile." }, { "id": "C03-RA", "feature": "C03", "stack": "RA", "status": "Y", "reason": "With selected SDU encryption active on every normal-DIF adjacency, RMT protects the serialized PDU before passing it to the lower flow. The default crypto policy encrypts the complete PDU buffer after compression, sequence/MAC addition and block padding. Thus normal-DIF address, CEP, QoS, type and control fields are not available in cleartext to a passive link observer without the keys.", "method": "Pinned serialization/protection source trace; passive observation boundary; no runtime capture", "source_label": "IRATI RMT and default SDU encryption pipeline", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup-crypto-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/pci.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/ipcps/shim-eth-core.c" ], "editorial_references": [ "round668.html" ], "qualification": "Yes for established protected traffic, using the same outer-framing boundary as the Tor and PRP entries. Ethernet/Wi-Fi framing, MAC addresses, EtherType, IV, lengths and timing remain observable; bootstrap and link discovery are excluded. This is not protocol indistinguishability. An enrolled intermediary can decrypt its own adjacency and read forwarding fields, so C06 remains No. No packet capture, independent cryptographic audit or active-probe qualification." }, { "id": "C04-PN", "feature": "C04", "stack": "PN", "status": "Y", "reason": "The selected known-identity PRP composition includes a credential-gated handshake defense. In pinned kernel source, hs2_observe_scoped first verifies the HS2 cryptographic proof and then matches the derived strong identity against an unexpired expected identity for the context/scope/alias before allocating negotiation state. A different identity returns EKEYREJECTED; the carrier-bootstrap fallback applies to ENOKEY, not a mismatch against an existing expectation. The inspected rejection path reports through local generic netlink, not a carrier response. For an already protected adjacency, authentication failure returns before public-control parsing. Credit the existence of this bounded defense, consistently with C04 cells that retain documented admission exceptions.", "method": "Source-level evidence of a bounded defense; prior local admission experiment retained with explicit limits", "source_label": "Pinned prp-linux-kmod d90a712c6d36111de66bcdd7be8e0f462bf539ae: handshake proof, expected-identity admission, local rejection diagnostics and RX dispatch", "sources": [], "editorial_references": [ "round362-sources.json", "round361-review.json", "round360-sources.json" ], "qualification": "Requires a valid expected-identity binding in the already selected known-identity mode. This is not silence for every probe or every endpoint state. Missing/expired identity expectations may allow identity learning on valid carrier-bootstrap contexts; the public PoW challenge can remain recognizable before requester authentication, as the previous local harness demonstrated with TX stubbed. Locator/context matching is not itself cryptographic authentication. No network/timing/replay-resistance experiment, constant-time claim, universal camouflage, DoS immunity or whole-stack certification. Any runtime controller reactions and carrier-driver replies remain outside this source-level witness. Criterion and profiles unchanged." }, { "id": "C04-PI", "feature": "C04", "stack": "PI", "status": "Y", "reason": "The selected known-identity PRP composition includes a credential-gated handshake defense. In pinned kernel source, hs2_observe_scoped first verifies the HS2 cryptographic proof and then matches the derived strong identity against an unexpired expected identity for the context/scope/alias before allocating negotiation state. A different identity returns EKEYREJECTED; the carrier-bootstrap fallback applies to ENOKEY, not a mismatch against an existing expectation. The inspected rejection path reports through local generic netlink, not a carrier response. For an already protected adjacency, authentication failure returns before public-control parsing. Credit the existence of this bounded defense, consistently with C04 cells that retain documented admission exceptions.", "method": "Source-level evidence of a bounded defense; prior local admission experiment retained with explicit limits", "source_label": "Pinned prp-linux-kmod d90a712c6d36111de66bcdd7be8e0f462bf539ae: handshake proof, expected-identity admission, local rejection diagnostics and RX dispatch", "sources": [], "editorial_references": [ "round362-sources.json", "round361-review.json", "round360-sources.json" ], "qualification": "Requires a valid expected-identity binding in the already selected known-identity mode. This is not silence for every probe or every endpoint state. Missing/expired identity expectations may allow identity learning on valid carrier-bootstrap contexts; the public PoW challenge can remain recognizable before requester authentication, as the previous local harness demonstrated with TX stubbed. Locator/context matching is not itself cryptographic authentication. No network/timing/replay-resistance experiment, constant-time claim, universal camouflage, DoS immunity or whole-stack certification. Any runtime controller reactions and carrier-driver replies remain outside this source-level witness. Criterion and profiles unchanged." }, { "id": "C04-IP", "feature": "C04", "stack": "IP", "status": "N", "reason": "The selected IP/ICMP service includes no credential-gated camouflage or active-probe resistance mechanism. An external filtering policy is not included.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "C04-BP", "feature": "C04", "stack": "BP", "status": "N", "reason": "RFC 9174 section 4.1 requires the passive entity to return a Contact Header before TLS after receiving one from the active entity. This public protocol/version exchange supplies a concrete uncredentialed probe distinguisher in the selected standard profile. Resource-admission safeguards do not hide that response.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.1" ], "editorial_references": [], "qualification": "" }, { "id": "C04-CG", "feature": "C04", "stack": "CG", "status": "N", "reason": "TCPCL exchanges its recognizable Contact Header before TLS authentication. A valid unauthenticated header elicits the passive peer header, including the dtn! marker. Rejecting malformed headers or later rejecting certificates does not conceal the service from this valid probe. No additional probe-concealment layer is selected.", "method": "Documentary review; no new runtime experiment", "source_label": "Primary specification and bounded profile inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.1" ], "editorial_references": [], "qualification": "Capture valid and malformed probes against the selected executable; this documentary No does not claim access through an external firewall." }, { "id": "C04-LT", "feature": "C04", "stack": "LT", "status": "N", "reason": "In the selected bidirectional profile, LTP cancellation processing can return a cancel acknowledgment before any BP payload authentication. RFC 5326 section 6.17 queues the response when the corresponding return queue exists, including when session state has already gone. BPSec authenticates bundle content, not these LTP control segments; no adjacent authentication or probe-concealment extension is selected.", "method": "Primary-specification analysis; no probe execution", "source_label": "RFC 5326 sections 6.17 and 9; selected security boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html#section-6.17" ], "editorial_references": [], "qualification": "Exercise valid control probes on an admitted adjacent channel with a configured return queue. Record timing and responses. This does not assert reachability from arbitrary radio transmitters or unconfigured engines." }, { "id": "C04-LP", "feature": "C04", "stack": "LP", "status": "N", "reason": "The selected ordinary QUIC handshake has publicly derivable Initial protection and recognizable protocol responses before mutual certificate authentication completes. No secret-gated camouflage transport is selected. Retry/address validation addresses spoofing and amplification, not protocol concealment. This is a scope inference, not a measured fingerprinting success rate or a claim that every probe receives a reply.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9001#section-7" ], "editorial_references": [], "qualification": "" }, { "id": "C04-TO", "feature": "C04", "stack": "TO", "status": "N", "reason": "Public Tor channels negotiate VERSIONS and relay certificates with unauthenticated clients. The selected public-relay profile has no pluggable camouflage transport. This does not classify obfs4 or other bridge compositions.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://spec.torproject.org/tor-spec/negotiating-channels.html" ], "editorial_references": [], "qualification": "" }, { "id": "C04-I2", "feature": "C04", "stack": "I2", "status": "Y", "reason": "NTCP2 AEAD Error Handling explicitly specifies probing-resistance behavior: on initial authentication failure, delayed closing with randomized timeout and read length, plus repeated-failure blacklisting. This credits a stated defense; ranges remain TBD and deployment efficacy is not established.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "Pin an implementation and its timeout/read ranges, then evaluate probe distinguishability and false positives. The specification leaves those ranges TBD." }, { "id": "C04-YG", "feature": "C04", "stack": "YG", "status": "N", "reason": "The selected TLS listener offers an ordinary TLS handshake with tls.NoClientCert. Later key admission does not supply secret-gated camouflage of that opening exchange. This does not mean that Yggdrasil peer identity verification is absent.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/tls.go" ], "editorial_references": [], "qualification": "" }, { "id": "C04-CJ", "feature": "C04", "stack": "CJ", "status": "Y", "reason": "The listener invokes tryHandshake with require_auth=true; ordinary CryptoAuth and Noise admission reject missing or unknown credentials. This supplies a secret-gated response defense under normal admission. The Noise load-defense path can return a cookie before user authorization, so the credit does not imply silence for every unauthenticated probe or complete protocol indistinguishability.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/crypto/crypto_noise.rs#L685" ], "editorial_references": [], "qualification": "Capture invalid, valid-public-key/no-password, guessed-credential and replayed probes in idle and overloaded states. Inspect pre-authorization cookies, known-peer handling and driver replies. Selected UDP peering uses private credentials without public beacon advertisement; no probe experiment performed." }, { "id": "C04-MQ", "feature": "C04", "stack": "MQ", "status": "N", "reason": "The selected ordinary QUIC handshake has publicly derivable Initial protection and recognizable protocol responses before mutual certificate authentication completes. No secret-gated camouflage transport is selected. Retry/address validation addresses spoofing and amplification, not protocol concealment. This is a scope inference, not a measured fingerprinting success rate or a claim that every probe receives a reply.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9001#section-7" ], "editorial_references": [], "qualification": "" }, { "id": "C04-SC", "feature": "C04", "stack": "SC", "status": "N", "reason": "The selected ordinary SCION/UDP profile includes recognizable SCMP echo/error exchanges and no secret-gated concealment layer. Hop-field authentication is not a mechanism for hiding the protocol from a prober with a usable path. This is a scope decision, not a guarantee that every malformed probe receives a reply.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://docs.scion.org/en/latest/protocols/scmp.html" ], "editorial_references": [], "qualification": "" }, { "id": "C04-RT", "feature": "C04", "stack": "RT", "status": "Y", "reason": "In the already selected secret-IFAC serial profile, preprocess_inbound rejects missing or invalid access codes before packet parsing. The base interface violation handler only counts/logs locally. This supplies a secret-gated defense against eliciting protocol replies, not universal camouflage or constant-time processing.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Transport.py#L1753" ], "editorial_references": [], "qualification": "Capture invalid, missing, replayed and guessed IFAC probes on the selected serial interface; inspect driver responses and timing. Tag length, secret quality and replay handling limit the defense. No active probing performed." }, { "id": "C04-NS", "feature": "C04", "stack": "NS", "status": "N", "reason": "The selected public TLS/WebSocket service exposes an ordinary opening handshake without a secret-gated camouflage layer. Server authentication does not conceal the service from an initiating prober. This scope decision does not assert a measured fingerprinting rate.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://datatracker.ietf.org/doc/html/rfc6455#section-4.2" ], "editorial_references": [], "qualification": "" }, { "id": "C04-MT", "feature": "C04", "stack": "MT", "status": "N", "reason": "In the explicitly selected CLIENT/ALL relay mode, a valid outer radio packet with an unknown channel hash can take DECODE_OPAQUE and OPAQUE_RELAY_ONLY. The receive path invokes relayOpaquePacket before module delivery. With a fresh nonzero packet ID, remaining hops, a nonlocal sender/destination and no next-hop restriction, it copies the packet, decrements hop_limit, writes the relay-node byte and sends. The sender need not know the private channel key or supply a valid payload signature for this branch. This permits an observable, protocol-shaped relay response to a chosen probe despite private-channel/STRICT protection of decoded content. Those protections remain real, but do not conceal this whole listening relay. Muting, different relay policy, packet filters, airtime/queue limits and radio failure can suppress a particular response; no universal response or measured fingerprint success rate is asserted.", "method": "Pinned primary-source control-flow inspection; no firmware execution or RF capture", "source_label": "Meshtastic firmware 8e6a88d: Router, NextHopRouter, FloodingRouter and NodeDB", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NodeDB.cpp" ], "editorial_references": [], "qualification": "In an isolated compatible radio setup, keep CLIENT/ALL, private channel and STRICT. Inject a fresh bounded packet on a hash matching no local channel, with nonzero hop limit, broadcast destination and no next-hop preference; ensure sender is neither local nor ignored. Capture the relayed header/ciphertext and distinguish it from autonomous traffic using the chosen packet ID. Compare zero-hop, muted and invalid-signature matching-channel controls. Do not claim any payload delivery, PKI bypass or amplification measurement." }, { "id": "C04-GN", "feature": "C04", "stack": "GN", "status": "N", "reason": "The selected GNUnet 0.20.0 UDP TRANSPORT profile exposes address validation before a CORE/CADET application relationship. A well-formed PING naming the target public peer identity and a valid advertised UDP address reaches GST_validation_handle_ping; it constructs a signed PONG and sends through the transport plugin. The probe needs public target information, not the target private key or an application credential. Wrong-target/address probes may be dropped, and peer blacklisting can deny sessions; these are not a selected secret-gated camouflage mechanism. This is a bounded documentary counterexample to protocol-concealment credit, not proof that every scanner receives a response or that payload authentication is absent. Fragment ACK behavior is supplementary evidence only, not the basis of this verdict.", "method": "Primary-source control-flow analysis and bounded composition inference; no protocol execution", "source_label": "GNUnet 0.20.0 UDP receive path, TRANSPORT dispatch and address-validation source", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html", "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round120-sources.json" ], "qualification": "On the selected ordinary UDP listener, send a correctly formed address-validation PING for its known public identity/address from a fresh, non-blacklisted peer. Capture signed PONG and compare wrong target/address, replay and control-service cases. Verify blacklist lifecycle separately. No probe execution or measured fingerprint success rate claimed." }, { "id": "C04-ND", "feature": "C04", "stack": "ND", "status": "N", "reason": "For a reachable ordinary content service, an uncredentialed peer can send an unsigned Interest for a known available name and receive recognizable NDN Data, including a cache response. The selected plain Ethernet NFD profile adds no secret admission or camouflage to that path. A silent missing-name result and authenticated management commands do not protect this successful content probe. This is a mechanism decision, not a measured fingerprinting rate or a claim that every node answers every probe.", "method": "Pinned source and specification analysis; no execution", "source_label": "NFD 24.07 onIncomingInterest and onContentStoreHit", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp", "https://docs.named-data.net/NDN-packet-spec/0.3/interest.html" ], "editorial_references": [], "qualification": "" }, { "id": "C04-AX", "feature": "C04", "stack": "AX", "status": "N", "reason": "A classic NET/ROM Connect Request elicits a recognizable acceptance or refusal without cryptographic authentication. Callsigns, circuit fields and flow-control flags supply no secret probe gate or camouflage. This identifies a protocol response opportunity, not a claim that every node answers under every operating policy.", "method": "Primary protocol and pinned source analysis; no execution", "source_label": "NET/ROM transport: Connect Request and Connect Acknowledge, pp. 1–2", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "C04-BA", "feature": "C04", "stack": "BA", "status": "N", "reason": "Linux 6.12 batadv_recv_icmp_packet dispatches locally addressed diagnostic requests to batadv_recv_my_icmp_packet. The ECHO_REQUEST branch returns ECHO_REPLY when a primary interface and route to the originating mesh node exist. MAC validity, packet-size and route checks are not cryptographic credentials. A reachable participant on the selected unprotected mesh can therefore elicit a recognizable native diagnostic response. This is batman-adv ICMP, not IP ICMP; Internet reachability and guaranteed replies from unknown origins are not claimed.", "method": "Primary protocol and pinned source analysis; no execution", "source_label": "Linux 6.12 native batman-adv diagnostic receive path", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c", "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "C04-BL", "feature": "C04", "stack": "BL", "status": "N", "reason": "RFC 8966 section 3.8.1.1 requires an update or retraction in response to a valid specific-prefix Route Request; wildcard requests can elicit a rate-limited table dump. The selected profile excludes Babel MAC/DTLS authentication and external filtering. A reachable link neighbor can obtain a recognizable control response without a secret credential. This does not make Babel control reachable from every Internet host; it establishes the absence of the tested probe defense on its actual access scope. IPv6 echo behavior is not needed for this decision.", "method": "Primary protocol and pinned source analysis; no execution", "source_label": "RFC 8966 request handling and security considerations", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.8.1.1", "https://www.rfc-editor.org/rfc/rfc8966.html#section-6" ], "editorial_references": [], "qualification": "" }, { "id": "C04-RI", "feature": "C04", "stack": "RI", "status": "N", "reason": "The selected ordinary DTLS handshake includes no specified camouflage or secret-gated probe-concealment policy. Its optional recognizable HelloRetryRequest/cookie exchange verifies address reachability and limits spoofing/amplification; it is not an active-probe identification defense.", "method": "Documentary mechanism review; no active probing or runtime test", "source_label": "CCNx request-state semantics and HIP/DTLS handshake specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html#section-5.1" ], "editorial_references": [ "round266-sources.json" ], "qualification": "Evaluate an adversary able to reach the service on the admitted link but lacking the final-peer PSK. PSK authentication protects session admission, not a demonstrated indistinguishable response policy. This does not assert that every invalid binder triggers a reply or that custom implementations cannot suppress responses." }, { "id": "C04-HP", "feature": "C04", "stack": "HP", "status": "N", "reason": "The ordinary HIP base exchange sends recognizable R1 puzzle, key and signature material before validating the initiator proof in I2. The selected profile has no secret-gated camouflage mechanism to conceal HIP from a reachable prober.", "method": "Documentary mechanism review; no active probing or runtime test", "source_label": "CCNx request-state semantics and HIP/DTLS handshake specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-4.1" ], "editorial_references": [ "round266-sources.json" ], "qualification": "The puzzle limits computational abuse; it does not conceal the protocol. Local policy can reject some I1 messages, so this is not a claim that every probe receives a reply. Pinned peer admission is not proof of pre-authentication protocol concealment." }, { "id": "C04-CX", "feature": "C04", "stack": "CX", "status": "N", "reason": "A reachable selected CCNx content service can answer a CRC32C Interest for a known available name with a recognizable Content Object. No consumer secret is required by this profile, including for cache responses.", "method": "Documentary mechanism review; no active probing or runtime test", "source_label": "CCNx request-state semantics and HIP/DTLS handshake specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.3" ], "editorial_references": [ "round266-sources.json" ], "qualification": "Silent handling of unknown names or malformed packets does not protect a successful known-content probe. This evaluates the selected mechanism, not a measured identification rate or universal response behavior." }, { "id": "C04-LI", "feature": "C04", "stack": "LI", "status": "N", "reason": "The selected public-format Map-Request/Map-Reply and RLOC-probing exchanges are not preceded by a secret-gated camouflage mechanism. Map-Register authentication protects updates, not indistinguishability of the exposed LISP control service. Neither endpoint access filtering nor LISP-SEC is selected as an anti-identification mechanism.", "method": "Specification review; unchanged selected profile", "source_label": "rfc9301.html#section-5.3; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-5.3", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "No active scan or timing test was performed. Administrative firewalls could suppress exposure but are not a native anti-identification mechanism in this selected composition." }, { "id": "C04-IL", "feature": "C04", "stack": "IL", "status": "N", "reason": "The selected nonce protocol deliberately advertises ILNP mode during initial session establishment. A new correspondent need not possess a pre-shared credential before attempting that exchange. Validation of an existing session nonce protects against off-path injection; it does not provide protocol camouflage against an uncredentialed initiator.", "method": "Specification review; unchanged selected profile", "source_label": "rfc6744.html#section-5.2; rfc6744.html#section-6", "sources": [ "https://www.rfc-editor.org/rfc/rfc6744.html#section-5.2", "https://www.rfc-editor.org/rfc/rfc6744.html#section-6" ], "editorial_references": [], "qualification": "No live probing was performed. This is a selected-protocol design conclusion, not a claim that every packet necessarily receives a response." }, { "id": "C04-TS", "feature": "C04", "stack": "TS", "status": "Y", "reason": "The WireGuard receive path silently discards handshake packets with an invalid MAC1. Normal handshake replies require a valid known-peer initiation. This provides a concrete defense against blind active probing of the endpoint.", "method": "Pinned receive-path inspection and primary protocol documentation; no runtime test", "source_label": "Tailscale wireguard-go dependency, MAC1 and cookie branches", "sources": [ "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://www.wireguard.com/protocol/", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/magicsock.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go", "https://tailscale.com/docs/reference/derp-servers" ], "editorial_references": [ "round592.html", "round592-sources.json" ], "qualification": "Bounded defense, not universal invisibility. A prober knowing the responder public key can form MAC1 and may obtain an under-load cookie response without being an authorized peer. Replay, timing and other exposed services require separate assessment. No active scan was executed; public DERP/control servers are not hidden by this endpoint mechanism." }, { "id": "C04-RA", "feature": "C04", "stack": "RA", "status": "N", "reason": "The selected native Ethernet shim registers its application name as a protocol address in RINARP. The ARP_REQUEST handler checks its target-name table and sends a RINARP reply when the target is present, without requiring the normal DIF AuthSSH2 credential. An uncredentialed participant able to send frames on that Ethernet segment and knowing a registered target name can therefore elicit a protocol-specific reply before normal-DIF admission. Normal-DIF encryption does not cover this discovery exchange.", "method": "Pinned native registration and unauthenticated discovery-response trace", "source_label": "IRATI Ethernet shim and RINARP request handler", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rinarp/arp826-rxtx.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/ipcps/shim-eth-core.c" ], "editorial_references": [ "round675.html" ], "qualification": "No for active-probe identification resistance across the selected native stack. This is a valid known-name discovery probe on the local Ethernet segment, not an Internet-wide scan, a guarantee of enumeration, or proof that arbitrary invalid/replayed authentication probes receive replies. Link access is a prerequisite; a separately protected link can restrict the observer. The reply identifies the RINA discovery service, not a civil identity or permission to exchange protected application payload. Source-level result; no packet capture or timing experiment performed." }, { "id": "C05-PN", "feature": "C05", "stack": "PN", "status": "Y", "reason": "Architecture 5.6 and Bootstrap Reachability sections 3.1 and 7.1 permit local carrier candidates with expected identities and HS2, without DNS. The selected realization uses locally known identities and native link candidates or numeric IPv4 peers. Optional DNS references are excluded. No arbitrary remote discovery, protected referral or cold-start Internet reachability is claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "C05-PI", "feature": "C05", "stack": "PI", "status": "Y", "reason": "Architecture 5.6 and Bootstrap Reachability sections 3.1 and 7.1 permit local carrier candidates with expected identities and HS2, without DNS. The selected realization uses locally known identities and native link candidates or numeric IPv4 peers. Optional DNS references are excluded. No arbitrary remote discovery, protected referral or cold-start Internet reachability is claimed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "C05-IP", "feature": "C05", "stack": "IP", "status": "Y", "reason": "The numeric-address profile uses provisioned addresses and routing configuration; DNS is not a prerequisite for packet forwarding or startup.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-BP", "feature": "C05", "stack": "BP", "status": "Y", "reason": "The selected numeric-peer/local-trust profiles do not require DNS. This carries F17 into a DNS-outage scenario; no execution test was run.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "matrix.html#e-F17-BP" ], "qualification": "" }, { "id": "C05-CG", "feature": "C05", "stack": "CG", "status": "Y", "reason": "Startup uses supplied numeric peers, contact plans and local trust; it needs no DNS cache or lookup in this declared profile.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9174, TCPCLv4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "C05-LT", "feature": "C05", "stack": "LT", "status": "Y", "reason": "The declared preplaced plans, engine mappings and keys support startup without DNS lookup or cache.", "method": "Primary-specification analysis of the explicit composition; no runtime execution", "source_label": "LTP specification, RFC 5326", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html" ], "editorial_references": [], "qualification": "Pin and validate the complete BPv7/SABR/LTP/Encapsulation/AOS executable composition, including security and local management. Documentary capability is not conformance or measured service." }, { "id": "C05-LP", "feature": "C05", "stack": "LP", "status": "Y", "reason": "The selected numeric-peer/local-trust profiles do not require DNS. This carries F17 into a DNS-outage scenario; no execution test was run.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "matrix.html#e-F17-LP" ], "qualification": "" }, { "id": "C05-TO", "feature": "C05", "stack": "TO", "status": "Y", "reason": "Tor directory bootstrap supports built-in numeric fallback addresses and identity fingerprints; onion-v3 names encode service keys rather than requiring DNS resolution. This credits the selected onion-service use, with reachable directory infrastructure. It does not remove directory authorities or cover ordinary DNS-named websites accessed through exits.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://torproject.gitlab.io/torspec/dir-list-spec.html" ], "editorial_references": [], "qualification": "Pin a Tor build with usable numeric fallbacks and bootstrap with an empty DNS cache and DNS disabled. Confirm onion-v3 access; no runtime test was executed. Onion address encoding: https://spec.torproject.org/rend-spec/encoding-onion-addresses.html" }, { "id": "C05-I2", "feature": "C05", "stack": "I2", "status": "Y", "reason": "The selected profile now starts from a locally supplied fresh RouterInfo bundle with reachable numeric NTCP2 contacts, known destination keys and a correct local clock. Official file reseeding avoids an online reseed service; no external DNS naming or time service is selected. This is not cold discovery from zero information or a claim about default online reseeding.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/blog/2020/06/07/help-your-friends-join-i2p-by-sharing-reseed-bundles/" ], "editorial_references": [], "qualification": "Pin a router build and file bootstrap configuration, disable DNS/online reseed and external time queries, and verify fresh RouterInfo admission plus NTCP2 tunnel establishment. Test stale/unreachable contacts separately. No runtime test was executed." }, { "id": "C05-YG", "feature": "C05", "stack": "YG", "status": "Y", "reason": "The selected Yggdrasil profile uses documented numeric TLS peer URLs with pinned peer public keys and no DNS-based application naming. Local key generation and numeric peering remove external DNS from bootstrap and traffic; this does not claim reachability without configured peers or underlay connectivity.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/configurationref.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-CJ", "feature": "C05", "stack": "CJ", "status": "Y", "reason": "The selected cjdns UDP profile uses numeric peer addresses, known public keys and locally exchanged peering credentials. Its generated overlay IPv6 addresses can be used directly by the application. No DNS lookup is required in this composition; hostname-based services would be a different choice.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md" ], "editorial_references": [], "qualification": "" }, { "id": "C05-MQ", "feature": "C05", "stack": "MQ", "status": "Y", "reason": "The profile uses numeric peers, directly provisioned certificate trust and no SNI requirement or online certificate service. QUIC authentication is retained without a DNS lookup. This scoped inference does not apply to arbitrary hostname-based Internet services.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9001#section-4.4" ], "editorial_references": [], "qualification": "" }, { "id": "C05-SC", "feature": "C05", "stack": "SC", "status": "Y", "reason": "With numeric topology and endpoint addresses plus local trust/time already provisioned, the selected SCION bootstrap does not depend on an external DNS cache or service. This does not remove control infrastructure or its availability requirements.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://docs.scion.org/en/latest/manuals/common.html#topology-json" ], "editorial_references": [], "qualification": "" }, { "id": "C05-RT", "feature": "C05", "stack": "RT", "status": "Y", "reason": "Serial operation uses destination hashes and announcements, without external DNS.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/understanding.html#public-key-announcements" ], "editorial_references": [], "qualification": "" }, { "id": "C05-NS", "feature": "C05", "stack": "NS", "status": "N", "reason": "The selected WSS hostname profile cannot initialize with DNS unavailable and an empty cache.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "matrix.html#e-F17-NS" ], "qualification": "" }, { "id": "C05-MT", "feature": "C05", "stack": "MT", "status": "Y", "reason": "The selected local radio/key bootstrap can start with no DNS cache or resolver. Peers still need compatible radio settings and the stated key knowledge.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/introduction/" ], "editorial_references": [], "qualification": "" }, { "id": "C05-GN", "feature": "C05", "stack": "GN", "status": "Y", "reason": "Locally supplied numeric HELLO contacts permit bootstrap without DNS; deployment of that configuration remains untested.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "GNUnet TRANSPORT handbook, v0.20.x; current introductory sections only", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html" ], "editorial_references": [], "qualification": "Verify startup with locally supplied contacts and online hostlist/NAT helpers disabled; no integration test performed." }, { "id": "C05-ND", "feature": "C05", "stack": "ND", "status": "Y", "reason": "Ethernet/Unix face setup and the locally supplied route/key state can initialize without a DNS cache.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 face management", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-AX", "feature": "C05", "stack": "AX", "status": "Y", "reason": "Configured callsign ports and local routing broadcasts do not require a DNS cache to start.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux AX.25 HOWTO: NET/ROM port configuration", "sources": [ "https://tldp.org/HOWTO/AX25-HOWTO/x1218.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-BA", "feature": "C05", "stack": "BA", "status": "Y", "reason": "The selected local interface/MAC bootstrap has no DNS cache dependency.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-BL", "feature": "C05", "stack": "BL", "status": "Y", "reason": "Provisioned IPv6 interfaces bootstrap Babel neighbors without DNS lookup.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-RI", "feature": "C05", "stack": "RI", "status": "Y", "reason": "The selected RPL/6LoWPAN deployment uses a locally provisioned ULA prefix, numeric final-peer addresses and locally provisioned pairwise DTLS PSKs. Initial route formation and peer authentication therefore require no external DNS cache or service.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-3" ], "editorial_references": [ "round262-sources.json" ], "qualification": "Ordinary link admission, neighbor registration, a reachable RPL root and correct PSKs remain prerequisites. No cloud provisioning or certificate lookup is introduced. Runtime cold-start capture remains unperformed." }, { "id": "C05-HP", "feature": "C05", "stack": "HP", "status": "Y", "reason": "The selected bootstrap uses known numeric locators and locally pinned peer Host Identities/HITs. It can perform the HIP base exchange without resolving DNS records or fetching external trust material.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-4.1" ], "editorial_references": [ "round262-sources.json" ], "qualification": "Requires the declared local configuration and reachable peer. This does not establish arbitrary remote discovery, simultaneous-mobility recovery or reachability when all configured peers are blocked. Runtime DNS-blocked startup remains untested." }, { "id": "C05-CX", "feature": "C05", "stack": "CX", "status": "Y", "reason": "Numeric adjacent UDP forwarders, locally configured name-prefix routes, known content names and preprovisioned trusted producer keys supply the selected CCNx initial state without DNS. No external key lookup is needed for this composition.", "method": "Documentary packet and dependency inventory; no traffic capture", "source_label": "Primary specifications and explicitly configured bootstrap/trust profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.2" ], "editorial_references": [ "round262-sources.json" ], "qualification": "This is configured bootstrap, not automatic global content discovery. Missing names/routes/keys or blocked configured forwarders can still prevent communication. Runtime DNS-disabled startup remains untested." }, { "id": "C05-LI", "feature": "C05", "stack": "LI", "status": "Y", "reason": "Cold bootstrap can use the provisioned numeric Map-Resolver/Map-Server and peer addresses, plus local registration keys. EID mapping queries do not require an external DNS response in this declared profile.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9301.html#section-4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-4" ], "editorial_references": [], "qualification": "Exercise cold caches with external DNS unavailable; preserve the explicitly provisioned numeric contacts." }, { "id": "C05-IL", "feature": "C05", "stack": "IL", "status": "N", "reason": "With no cached peer information, the selected DNS-based discovery requires the relevant DNS response. No pre-provisioned peer I-L vectors or local DNS alternative is selected; Locator Updates maintain existing communications rather than replace this bootstrap.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html#section-4.4; rfc6742.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc6742.html" ], "editorial_references": [], "qualification": "" }, { "id": "C05-TS", "feature": "C05", "stack": "TS", "status": "N", "reason": "The selected fresh user-enrollment flow requires the managed login page and an external identity provider in a web browser. With external DNS unavailable and no name cache or pre-provisioned authentication key, that browser cannot resolve the required service names. The daemon-specific bootstrap resolver does not provision name resolution for the browser and identity-provider flow. The complete selected bootstrap therefore does not meet C05.", "method": "Primary enrollment documentation and scoped bootstrap dependency analysis; no runtime test", "source_label": "Tailscale identity, Linux installation and auth-key documentation", "sources": [ "https://tailscale.com/docs/concepts/tailscale-identity", "https://tailscale.com/docs/install/linux", "https://tailscale.com/docs/features/access-control/auth-keys" ], "editorial_references": [ "round590-sources.json", "round594.html", "round594-sources.json" ], "qualification": "Documentary dependency inference, not an executed outage test. This is initial interactive user enrollment, not already enrolled nodes reconnecting. Pre-provisioned auth keys can bypass browser login and constitute a different initial state; they are not assumed here. Tailscale has a numeric-address HTTPS bootstrap resolver for its own control connectivity, so failure of ordinary DNS alone does not imply that all daemon connectivity fails. No claim that every Tailscale provisioning method requires a live browser or ordinary DNS." }, { "id": "C05-RA", "feature": "C05", "stack": "RA", "status": "Y", "reason": "With local configuration and participant enrollment already specified, the native Ethernet-shim profile starts and resolves registered application names inside its DIF without external DNS. Tutorial 1 uses local configuration files and a Unix-domain management console; the selected stack includes no DNS-dependent IP shim. No DNS cache is required.", "method": "Primary tutorial, configuration and implementation-source assessment; no execution", "source_label": "IRATI native bootstrap and two-provider mobility documentation", "sources": [ "https://raw.githubusercontent.com/wiki/IRATI/stack/Tutorial-1%3A-DIF-over-a-VLAN-%28point-to-point-DIF%29.md", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/ipcm.conf" ], "editorial_references": [ "round658.html" ], "qualification": "Architectural bootstrap Yes for this locally provisioned composition. Initial software acquisition and configuration distribution are prerequisites. This does not imply operation when every peer is blocked; DNS-disabled execution was not repeated." }, { "id": "C06-PN", "feature": "C06", "stack": "PN", "status": "Y", "reason": "For C06 explicitly select the author-approved successor fast-path architecture, rather than importing its properties into retained wire-v4 onion framing. TPA candidate section 7 scopes selectors to each hop and realization, without global context-ID semantics or mandatory full-path disclosure. Successor proposal section 10 carries opaque requester-to-current-peer communication over installed scoped state and forbids an intermediate aggregator from terminating that protected session on the requester's behalf. The author confirms that the identity used with the aggregator does not reveal the distinct identity used in the protected fast path. In this established, protected composition, visible local forwarding selectors identify a segment operation rather than the final identity pair; final-channel identities remain within that channel. This supports Yes at the architectural/documentary level used for the matrix's other bounded witnesses.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "TPA hop-local semantics, successor protected forwarding and author identity-scope clarification", "sources": [], "editorial_references": [ "round578.html#C06-PN", "round578.html", "round578-sources.json" ], "qualification": "Criterion-specific architectural witness: established authorized fast paths, hop-local selectors and protected adjacency/final channels with distinct scoped identities; no deliberately exported identity binding or diagnostic route map. An intermediate observes its own neighboring peers and local input/output mapping; the final endpoint knows its own authenticated peer. These are not a global final-peer identifier. The conclusion does not assert traffic unlinkability against timing, volume or combined external identity disclosures; timing/volume belongs to C07. Exact wire encoding, installation, bootstrap and implementation/security admission remain separately unqualified. The selected C06 successor witness is recorded explicitly in both column descriptions; other criteria retain their existing profiles and evidence. It does not retroactively qualify the historical onion annex." }, { "id": "C06-PI", "feature": "C06", "stack": "PI", "status": "Y", "reason": "For C06 explicitly select the author-approved successor fast-path architecture, rather than importing its properties into retained wire-v4 onion framing. TPA candidate section 7 scopes selectors to each hop and realization, without global context-ID semantics or mandatory full-path disclosure. Successor proposal section 10 carries opaque requester-to-current-peer communication over installed scoped state and forbids an intermediate aggregator from terminating that protected session on the requester's behalf. The author confirms that the identity used with the aggregator does not reveal the distinct identity used in the protected fast path. In this established, protected composition, visible local forwarding selectors identify a segment operation rather than the final identity pair; final-channel identities remain within that channel. This supports Yes at the architectural/documentary level used for the matrix's other bounded witnesses.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "TPA hop-local semantics, successor protected forwarding and author identity-scope clarification", "sources": [], "editorial_references": [ "round578.html#C06-PI", "round578.html", "round578-sources.json" ], "qualification": "Criterion-specific architectural witness: established authorized fast paths, hop-local selectors and protected adjacency/final channels with distinct scoped identities; no deliberately exported identity binding or diagnostic route map. An intermediate observes its own neighboring peers and local input/output mapping; the final endpoint knows its own authenticated peer. These are not a global final-peer identifier. The conclusion does not assert traffic unlinkability against timing, volume or combined external identity disclosures; timing/volume belongs to C07. Exact wire encoding, installation, bootstrap and implementation/security admission remain separately unqualified. The selected C06 successor witness is recorded explicitly in both column descriptions; other criteria retain their existing profiles and evidence. It does not retroactively qualify the historical onion annex. IPv4/UDP addresses remain visible for each carrier segment. The witness uses intermediate PRP forwarding and protected distinct final identities; a direct IP path exposing the actual final locator pair is not this witness." }, { "id": "C06-IP", "feature": "C06", "stack": "IP", "status": "N", "reason": "The selected unencapsulated IPv4/IPv6 service carries source and destination addresses in the visible packet header. An observer on the routed path can associate that communicating address pair within the traffic. Rotating the source between contexts does not hide the pair during a communication.", "method": "Primary documentary assessment under revised criterion; no runtime experiment", "source_label": "Pinned PRP architecture worktree and IP RFCs", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc8200.html#section-3" ], "editorial_references": [ "round488.html", "round488-sources.json" ], "qualification": "This column selects raw IP/ICMP, not application TCP/UDP, so transport ports are not required for this finding. The exposed address pair suffices; no legal-person identification or timing inference is assumed. The old temporary-address configuration remains part of the profile but no longer satisfies revised C06. No IPsec or privacy tunnel is silently added." }, { "id": "C06-BP", "feature": "C06", "stack": "BP", "status": "N", "reason": "The selected identified-source BPv7 traffic carries the destination EID and original source-node ID in the primary block. BPSec can authenticate this block but cannot encrypt it with a BCB. A forwarding bundle node therefore reads the final-pair references without the final payload keys; those references persist across bundle hops.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP primary blocks and routed IPv6 headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.3.1", "https://www.rfc-editor.org/rfc/rfc9172.html#section-3.8" ], "editorial_references": [ "round499.html", "round499-sources.json" ], "qualification": "Observation is at a participating bundle forwarder. TCPCL TLS protects the link from an outsider without traffic keys, but terminates at the bundle nodes. Independent identities between contexts do not hide the pair within a communication. BP permits a null anonymous source in other configurations; that is not the selected exact-origin authenticated composition and is not credited here. This verdict does not expose civil identities or encrypted payload contents." }, { "id": "C06-CG", "feature": "C06", "stack": "CG", "status": "N", "reason": "The selected identified-source BPv7 traffic carries the destination EID and original source-node ID in the primary block. BPSec can authenticate this block but cannot encrypt it with a BCB. A forwarding bundle node therefore reads the final-pair references without the final payload keys; those references persist across bundle hops.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP primary blocks and routed IPv6 headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.3.1", "https://www.rfc-editor.org/rfc/rfc9172.html#section-3.8" ], "editorial_references": [ "round499.html", "round499-sources.json" ], "qualification": "Observation is at a participating bundle forwarder. TCPCL TLS protects the link from an outsider without traffic keys, but terminates at the bundle nodes. Independent identities between contexts do not hide the pair within a communication. BP permits a null anonymous source in other configurations; that is not the selected exact-origin authenticated composition and is not credited here. This verdict does not expose civil identities or encrypted payload contents." }, { "id": "C06-LT", "feature": "C06", "stack": "LT", "status": "N", "reason": "The selected identified-source BPv7 traffic carries the destination EID and original source-node ID in the primary block. BPSec can authenticate this block but cannot encrypt it with a BCB. A forwarding bundle node therefore reads the final-pair references without the final payload keys; those references persist across bundle hops.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP primary blocks and routed IPv6 headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9171.html#section-4.3.1", "https://www.rfc-editor.org/rfc/rfc9172.html#section-3.8" ], "editorial_references": [ "round499.html", "round499-sources.json" ], "qualification": "Observation is at a participating bundle forwarder. The selected LTP/Encapsulation/AOS binding adds no primary-block confidentiality. Independent identities between contexts do not hide the pair within a communication. BP permits a null anonymous source in other configurations; that is not the selected exact-origin authenticated composition and is not credited here. This verdict does not expose civil identities or encrypted payload contents." }, { "id": "C06-LP", "feature": "C06", "stack": "LP", "status": "N", "reason": "libp2p over direct QUIC protects transport payloads, but the selected direct IP/UDP connection exposes the source and destination network addresses and UDP ports on each used path. The observer can associate the final communicating endpoints without decrypting application data or recovering a peer public key.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-12", "https://www.rfc-editor.org/rfc/rfc9000.html#section-9.5", "https://www.rfc-editor.org/rfc/rfc8200.html#section-3" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "Connection-ID rotation, path migration and distinct identity keys do not conceal the address pair of the observed direct path. This is not a claim of unconditional cross-path linkage through a reused connection ID. No privacy relay, VPN or anonymity overlay is selected; authenticated peer identity and real-world identity are not required for the address-pair finding." }, { "id": "C06-TO", "feature": "C06", "stack": "TO", "status": "Y", "reason": "Tor CircIDs are channel-local and change across the channels of a multi-hop circuit. Relay-message bodies, including StreamIDs, receive layered encryption. In the selected onion-service path, rendezvous joins two circuits without putting the client and service identity pair into a common visible end-to-end forwarding identifier.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Tor channel-local circuit IDs and pinned cjdns session handles", "sources": [ "https://spec.torproject.org/tor-spec/cell-packet-format.html", "https://spec.torproject.org/tor-spec/routing-relay-cells.html", "https://spec.torproject.org/tor-spec/relay-cells.html", "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [ "round501.html", "round501-sources.json" ], "qualification": "An authorized relay knows its adjacent peers and local circuit mappings; a rendezvous node knows which two circuits it joins. These facts do not disclose the final identity pair in ordinary forwarding fields. This does not protect against compromised endpoints, collusion reconstructing all circuit mappings, active attacks or timing/volume correlation. The result is for onion services, not plaintext exit traffic, and does not independently qualify optional Conflux deployment." }, { "id": "C06-I2", "feature": "C06", "stack": "I2", "status": "Y", "reason": "I2P uses hop-local tunnel IDs. Each participant transforms the IV and encrypted tunnel data and sends the next tunnel ID, rather than preserving one visible identifier across the tunnel. The selected multi-hop outbound tunnel separates its originating router from the outbound endpoint that sees onward delivery instructions; the receiving tunnel continues delivery without exposing a common final-Destination pair in ordinary forwarding fields.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "I2P tunnel processing and GNUnet 0.20.0 CADET forwarding", "sources": [ "https://i2p.net/en/docs/specs/tunnel-implementation/", "https://i2p.net/en/docs/overview/tunnel-routing/" ], "editorial_references": [ "round502.html", "round502-sources.json" ], "qualification": "This credits the selected multi-hop destination traffic and layered tunnel processing, not a zero-hop or direct-destination transport. An outbound tunnel endpoint sees onward router/tunnel instructions; an inbound gateway sees its local tunnel and previous sender. Their partial views do not amount to a universally hidden topology. Collusion reconstructing mappings, malicious peers, endpoint compromise, timing/volume analysis and application disclosures remain outside this header-level result. No execution or universal anonymity certification is claimed." }, { "id": "C06-YG", "feature": "C06", "stack": "YG", "status": "N", "reason": "The selected Ironwood traffic encoding includes source and destination public keys outside the encrypted payload. Participating routers decode that structure and forward it with those keys retained. A forwarding node can therefore read the final-key pair even though it cannot decrypt the application payload.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Pinned Ironwood and Reticulum forwarding code", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/traffic.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go" ], "editorial_references": [ "round500.html", "round500-sources.json" ], "qualification": "The observer terminates an authorized peer transport. TCP/TLS can hide these fields from an external observer without link keys, but not from the forwarding participant. Independent logical-node keys between contexts do not hide an established flow. Public keys are protocol identities, not proof of civil identity; no cryptographic break is claimed." }, { "id": "C06-CJ", "feature": "C06", "stack": "CJ", "status": "N", "reason": "The selected cjdns SessionManager prepends the receiving endpoint session handle after end-to-end encryption and before the switch header. Transit SwitchCore changes the route label and header fields, but retains that session handle. Authorized observers across segments can associate established packets by the retained directional session identifier; label transformation alone does not satisfy C06.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Tor channel-local circuit IDs and pinned cjdns session handles", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c", "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/switch/SwitchCore.c" ], "editorial_references": [ "round501.html", "round501-sources.json" ], "qualification": "The observer participates in the outer CryptoAuth-protected links and can inspect the decrypted switch packet, without possessing final-session payload keys. A handle is not a globally unique civil or persistent node identity; collisions and reuse preclude treating it alone as universal proof across unrelated sessions. The finding is the unchanged within-session cross-hop field, not payload disclosure, and does not deny the transformed per-hop route label." }, { "id": "C06-MQ", "feature": "C06", "stack": "MQ", "status": "N", "reason": "Multipath QUIC protects transport payloads, but the selected direct IP/UDP connection exposes the source and destination network addresses and UDP ports on each used path. The observer can associate the final communicating endpoints without decrypting application data or recovering a peer public key.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-12", "https://www.rfc-editor.org/rfc/rfc9000.html#section-9.5", "https://www.rfc-editor.org/rfc/rfc8200.html#section-3" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "Connection-ID rotation, path migration and distinct identity keys do not conceal the address pair of the observed direct path. This is not a claim of unconditional cross-path linkage through a reused connection ID. No privacy relay, VPN or anonymity overlay is selected; authenticated peer identity and real-world identity are not required for the address-pair finding." }, { "id": "C06-SC", "feature": "C06", "stack": "SC", "status": "N", "reason": "The SCION address header explicitly carries source and destination ISD-AS values and host addresses. The selected UDP underlay and SCION data path do not encrypt that header, so a transit observer can identify the final address pair despite per-hop path authentication.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html#address-header", "https://raw.githubusercontent.com/scionproto/scion/90de96d6404a5e4fa56ea020187bff8ab5b501bc/doc/protocols/scion-header.rst" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "The outer underlay may identify adjacent routers, but the inner SCION address header still exposes final addresses. Distinct flow/address contexts between sessions do not meet the revised within-communication association criterion. No anonymity extension is selected; path authenticity is not endpoint-pair confidentiality." }, { "id": "C06-RT", "feature": "C06", "stack": "RT", "status": "N", "reason": "Reticulum assigns the Link ID as the Link destination hash. Established Link packets carry that hash, and transport forwarding changes the hop count while retaining the remaining packet fields. Authorized observers on different traversed segments can match this common Link identifier without timing analysis or decrypting the payload. This fails the cross-segment association clause of C06.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Pinned Ironwood and Reticulum forwarding code", "sources": [ "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Link.py", "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Packet.py", "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round500.html", "round500-sources.json" ], "qualification": "The observer has the relevant IFAC interface access; outsiders without the secret IFAC credentials are not assigned the same visibility. A shared Link ID does not itself reveal the persistent initiator identity, and fresh identifiers across Links retain their separate privacy value. Optional identify() remains encrypted; this finding concerns within-Link association, not identity disclosure or message contents." }, { "id": "C06-NS", "feature": "C06", "stack": "NS", "status": "N", "reason": "A participating Nostr relay sees the event author pubkey and stable event ID, then associates the delivered event with the reader's WebSocket subscription and connection. NIP-01 uses those fields for filtering and delivery; they are protocol selectors, not merely an opaque payload fingerprint. A publisher and reader using that relay therefore have an observable delivery association. WSS hides these records from passive carrier observers, but not from the relay terminating TLS. The selected basic composition consequently does not conceal the association from all selected transit observers.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "NIP-01 event format, filters and client/relay message definitions", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round582.html", "round582-sources.json" ], "qualification": "No claim that a reader exposes a civil identity or authenticated Nostr key: its receiving connection is sufficient for this bounded observation. A signed author is not necessarily the live publishing socket owner; replay by another publisher remains possible. Subscription IDs are connection-local, whereas event IDs and author keys persist across relay copies. Credit concerns protocol-visible delivery metadata, not timing correlation, compulsory logging or a private-message recipient field. No NIP-17/44, Tor or additional privacy wrapper is selected. Other Nostr profiles require separate assessment." }, { "id": "C06-MT", "feature": "C06", "stack": "MT", "status": "N", "reason": "The selected Meshtastic radio PacketHeader contains the final to/from NodeNum fields separately from the protected payload and the next_hop/relay_node fields. A radio observer can associate the sender and destination NodeIDs without decrypting the direct-message payload.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "RFC routing/discovery mechanisms and pinned Meshtastic header", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/RadioInterface.h", "https://meshtastic.org/docs/overview/mesh-algo/" ], "editorial_references": [ "round491.html", "round491-sources.json" ], "qualification": "PKI payload encryption, private channel keys and strict signatures remain selected, but do not hide these header fields. Distinct provisioned identities between contexts do not conceal the pair within a communication. This identifies radio endpoints, not necessarily legal persons; no timing inference or fabricated decryption is required." }, { "id": "C06-GN", "feature": "C06", "stack": "GN", "status": "N", "reason": "GNUnet 0.20.0 CADET places the connection identifier before the encrypted tunnel-message header and content. Intermediate CADET peers look up this identifier and forward a copy of the message, retaining it across the connection path. Authorized forwarding observers can match this common connection identifier across segments without decrypting the final payload.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "I2P tunnel processing and GNUnet 0.20.0 CADET forwarding", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [ "round502.html", "round502-sources.json" ], "qualification": "The observer participates in the CORE-protected peer links. CORE protects against an outsider without link keys but does not conceal the CADET header from that intermediary. This is connection association, not necessarily civil identity disclosure; fresh independent keys or connections do not remove the shared identifier inside an existing connection. The finding is specific to the selected v0.20.x baseline." }, { "id": "C06-ND", "feature": "C06", "stack": "ND", "status": "N", "reason": "No under the revised C06 criterion. NDN Interests expose Name and, on network links, Nonce; their combination identifies an Interest for loop detection. In the selected NFD 24.07 multicast strategy, the ordinary initial Interest is passed to outgoing forwarding without replacing these fields with hop-local aliases. The outgoing pipeline sends that Interest and Data retains its Name. Consequently a cache-miss, unaggregated exchange has a common visible request selector across segments, allowing the consumer and responding producer attachments to be associated when their edge segments are observed. Direct Ethernet addresses identify each segment, not a global endpoint pair, but this does not remove the persistent Name/Nonce selector. No authenticated consumer identity is needed for this bounded association.", "method": "Primary packet definitions and pinned forwarding trace; bounded architectural counterexample, no runtime experiment", "source_label": "NDN packet v0.3, NFD 24.07, CCNx RFCs 8569 and 8609", "sources": [ "https://docs.named-data.net/NDN-packet-spec/current/interest.html", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/fw/multicast-strategy.cpp", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [ "round608.html", "round608-sources.json" ], "qualification": "The bounded counterexample is an ordinary unaggregated request for a distinctive exact content name, absent from intermediate caches, answered by a live producer. An observer reads forwarding fields on the consumer-facing and producer-facing segments and matches that request and response across them. This uses visible protocol selectors, not payload fingerprints, timing, volume, diagnostic logs or access to every router mapping. It demonstrates a permitted case without association concealment; it does not claim that every repeated popular-name request can be uniquely linked. Content names are not inherently host or civil identities. Caching, aggregation, multiple publishers and replay can prevent attributing a response to the original signer or producer; those benefits do not make the selected composition conceal all such associations. A cache-hit exchange must be evaluated against the serving cache, not falsely attributed to the original publisher. No new anonymity wrapper or application profile is selected. NDNLP link-local tokens, sequence fields and local face IDs do not conceal the enclosed Name/Nonce. Nonce regeneration on other forwarding or retransmission paths is not denied. A signature identifies a signing key, not necessarily the current responding host." }, { "id": "C06-AX", "feature": "C06", "stack": "AX", "status": "N", "reason": "Linux NET/ROM nr_transmit_buffer writes source_addr and dest_addr into the network header before forwarding. The selected AX.25/NET/ROM composition adds no cryptographic confidentiality, so the final callsign/SSID pair remains observable beyond the immediate link addresses.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_out.c" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "Private direct-serial labels need not be public radio callsigns or real-world identities. Nevertheless, their communicating pair is exposed in protocol fields. Changing labels between contexts does not hide the pair within the communication, and the no-IP composition does not remove this association." }, { "id": "C06-BA", "feature": "C06", "stack": "BA", "status": "N", "reason": "The selected batman-adv service encapsulates the attached Ethernet frame in mesh headers. Its original source and destination MAC addresses remain in that frame, which transit observers can inspect because this composition selects no link or end-to-end confidentiality.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/include/uapi/linux/batadv_packet.h" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "Outer next-hop addresses and mesh-originator selectors do not erase the inner Ethernet address pair. Locally administered MAC addresses avoid a mandatory manufacturer identity, but do not hide the communicating pair. This evaluates the existing unencrypted L2 service; no IP layer, WPA, MACsec or VPN is added." }, { "id": "C06-BL", "feature": "C06", "stack": "BL", "status": "N", "reason": "The selected Babel composition forwards ordinary IPv6 datagrams. Their network header exposes the source and destination addresses to transit observers; Babel route selection does not translate or hide that final address pair.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html#section-3" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "This profile has no IPsec or privacy tunnel. ULA allocation and independent address contexts do not hide the pair within an established communication. No transport ports, application identity or timing analysis are necessary for the finding." }, { "id": "C06-RI", "feature": "C06", "stack": "RI", "status": "N", "reason": "In the selected route-over IPv6/RPL composition, authorized forwarding routers process the source and destination IPv6 addresses. End-to-end DTLS protects application records, not this IP peer pair. IEEE 802.15.4 link encryption is removed by authorized link participants before IPv6 forwarding; header compression changes representation rather than providing identity confidentiality.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "BP primary blocks and routed IPv6 headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html#section-3", "https://www.rfc-editor.org/rfc/rfc6554.html#section-3", "https://www.rfc-editor.org/rfc/rfc9147.html#section-4" ], "editorial_references": [ "round499.html", "round499-sources.json" ], "qualification": "The observer is a participating RPL router with the required link access, not a passive outsider lacking IEEE 802.15.4 keys. Final DTLS keys remain unavailable to that router. RPL source-routing intermediates can temporarily occupy the IPv6 Destination Address field; the selected routing header identifies the remaining route and final destination. No DTLS-terminating gateway, civil-identity inference or payload decryption is asserted." }, { "id": "C06-HP", "feature": "C06", "stack": "HP", "status": "N", "reason": "HIP ESP protects the payload, but the selected host-to-host data path transmits packets with the communicating hosts' source and destination IP locators in the outer IP header. An observer of that forwarding segment can associate the peer pair; replacing HITs with locators does not conceal that pair.", "method": "Primary documentary reassessment; no runtime test", "source_label": "Selected routing and HIP specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html#section-3.2" ], "editorial_references": [ "round493.html", "round493-sources.json" ], "qualification": "This is a visible-header result, not a claim that an observer learns civil identities or encrypted application contents. Mobility can change locators, but does not hide the pair within each observed communication interval. No relay or anonymity layer is selected." }, { "id": "C06-CX", "feature": "C06", "stack": "CX", "status": "N", "reason": "No under the revised C06 criterion. RFC 8569 uses the Interest Name and optional restrictions for forwarding/PIT matching; responses match the request Name, and RFC 8609 places these fields in the visible Message TLV. The selected IPv4/UDP binding supplies no confidentiality for that message. For a distinctive exact-name request with no cache hit or aggregation, the same visible name links the exchange across the consumer-facing and responding producer-facing segments. Hop-local IP/UDP peers and pending-interest state do not replace that selector with protected adjacency-local names. This defeats the cross-segment association clause without inventing a source-address field or requiring authenticated consumer identity.", "method": "Primary packet definitions and pinned forwarding trace; bounded architectural counterexample, no runtime experiment", "source_label": "NDN packet v0.3, NFD 24.07, CCNx RFCs 8569 and 8609", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-9", "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.2", "https://www.rfc-editor.org/rfc/rfc8609.html#section-3.6" ], "editorial_references": [ "round608.html", "round608-sources.json" ], "qualification": "The bounded counterexample is an ordinary unaggregated request for a distinctive exact content name, absent from intermediate caches, answered by a live producer. An observer reads forwarding fields on the consumer-facing and producer-facing segments and matches that request and response across them. This uses visible protocol selectors, not payload fingerprints, timing, volume, diagnostic logs or access to every router mapping. It demonstrates a permitted case without association concealment; it does not claim that every repeated popular-name request can be uniquely linked. Content names are not inherently host or civil identities. Caching, aggregation, multiple publishers and replay can prevent attributing a response to the original signer or producer; those benefits do not make the selected composition conceal all such associations. A cache-hit exchange must be evaluated against the serving cache, not falsely attributed to the original publisher. No new anonymity wrapper or application profile is selected. CCNx has no NDN Nonce requirement: the finding uses the distinctive Name and matching rules, not a transferred NDN field. Optional KeyId/ContentObjectHash restrictions may narrow matching but are not needed for this counterexample. Producer signatures and CRC32C integrity do not conceal the selectors." }, { "id": "C06-LI", "feature": "C06", "stack": "LI", "status": "N", "reason": "RFC 9300 encapsulation places the EID-bearing inner IP packet after the outer RLOC, UDP and LISP headers. The selected composition does not encrypt the inner packet, so a transit packet observer can read both final EIDs rather than seeing only the tunnel-router locators.", "method": "Header/encapsulation assessment under revised C06; no traffic capture", "source_label": "Primary RFCs and pinned protocol/implementation headers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-5.1", "https://www.rfc-editor.org/rfc/rfc9300.html#section-5.3" ], "editorial_references": [ "round490.html", "round490-sources.json" ], "qualification": "The EID/RLOC separation is retained as a routing capability. It is not confidentiality of the EID pair. No LISP-SEC, IPsec or endpoint privacy layer is selected; the finding concerns visible network addresses, not real-world identities." }, { "id": "C06-IL", "feature": "C06", "stack": "IL", "status": "N", "reason": "The selected ILNPv6 packet format carries source and destination Identifiers and Locators in the visible network header. The Identifier pair persists across Locator changes for an active communication, allowing a transit observer to associate the final peers by protocol fields.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "Pinned architecture/lifecycle source and ILNP experimental RFCs", "sources": [ "https://www.rfc-editor.org/rfc/rfc6741.html#section-3", "https://www.rfc-editor.org/rfc/rfc6740.html" ], "editorial_references": [ "round489.html", "round489-sources.json" ], "qualification": "No IPsec or privacy tunnel is selected. Locally generated identifiers need not reveal a legal identity, but that does not hide the communicating pair under revised C06. Separating location from identity supports mobility without itself hiding the association; timing correlation is not needed for this finding." }, { "id": "C06-TS", "feature": "C06", "stack": "TS", "status": "N", "reason": "A transit observer on the selected direct path sees the outer source and destination locators and UDP flow identifiers linking the communicating endpoint attachments. Encryption conceals inner addresses, not that direct-path association.", "method": "Primary documentation and explicit architectural inference; no runtime test", "source_label": "Tailscale service model and WireGuard protocol", "sources": [ "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/access-control", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/reference/connection-types", "https://tailscale.com/docs/features/site-to-site", "https://www.wireguard.com/protocol/", "https://www.wireguard.com/" ], "editorial_references": [ "round585.html", "round585-sources.json" ], "qualification": "No claim that outer addresses reveal civil identities or uniquely identify a device behind shared NAT. No anonymity wrapper is selected." }, { "id": "C06-RA", "feature": "C06", "stack": "RA", "status": "N", "reason": "The protected two-host upper DIF still needs a lower routed flow between its host IPCPs. An intermediary in that supporting DIF removes its incoming SDU protection and can read the lower PDU source/destination addresses and source/destination CEP identifiers. Those identifiers persist across forwarding in that DIF; its replicated directory associates registered upper IPCP names with attachment addresses. The endpoint-host association therefore remains visible at this transit scope even though the upper payload is encrypted.", "method": "Pinned packet-field and forwarding source inspection with explicit observer scope", "source_label": "IRATI PCI fields, RMT forwarding and per-DIF directory", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/pci.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/flow-allocator.cc", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round667.html" ], "qualification": "No for the selected recursive composition, using the supporting transit DIF as the observation boundary. It does not imply every physical access hop sees the same fields, nor that the observer decrypts application data or learns civil identities. Aggregating applications behind one host may hide individual application flows, but does not conceal the communicating endpoint-host pair. A distinct anonymity or relay composition would require separate assessment; no timing-correlation experiment." }, { "id": "C07-PN", "feature": "C07", "stack": "PN", "status": "Y", "reason": "Protected adjacency encryption and opaque padding are specified in wire-v4 sections 5–6 and 12. Architecture section 11 recognizes optional cover traffic; the author clarifies cover data within packets and cover packets on the carrier. Credit is for available mechanisms when enabled. Exact cover scheduling and measured correlation reduction remain unqualified; cover-packet implementation was not verified here.", "method": "Documentary analysis", "source_label": "PRP specification plus author clarification in editorial review", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Specify cover scheduling, overhead and observer model; measure correlation reduction. Cover-packet runtime support was not independently checked." }, { "id": "C07-PI", "feature": "C07", "stack": "PI", "status": "Y", "reason": "Protected adjacency encryption and opaque padding are specified in wire-v4 sections 5–6 and 12. Architecture section 11 recognizes optional cover traffic; the author clarifies cover data within packets and cover packets on the carrier. Credit is for available mechanisms when enabled. Exact cover scheduling and measured correlation reduction remain unqualified; cover-packet implementation was not verified here.", "method": "Documentary analysis", "source_label": "PRP specification plus author clarification in editorial review", "sources": [], "editorial_references": [ "index.html#prp-review-current" ], "qualification": "Specify cover scheduling, overhead and observer model; measure correlation reduction. Cover-packet runtime support was not independently checked." }, { "id": "C07-IP", "feature": "C07", "stack": "IP", "status": "N", "reason": "The selected composition has no IPsec security association, encryption, padding or cover-traffic mechanism. Such protection requires an explicitly added security profile.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4301.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-BP", "feature": "C07", "stack": "BP", "status": "Y", "reason": "The column now explicitly selects TLS 1.3. RFC 8446 section 5.4 and appendix E.3 provide encrypted record padding and padding-only traffic, qualifying under C07 optional-mechanism rules. This is TLS-layer capability, not an application feature or evidence that a deployed client exposes a padding policy. Timing and residual length correlation remain possible.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4" ], "editorial_references": [], "qualification": "Pin the TLS implementation and API/configuration enabling a padding policy; verify records on every observed segment and evaluate correlation reduction, latency and bandwidth cost. TLS 1.3 capability is not evidence of enabled defaults or effective end-to-end cover. No test executed." }, { "id": "C07-CG", "feature": "C07", "stack": "CG", "status": "Y", "reason": "The selected TLS 1.3 layer permits encrypted record padding and empty application-data records for cover traffic. This meets the criterion for an optional mechanism; it does not establish an enabled policy or effective end-to-end correlation resistance. The initial TCPCL header remains visible.", "method": "Documentary review; no new runtime experiment", "source_label": "Primary specification and bounded profile inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4" ], "editorial_references": [], "qualification": "Pin TLS padding controls, exercise them on every observed hop and measure residual correlation and cost. No enabled defaults or measured effectiveness are claimed." }, { "id": "C07-LT", "feature": "C07", "stack": "LT", "status": "N", "reason": "The selected AOS packet service exposes idle-only frames through the reserved VCID and idle-only packet zones through the First Header Pointer. Packet boundaries and lengths remain observable without SDLS. Thus regular framing and idle fill do not supply opaque cover traffic in this profile; no mix or separate traffic-analysis defense is selected. BPSec payload encryption leaves these outer indicators visible.", "method": "Selected-profile wire-format analysis; no correlation experiment", "source_label": "AOS 732.0-B-4 sections 4.1.4.1.5 and 4.1.4.2.3–4.1.4.2.4", "sources": [ "https://ccsds.org/Pubs/732x0b4.pdf" ], "editorial_references": [], "qualification": "Capture packet-service frames with payload and idle periods, parse visible indicators and compare traffic traces. This No does not exclude a separately defined encrypted-link or cover-traffic profile." }, { "id": "C07-LP", "feature": "C07", "stack": "LP", "status": "Y", "reason": "RFC 9000 sections 19.1 and 21.14 explicitly provide PADDING to obscure protected content lengths. The same mechanism-presence standard used for PRP applies here. This is partial traffic-analysis defense, not a claim that padding defeats timing correlation or supplies a constant-rate cover schedule.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-21.14" ], "editorial_references": [], "qualification": "" }, { "id": "C07-TO", "feature": "C07", "stack": "TO", "status": "Y", "reason": "Tor Padding Specification explicitly defines cover traffic to obscure traffic patterns from external and internal observers. This credits a defense mechanism, not prevention of all end-to-end timing correlation; deployment and cost remain profile-dependent.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/padding-spec/" ], "editorial_references": [], "qualification": "" }, { "id": "C07-I2", "feature": "C07", "stack": "I2", "status": "Y", "reason": "NTCP2 specifies random padding inside authenticated data-phase frames. Padding reduces useful-length disclosure; it is not a guarantee against timing correlation or a claim of constant-rate transmission.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "" }, { "id": "C07-YG", "feature": "C07", "stack": "YG", "status": "Y", "reason": "The column now explicitly selects TLS 1.3. RFC 8446 section 5.4 and appendix E.3 provide encrypted record padding and padding-only traffic, qualifying under C07 optional-mechanism rules. This is TLS-layer capability, not an application feature or evidence that a deployed client exposes a padding policy. Timing and residual length correlation remain possible.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4" ], "editorial_references": [], "qualification": "Pin the TLS implementation and API/configuration enabling a padding policy; verify records on every observed segment and evaluate correlation reduction, latency and bandwidth cost. TLS 1.3 capability is not evidence of enabled defaults or effective end-to-end cover. No test executed." }, { "id": "C07-CJ", "feature": "C07", "stack": "CJ", "status": "N", "reason": "The selected ordinary CryptoAuth composition adds authentication/encryption overhead but no chosen cover or timing-shaping policy. The alternative Noise codec's pad(msg, align) is memory/wire alignment, not a selected traffic-correlation defense. This negative is scoped to the declared stack.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/rust/cjdns_sys/src/crypto/cnoise.rs" ], "editorial_references": [], "qualification": "" }, { "id": "C07-MQ", "feature": "C07", "stack": "MQ", "status": "Y", "reason": "RFC 9000 sections 19.1 and 21.14 explicitly provide PADDING to obscure protected content lengths. The same mechanism-presence standard used for PRP applies here. This is partial traffic-analysis defense, not a claim that padding defeats timing correlation or supplies a constant-rate cover schedule.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-21.14" ], "editorial_references": [], "qualification": "" }, { "id": "C07-SC", "feature": "C07", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP composition supplies visible forwarding metadata and no selected traffic-padding, cover or mixing mechanism. Header alignment and address zero-padding are format requirements, not correlation defenses. Extra privacy layers would change the compared stack. Scope inference; no correlation experiment was performed.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-RT", "feature": "C07", "stack": "RT", "status": "N", "reason": "The selected serial Link/secret-IFAC composition has encryption, fixed authentication overhead and PKCS7 block alignment. It selects no arbitrary cover-padding or traffic-shaping policy. Block alignment and header masking alone do not supply the criterion's deliberate traffic-correlation defense.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Cryptography/Token.py" ], "editorial_references": [], "qualification": "" }, { "id": "C07-NS", "feature": "C07", "stack": "NS", "status": "Y", "reason": "The column now explicitly selects TLS 1.3. RFC 8446 section 5.4 and appendix E.3 provide encrypted record padding and padding-only traffic, qualifying under C07 optional-mechanism rules. This is TLS-layer capability, not an application feature or evidence that a deployed client exposes a padding policy. Timing and residual length correlation remain possible.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4" ], "editorial_references": [], "qualification": "Pin the TLS implementation and API/configuration enabling a padding policy; verify records on every observed segment and evaluate correlation reduction, latency and bandwidth cost. TLS 1.3 capability is not evidence of enabled defaults or effective end-to-end cover. No test executed." }, { "id": "C07-MT", "feature": "C07", "stack": "MT", "status": "N", "reason": "In this selected profile, encryption leaves packet length and transmission timing observable. RadioInterface transmits encrypted.size plus the fixed header; it does not pad packets to a privacy schedule. The documented random backoff manages channel contention and duplicate suppression, not entry/exit correlation. No cover, mixing or traffic-shaping privacy policy is selected. Thus payload encryption and ordinary radio scheduling do not meet C07; this is a mechanism-scope conclusion, not a measured correlation attack.", "method": "Read-only code analysis and explicit topology inference", "source_label": "Pinned Meshtastic firmware: forwarding, authenticated receive and client serialization", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/RadioInterface.cpp#L1506" ], "editorial_references": [], "qualification": "" }, { "id": "C07-GN", "feature": "C07", "stack": "GN", "status": "Y", "reason": "CORE can combine multiple small messages for the same adjacent peer into one plaintext buffer before encrypting it. In 0.20.0, the session queue builds that combined buffer and passes it to GSC_KX_encrypt_and_transmit; CORK_ALLOWED optionally delays eligible messages until a bounded deadline to facilitate aggregation. When aggregation occurs, an outside observer sees the aggregate encrypted record rather than separate inner-message boundaries and emission times. This provides a limited batching mechanism under the existing C07 mechanism-presence rule. It is not padding, a constant-rate cover schedule, a randomized anonymity mix or a demonstrated reduction of end-to-end correlation. Total volume, aggregate timing and outer transport metadata remain observable; adjacent peers can decrypt their own CORE traffic. The feature is native CORE behavior, not anonymous file sharing or an added discovery/application protocol.", "method": "Versioned CORE documentation and GNUnet 0.20.0 source analysis; no traffic experiment", "source_label": "CORE message grouping and optional corking; gnunet-service-core_sessions.c", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/core/core.html", "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [], "qualification": "Trace CORK_ALLOWED propagation and ordinary aggregation for CADET traffic in the selected build. Capture separate observed links under sparse and concurrent loads, identify transport fragmentation and aggregate sizes, then compare correlation, latency and overhead with a fixed observer model. Do not assume that corking is enabled by default, that isolated messages are batched, or that an adjacent decrypting relay loses visibility. No traffic capture or effectiveness experiment performed." }, { "id": "C07-ND", "feature": "C07", "stack": "ND", "status": "N", "reason": "The selected NFD Interest/Data service supplies no privacy padding, cover schedule or mixing policy to reduce entry/exit timing and volume correlation. Caching and request aggregation change traffic, but are not selected as a correlation-defense mechanism.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "NFD 24.07 module and forwarding architecture", "sources": [ "https://docs.named-data.net/NFD/24.07/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-AX", "feature": "C07", "stack": "AX", "status": "N", "reason": "The selected frame/circuit service supplies no traffic-analysis padding, batching or cover policy. Flow control, retransmission and periodic route broadcasts are not an entry/exit correlation defense.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "C07-BA", "feature": "C07", "stack": "BA", "status": "N", "reason": "The native Ethernet forwarding profile supplies no traffic-analysis cover, padding or mixing policy. Route announcements and ordinary frame formatting are not a selected defense against cooperating entry/exit observers; no privacy layer is included.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-BL", "feature": "C07", "stack": "BL", "status": "N", "reason": "Babel Pad1/PadN elements are ignored control-packet padding, not a selected policy masking user-data timing or volume. The declared IPv6/Babel composition contains no traffic-analysis defense; periodic Hellos do not supply one.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-RI", "feature": "C07", "stack": "RI", "status": "Y", "reason": "DTLS 1.3 retains encrypted inner-plaintext padding. Combined with the TLS 1.3 record-padding semantics, this allows optional padding to obscure useful-record sizes, satisfying the limited C07 mechanism-presence criterion.", "method": "Documentary mechanism inventory; no traffic-analysis experiment", "source_label": "Primary packet-format, signaling and padding specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc9147.html#section-4", "https://www.rfc-editor.org/rfc/rfc8446.html#section-5.4" ], "editorial_references": [ "round263-sources.json" ], "qualification": "Padding policy and deployment are unqualified. Packet timing, addresses, total padded volume and fragmentation remain visible; DTLS does not protect RPL control messages. Measure correlation reduction and overhead before claiming effectiveness." }, { "id": "C07-HP", "feature": "C07", "stack": "HP", "status": "Y", "reason": "ESP provides optional Traffic Flow Confidentiality padding inside encrypted payloads. RFC 4303 section 2.7 permits it in transport mode when the next protocol supplies its real length; the selected UDP payload satisfies that condition. It can obscure useful-payload size beyond cipher-block alignment.", "method": "Documentary mechanism inventory; no traffic-analysis experiment", "source_label": "Primary packet-format, signaling and padding specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc4303.html#section-2.7" ], "editorial_references": [ "round263-sources.json" ], "qualification": "Credits presence of an optional mechanism, not its activation or measured correlation resistance. Outer endpoints, timing and padded packet sizes remain observable; no gateway tunnel, constant-rate schedule or anonymity guarantee is inferred. Exact implementation support and MTU/cost need testing." }, { "id": "C07-CX", "feature": "C07", "stack": "CX", "status": "N", "reason": "The selected CCNx core supplies no encrypted padding, cover schedule or mixing mechanism to conceal traffic timing or volume from cooperating observers. Signature validation does not hide request or object lengths.", "method": "Documentary mechanism inventory; no traffic-analysis experiment", "source_label": "Primary packet-format, signaling and padding specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4" ], "editorial_references": [ "round263-sources.json" ], "qualification": "Caching and Interest aggregation change traffic but do not by themselves establish a selected correlation-defense policy. No privacy extension or encrypted wrapper is selected." }, { "id": "C07-LI", "feature": "C07", "stack": "LI", "status": "N", "reason": "The declared unencrypted LISP/UDP profile has no traffic-padding or cover-packet mechanism to obscure timing or volume. Locator indirection and load balancing do not provide that mechanism.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-IL", "feature": "C07", "stack": "IL", "status": "N", "reason": "The selected ILNPv6/TCP profile provides no cover-traffic or traffic-shaping padding mechanism. Changing NIDs or Locators does not by itself conceal timing and volume from cooperating observers.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "C07-TS", "feature": "C07", "stack": "TS", "status": "Y", "reason": "WireGuard pads inner packets to 16-byte boundaries before encryption, subject to MTU limits. This reduces exact-length information available for matching packets across an encapsulation boundary.", "method": "Pinned dependency/source inspection and official documentation; no runtime test", "source_label": "Tailscale go.mod and selected wireguard-go dependency", "sources": [ "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://www.wireguard.com/protocol/", "https://tailscale.com/docs/reference/connection-types", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/receive.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/send.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/timers.go", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/constants.go" ], "editorial_references": [ "round587.html", "round587-sources.json" ], "qualification": "Narrow credit under the criterion allowing partial padding defenses. Timing and coarse length remain visible; no cover schedule, strong anonymity or measured correlation resistance is claimed." }, { "id": "C07-RA", "feature": "C07", "stack": "RA", "status": "N", "reason": "The selected default SDU crypto policy compresses, adds sequence/MAC data, pads to the cipher block size and encrypts each submitted PDU. Its padding is deterministic block completion, not a selected traffic-shaping or cover-traffic defense. The declared forwarding modes do not add independent dummy traffic, mixing or deliberate timing obfuscation.", "method": "Native architecture and pinned SDU/RMT source inspection; no runtime or attack experiment", "source_label": "RINA recursive protection placement and IRATI default SDU crypto policy", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup-crypto-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/sdup-crypto-ps-default.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md" ], "editorial_references": [ "round666.html" ], "qualification": "No for this explicit policy composition. Encryption and ordinary cipher padding alone do not establish a defense against observers correlating packet timing and volume. Recursive aggregation may combine flows but is not credited as a documented correlation-defense policy. No general impossibility for custom RINA policies, nor a measured attack-success claim." }, { "id": "S01-PN", "feature": "S01", "stack": "PN", "status": "Y", "reason": "Architecture section 5.6 requires communication from sufficient local relationship information and a compatible carrier without mandatory global naming, routing, identity, governance or ledger infrastructure. Optional services are profile choices.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "S01-PI", "feature": "S01", "stack": "PI", "status": "Y", "reason": "Architecture section 5.6 requires communication from sufficient local relationship information and a compatible carrier without mandatory global naming, routing, identity, governance or ledger infrastructure. Optional services are profile choices.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "S01-IP", "feature": "S01", "stack": "IP", "status": "Y", "reason": "Cooperating private networks can use locally administered IPv4 private space or locally generated IPv6 ULA prefixes without an external allocator or mandatory naming authority. This independent-deployment capability does not confer public Internet reachability.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-BP", "feature": "S01", "stack": "BP", "status": "Y", "reason": "TCPCL requires certification-path and NODE-ID validation, but not a public CA. The profile selects participant-operated CAs, locally exchanged trust and no online OCSP. BPSec keys are provisioned locally. No separate mandatory third-party authority is selected; identifier allocation remains S03. Profile inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9174#section-4.4.4" ], "editorial_references": [], "qualification": "For S01/S02, pin TCPCL/BPSec implementations; verify locally exchanged roots, NODE-ID matching, EKU and rejection of untrusted or mismatched identities without online services. BPSec leaves key management to network management (RFC 9172 section 6); the selected local provisioning must be exercised. No execution performed. https://datatracker.ietf.org/doc/html/rfc9172#section-6" }, { "id": "S01-CG", "feature": "S01", "stack": "CG", "status": "Y", "reason": "In the declared locally managed profile, peers supply plans, clocks, mappings and BPSec keys without a separate mandatory runtime authority. BPSec imposes no particular key-management strategy; SABR does not mandate a central plan distributor. Underlay identifier allocation is assessed separately in S03. TCPCL uses participant-operated certificate trust without online status or DNS services.", "method": "Documentary architectural inference; no executable qualification", "source_label": "Primary specifications; selected-profile analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9172.html#section-6", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [], "qualification": "Validate the declared complete composition and local management in an executable deployment; this decision is not measured scale, conformance or interoperability." }, { "id": "S01-LT", "feature": "S01", "stack": "LT", "status": "Y", "reason": "In the declared locally managed profile, peers supply plans, clocks, mappings and BPSec keys without a separate mandatory runtime authority. BPSec imposes no particular key-management strategy; SABR does not mandate a central plan distributor. Underlay identifier allocation is assessed separately in S03. This does not grant CCSDS mission identifiers or settle AOS allocation.", "method": "Documentary architectural inference; no executable qualification", "source_label": "Primary specifications; selected-profile analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9172.html#section-6", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc7116.html#section-3.1.2" ], "editorial_references": [], "qualification": "Validate the declared complete composition and local management in an executable deployment; this decision is not measured scale, conformance or interoperability." }, { "id": "S01-LP", "feature": "S01", "stack": "LP", "status": "Y", "reason": "The selected direct-peer profile uses locally generated Peer IDs and known addresses; no mandatory libp2p-wide identity or directory authority is involved. Underlay allocation is a separate question.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://libp2p.io/docs/peers/" ], "editorial_references": [], "qualification": "" }, { "id": "S01-TO", "feature": "S01", "stack": "TO", "status": "N", "reason": "The selected public Tor network uses directory authorities and a signed consensus. This does not mean one relay controls Tor or that private test networks are impossible.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/dir-spec/outline.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-I2", "feature": "S01", "stack": "I2", "status": "Y", "reason": "With locally exchanged bootstrap contacts and known destination keys, no mandatory external reseed/naming authority is required. NetDb records are signed by their originating routers/destinations and distributed through floodfill peers. Those peers remain availability/trust dependencies, not a separate mandatory identity or consensus authority. Public IP allocation remains outside this S01 result.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/overview/network-database/" ], "editorial_references": [], "qualification": "" }, { "id": "S01-YG", "feature": "S01", "stack": "YG", "status": "Y", "reason": "Nodes generate key-based identities and can form their own network. No central Yggdrasil address issuer is required. This does not remove underlay dependencies.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-CJ", "feature": "S01", "stack": "CJ", "status": "Y", "reason": "The documented local key/address generation and direct peer credential configuration permit willing peers to form their own cjdns network without a mandatory external directory, certificate issuer or global admission authority. Peer permission remains local; allocation and reachability of the IP underlay are assessed separately. Documentary scope inference.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/configure.md" ], "editorial_references": [], "qualification": "" }, { "id": "S01-MQ", "feature": "S01", "stack": "MQ", "status": "Y", "reason": "RFC 9001 requires server authentication, not a public CA. The selected profile uses locally generated certificates trusted directly by counterparts, including client authentication during the handshake. No external naming or certification authority is selected. This is a profile inference, not the default Web PKI deployment.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9001#section-4.4" ], "editorial_references": [], "qualification": "Shared qualification for S01/S02/S03/F18/C05: pin a multipath-21 implementation, provision mutual certificate trust and numeric private addresses, disable DNS and external certificate services, and verify authenticated operation. Check that an untrusted certificate is rejected. No execution performed." }, { "id": "S01-SC", "feature": "S01", "stack": "SC", "status": "N", "reason": "The selected inter-domain profile requires ISD trust-root governance and AS certification. This is distributed/localized authority, but not authority-free operation.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-RT", "feature": "S01", "stack": "RT", "status": "Y", "reason": "Reticulum supports local identity creation and independently operated networks. The selected serial profile requires no IP allocator, name delegation or global authority.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/whatis.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-NS", "feature": "S01", "stack": "NS", "status": "N", "reason": "Correction: although NIP-01 has no Nostr-wide authority, the selected public WSS-hostname stack requires external DNS naming infrastructure. S01 expressly counts mandatory naming authorities; deferring all naming dependency to S03 was inconsistent. A private numeric-address composition would require its own explicit profile.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#round025" ], "qualification": "" }, { "id": "S01-MT", "feature": "S01", "stack": "MT", "status": "Y", "reason": "Willing peers generate keys and agree radio/channel parameters locally. This composition requires no external directory, issuer or registration service to communicate; counterpart trust decisions remain local. Spectrum rules are not a protocol authority.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/configuration/radio/security/" ], "editorial_references": [], "qualification": "" }, { "id": "S01-GN", "feature": "S01", "stack": "GN", "status": "Y", "reason": "Locally created peer keys and supplied contacts permit the selected independent private-IP deployment without a mandatory issuer, public hostlist or DNS authority. Local administration remains necessary. This does not establish global Internet reachability.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "GNUnet v0.20.x peer identities", "sources": [ "https://docs.gnunet.org/v0.20.x/about.html#peer-identities", "https://docs.gnunet.org/v0.20.x/about.html#peer-identities", "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html", "https://www.rfc-editor.org/rfc/rfc1918.html" ], "editorial_references": [], "qualification": "Start isolated peers with local contacts, no hostlist/DNS/NAT helper; verify no authority lookup. Pin a runtime compatible with the historical handbook." }, { "id": "S01-ND", "feature": "S01", "stack": "ND", "status": "Y", "reason": "Local trust anchors and name routes suffice for this independent deployment; public-testbed enrollment is not selected.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NDN packet format v0.3 signatures", "sources": [ "https://docs.named-data.net/NDN-packet-spec/0.3/signature.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-AX", "feature": "S01", "stack": "AX", "status": "Y", "reason": "For the already declared direct-serial role, willing peers can configure their node/user labels, links and routes locally. The historical NET/ROM manual documents RS232 interconnection using its network and transport layers. Linux address conversion, NET/ROM interface address assignment and route insertion operate on local labels without a mandatory external identity signer or directory lookup. Local OS privileges and peer admission are not an external protocol authority. This decision covers a private serial network; it does not assert permission to transmit on amateur spectrum or to use arbitrary callsigns on a public radio network.", "method": "Pinned primary-source inspection and bounded configuration/topology inference; no execution", "source_label": "Linux v6.12 source; NET/ROM 1.3 manual where indicated", "sources": [ "https://hamgate.ampr.org/docs/1987_netrom_version_1_3.pdf", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ax25/ax25_addr.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_dev.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c" ], "editorial_references": [], "qualification": "Use isolated serial peers with locally agreed unique labels and routes, without RF or external services. Verify circuit establishment and data exchange. This is a technical independence witness, not a radio-licensing opinion." }, { "id": "S01-BA", "feature": "S01", "stack": "BA", "status": "Y", "reason": "Participating nodes form the virtual switch without a mandatory external naming or trust authority.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-BL", "feature": "S01", "stack": "BL", "status": "Y", "reason": "Independent nodes originate local routes and exchange them with neighbors without a mandatory external directory or issuer.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-RI", "feature": "S01", "stack": "RI", "status": "Y", "reason": "The selected unsecured RPL mode does not invoke the separate authentication authority used by authenticated RPL mode. Participant-operated routing and locally provisioned end-to-end DTLS PSKs permit communication without an external identity or governance service.", "method": "Documentary dependency and state inventory; no execution", "source_label": "Primary protocol specifications and selected local deployment/trust configuration", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-3.2.3" ], "editorial_references": [ "round264-sources.json" ], "qualification": "A root is still required for the RPL instance; a communicating participant can perform that role. This is not a claim that RPL has no coordination point or that every RPL security mode is authority-free. Link admission remains local." }, { "id": "S01-HP", "feature": "S01", "stack": "HP", "status": "Y", "reason": "Locally generated Host Identities, pinned peer keys and known locators permit the selected HIP peers to establish their association without a separate naming, certification or rendezvous authority.", "method": "Documentary dependency and state inventory; no execution", "source_label": "Primary protocol specifications and selected local deployment/trust configuration", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-4.1" ], "editorial_references": [ "round264-sources.json" ], "qualification": "Peer admission and local routing configuration remain necessary. No public reachability, automatic discovery or freedom from underlay allocation is inferred by this cell." }, { "id": "S01-CX", "feature": "S01", "stack": "CX", "status": "Y", "reason": "Participants can agree on local content names, configure name routes and trust locally generated producer keys. The selected CCNx composition requires no separate namespace registry, certification authority or global directory for that communication.", "method": "Documentary dependency and state inventory; no execution", "source_label": "Primary protocol specifications and selected local deployment/trust configuration", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.2" ], "editorial_references": [ "round264-sources.json" ], "qualification": "The chosen trust model is explicit local provisioning, not automatic trust in every received signing key. Public namespace governance and global discovery are not selected." }, { "id": "S01-LI", "feature": "S01", "stack": "LI", "status": "N", "reason": "The selected composition includes Map-Resolver/Map-Server roles and authenticated registration as a separate routing-control authority. Participant ownership of those components does not remove the authority requirement in this profile; local administrative independence is assessed by S04.", "method": "Specification review; unchanged selected profile", "source_label": "rfc9301.html#section-4", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-4" ], "editorial_references": [], "qualification": "" }, { "id": "S01-IL", "feature": "S01", "stack": "IL", "status": "N", "reason": "The selected bootstrap uses authoritative DNS NID/L64 records. This is a separate naming authority even if locally operated. Direct pre-exchanged identifier/locator vectors are an architectural alternative, not the selected discovery profile.", "method": "Specification review; unchanged selected profile", "source_label": "rfc6740.html#section-4.4; rfc6742.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc6742.html" ], "editorial_references": [], "qualification": "" }, { "id": "S01-TS", "feature": "S01", "stack": "TS", "status": "N", "reason": "The selected managed profile requires a separate coordination authority for enrollment and policy/key distribution. Cached communication during an outage does not eliminate that lifecycle dependency.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "S01-RA", "feature": "S01", "stack": "RA", "status": "Y", "reason": "The documented two-participant Ethernet deployment performs enrollment and application registration using local IPC managers and peer IPC processes. Its configuration names the local DIFs and processes without an indispensable third-party registry, coordinator or approval service. Under S01, counterpart enrollment policy and participant-local management do not constitute a mandatory separate authority.", "method": "Primary deployment configuration and architectural dependency inference; no runtime test", "source_label": "IRATI Ethernet tutorial and retrieved IPC-manager/DIF configurations", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/default.dif", "https://raw.githubusercontent.com/wiki/IRATI/stack/configurations/tutorial1/system1/ipcm.conf" ], "editorial_references": [ "round652.html" ], "qualification": "Bounded architectural witness for direct local operation, not every federated or globally discovered RINA deployment. Participant provisioning and mutual acceptance remain necessary. Neither self-certifying identity nor absence of local administration follows. No runtime test or security-policy validation was performed." }, { "id": "S02-PN", "feature": "S02", "stack": "PN", "status": "Y", "reason": "Architecture section 4.2 and the wire identity profile allow local key-based identity without an external issuer; counterparties still control admission.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "S02-PI", "feature": "S02", "stack": "PI", "status": "Y", "reason": "Architecture section 4.2 and the wire identity profile allow local key-based identity without an external issuer; counterparties still control admission.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp" ], "qualification": "" }, { "id": "S02-IP", "feature": "S02", "stack": "IP", "status": "N", "reason": "The selected datagram service supplies addresses, not cryptographic participant identity or a persistent authenticated relationship. No IPsec or upper-layer identity protocol is included.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4301.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-BP", "feature": "S02", "stack": "BP", "status": "Y", "reason": "Participants operate their own CA and issue NODE-ID certificates for their local keys; counterparts explicitly configure trust. This satisfies local cryptographic identity issuance without an external issuer. NODE-ID certification is not self-certifying addressing or automatic peer admission.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9174#section-4.4.2" ], "editorial_references": [], "qualification": "" }, { "id": "S02-CG", "feature": "S02", "stack": "CG", "status": "Y", "reason": "Participants can generate keys and operate the selected NODE-ID certificate issuer locally; peers explicitly configure trust. An external issuer is not mandatory in this profile. This is not automatic trust, self-certification or proof of an application identity API.", "method": "Documentary architectural inference; no executable qualification", "source_label": "Primary specifications; selected-profile analysis", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.4" ], "editorial_references": [], "qualification": "Validate the declared complete composition and local management in an executable deployment; this decision is not measured scale, conformance or interoperability." }, { "id": "S02-LT", "feature": "S02", "stack": "LT", "status": "Y", "reason": "Participants can locally generate the symmetric BPSec key and agree its binding to a private-use EID within their independent domain. The selected local security policy supplies that key; no external cryptographic issuer or CA must authorize it. Counterpart acceptance and private-EID uniqueness still require configuration. This is pairwise identity, not a globally verifiable public-key identity. External lower-layer allocation is separately assessed in S03.", "method": "Specification plus pinned receiver-policy analysis; no runtime experiment", "source_label": "BPSec local key policy and private-use ipn identifier scope", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html#section-3.8.1", "https://www.rfc-editor.org/rfc/rfc9172.html#section-6", "https://www.rfc-editor.org/rfc/rfc9758.html#section-5.5", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/bpsec/policy/bpsec_policy_rule.c" ], "editorial_references": [ "round193-sources.json" ], "qualification": "Exercise locally generated key provisioning and exact-origin policy on both participants; reject mismatched bindings. Enforce private-EID domain confinement and verify identifier uniqueness. S03-LT remains Pending for AOS SCID allocation." }, { "id": "S02-LP", "feature": "S02", "stack": "LP", "status": "Y", "reason": "The selected direct-peer profile uses locally generated Peer IDs and known addresses; no mandatory libp2p-wide identity or directory authority is involved. Underlay allocation is a separate question.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://libp2p.io/docs/peers/" ], "editorial_references": [], "qualification": "" }, { "id": "S02-TO", "feature": "S02", "stack": "TO", "status": "Y", "reason": "An onion-service name is derived from its locally controlled master identity key. Issuing that participant identity requires no external issuer; the public directory authorities remain a separate operational dependency already assessed in S01.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-I2", "feature": "S02", "stack": "I2", "status": "Y", "reason": "I2P locally generates destination/public-private key material; SAM exposes this through DEST GENERATE without needing an existing session. This demonstrates local identity issuance, not independence of all reseeding or naming services. SAM is evidence for generation, not an extra transport layer credited here.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://i2p.net/en/docs/api/samv3/#destination-key-generation" ], "editorial_references": [], "qualification": "" }, { "id": "S02-YG", "feature": "S02", "stack": "YG", "status": "Y", "reason": "Nodes generate key-based identities and can form their own network. No central Yggdrasil address issuer is required. This does not remove underlay dependencies.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/about.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-CJ", "feature": "S02", "stack": "CJ", "status": "Y", "reason": "cjdns derives overlay addresses from locally generated public keys. Underlay provisioning and peer admission remain separate.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/cjdelisle/cjdns" ], "editorial_references": [], "qualification": "" }, { "id": "S02-MQ", "feature": "S02", "stack": "MQ", "status": "Y", "reason": "TLS permits locally trusted certificates and proves possession with CertificateVerify. Under the explicit mutual-authentication profile, participants generate keys and certificates locally; counterparts provision trust. This supplies usable cryptographic identities without external issuance, not self-certifying routable addresses.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.3" ], "editorial_references": [], "qualification": "" }, { "id": "S02-SC", "feature": "S02", "stack": "SC", "status": "N", "reason": "The selected SCION/application-UDP endpoint stack provides no cryptographic participant identity service: the overview explicitly excludes endpoint identity authentication. Therefore the capability to generate such a usable identity locally is not supplied by this composition. AS certificates and self-issuing CA roles concern routing infrastructure, not the compared application endpoint. Out of scope is No under the matrix rule.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/overview.html#scope-and-goals" ], "editorial_references": [], "qualification": "" }, { "id": "S02-RT", "feature": "S02", "stack": "RT", "status": "Y", "reason": "Reticulum supports local identity creation and independently operated networks. The selected serial profile requires no IP allocator, name delegation or global authority.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/whatis.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-NS", "feature": "S02", "stack": "NS", "status": "Y", "reason": "NIP-01 uses author-generated keys and independently chosen relays; no mandatory Nostr-wide identity issuer or relay authority. The chosen WSS/DNS infrastructure is assessed separately in S03.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [], "qualification": "" }, { "id": "S02-MT", "feature": "S02", "stack": "MT", "status": "Y", "reason": "CryptoEngine generates the node key pair locally. No issuer must approve creating it; the separate question of whom the counterpart trusts remains explicit.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/CryptoEngine.cpp#L34" ], "editorial_references": [], "qualification": "" }, { "id": "S02-GN", "feature": "S02", "stack": "GN", "status": "Y", "reason": "The peer public/private key pair is generated on first startup. Known-key peer authentication does not require an external identity issuer; application egos and GNS are not needed for this claim.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "GNUnet v0.20.x peer identities", "sources": [ "https://docs.gnunet.org/v0.20.x/about.html#peer-identities" ], "editorial_references": [], "qualification": "Generate keys in isolated test directories and authenticate known peers without an issuer; inspect entropy and key lifecycle. No execution." }, { "id": "S02-ND", "feature": "S02", "stack": "ND", "status": "Y", "reason": "ndnsec generates the key pair locally. Under the already selected local trust model, counterpart acceptance need not involve an external issuer; public testbed enrollment is separate.", "method": "Documentary analysis and selected-profile inference; no execution", "source_label": "ndn-cxx 0.9.0 local key generation", "sources": [ "https://docs.named-data.net/ndn-cxx/0.9.0/manpages/ndnsec-key-gen.html" ], "editorial_references": [], "qualification": "Exercise locally generated ECDSA keys with independently provisioned consumer trust and no external enrollment; no consumer integration test performed." }, { "id": "S02-AX", "feature": "S02", "stack": "AX", "status": "N", "reason": "No cryptographic participant identity is supplied by this composition; this is not a ruling about callsign licensing.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "S02-BA", "feature": "S02", "stack": "BA", "status": "N", "reason": "This profile provides no cryptographic participant identity, despite permitting locally chosen MAC addresses.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-BL", "feature": "S02", "stack": "BL", "status": "N", "reason": "No cryptographic participant identity is part of the selected IPv6/Babel service.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "IPv6 base protocol, RFC 8200", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-RI", "feature": "S02", "stack": "RI", "status": "Y", "reason": "Participants can generate and provision the pairwise secret and its identity label locally; no external credential issuer must approve the key.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "Peer acceptance and secure key distribution are still required. This is a symmetric participant identity, not an independently verifiable public-key identity." }, { "id": "S02-HP", "feature": "S02", "stack": "HP", "status": "Y", "reason": "The Host Identity is a public key and its HIT is derived locally. The selected peers directly provision trust in those identities.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "No issuer is required by this known-peer profile; peer admission and host-network provisioning remain separate." }, { "id": "S02-CX", "feature": "S02", "stack": "CX", "status": "Y", "reason": "The selected producer generates its signing key locally and the consumer explicitly trusts it. CCNx supports public-key validation without requiring an embedded certificate.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "This is producer identity, not arbitrary name ownership or consumer authentication. Local trust provisioning does not guarantee automatic discovery." }, { "id": "S02-LI", "feature": "S02", "stack": "LI", "status": "N", "reason": "An EID is an IP identifier, not a participant-generated cryptographic identity. Locally provisioned mapping-registration keys authenticate control roles rather than supplying the missing final-participant identity.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-IL", "feature": "S02", "stack": "IL", "status": "N", "reason": "Locally generating a NID does not create a cryptographic participant identity. The selected profile excludes CGA identity binding and IPsec; nonce-based session checks do not satisfy this criterion.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "S02-TS", "feature": "S02", "stack": "TS", "status": "Y", "reason": "The node key pair is generated locally and the private key stays on the device. Its cryptographic identity does not require an external key issuer.", "method": "Official documentation and pinned source/declaration review; no runtime test", "source_label": "Tailscale identity documentation, LocalAPI and PATENTS grant", "sources": [ "https://tailscale.com/docs/concepts/tailscale-identity", "https://tailscale.com/docs/concepts/tailscale-identity", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/PATENTS", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/LICENSE", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/ipn/localapi/localapi.go", "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round588.html", "round588-sources.json" ], "qualification": "Credits only node-key creation. The selected managed service still requires enrollment and external user authentication, and Tailnet Lock signatures govern admission. S01 and S04 retain those authority dependencies." }, { "id": "S02-RA", "feature": "S02", "stack": "RA", "status": "Y", "reason": "In the selected SSH2-inspired enrollment mode, an IPCP uses a locally generated RSA key pair. Peers install its public key under its application-process name and decide locally whether to accept that binding. No certificate authority or external identity issuer is required.", "method": "Pinned documentation and authentication source inspection with explicit policy selection; no execution or audit", "source_label": "IRATI SSH2-inspired authentication policy", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/sm-auth-psoc/sm-auth-psoc-plugin.cc" ], "editorial_references": [ "round665.html" ], "qualification": "Scoped to IPCP cryptographic identity, not civil identity, automatic trust or arbitrary application identity. The README describes local key generation; load_authentication_keys reads local private and pinned peer-public keys. Administrative provisioning remains necessary and is not credited as unprivileged operation." }, { "id": "S03-PN", "feature": "S03", "stack": "PN", "status": "Y", "reason": "The native realization uses locally created cryptographic identities and local forwarding selectors, with no IP allocator or mandatory global naming service (architecture 4.2, 5.6–5.7; wire-v4 4 and 9). Counterpart admission and physical connectivity remain necessary. The IP composition is assessed separately.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#prp-audit" ], "qualification": "" }, { "id": "S03-PI", "feature": "S03", "stack": "PI", "status": "Y", "reason": "For the explicitly selected independent deployment, peers use numeric private IPv4 addresses and locally known PRP identities. RFC 1918 section 3 permits private address use without coordination with IANA or an Internet registry. This removes a mandatory external allocator for that private network, not internal address configuration, inter-network collision management or public Internet allocation dependencies.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://datatracker.ietf.org/doc/html/rfc1918#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "S03-IP", "feature": "S03", "stack": "IP", "status": "Y", "reason": "Cooperating private networks can use locally administered IPv4 private space or locally generated IPv6 ULA prefixes without an external allocator or mandatory naming authority. This independent-deployment capability does not confer public Internet reachability.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [], "qualification": "" }, { "id": "S03-BP", "feature": "S03", "stack": "BP", "status": "Y", "reason": "RFC 9758 reserves Default Allocator node numbers 1..0x3FFF for Private Use within one administrative domain. The selected independent deployment uses that range, private IPv4, local certificate trust and locally agreed dtn collective names. No public allocation or DNS delegation is required. Domain-boundary enforcement and collision-free local assignments remain necessary.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9758.html#section-3.4.3" ], "editorial_references": [], "qualification": "Pin RFC 9758 support and test private-use EID confinement, NODE-ID certificate matching, aggregate exits and local collective names over private IPv4. Verify that gateways reject cross-domain leakage. This does not qualify globally unique identifiers or a complete ION/TCPCLv4/BPSec deployment. No execution performed." }, { "id": "S03-CG", "feature": "S03", "stack": "CG", "status": "Y", "reason": "An independent deployment can use private IPv4 and private-use ipn numbering with locally provisioned names and trust. This is not global public reachability.", "method": "Primary-specification analysis of the explicit composition; no execution", "source_label": "RFC 9758, ipn private-use identifiers", "sources": [ "https://www.rfc-editor.org/rfc/rfc9758.html" ], "editorial_references": [], "qualification": "Pin and validate a compatible executable BPv7/SABR/security composition. Documentary capability is not integrated runtime or conformance evidence." }, { "id": "S03-LT", "feature": "S03", "stack": "LT", "status": "N", "reason": "The selected LTP composition includes the AOS space-link profile. AOS 732.0-B-4 sections 1.1 and 1.6 define its deployment over spacecraft-to-ground or spacecraft-to-spacecraft links; section 4.1.2.2.3 requires the SCID field and refers its assignment to SANA. CCSDS 320.0-M-7 Cor. 1 section 3.4.1 places Q-SCID assignment with SANA, with uniqueness scoped by frame version, frequency band and assignment period. Thus the selected operational space-link composition has an external identifier-allocation dependency even when BP endpoints, LTP engine mappings and cryptographic keys are locally configured. This settles S03 as No for this composition.", "method": "Selected operational-profile scope and normative assignment rule", "source_label": "AOS 732.0-B-4 and CCSDS 320.0-M-7 Cor. 1 assignment procedures", "sources": [ "https://ccsds.org/Pubs/732x0b4.pdf", "https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01/320x0m7c1.pdf" ], "editorial_references": [ "round636.html", "round636-sources.json", "round195-sources.json" ], "qualification": "Section 2 of the assignment procedure explicitly delegates simulation/testing and non-radiating ground simulators or assemblies to local management; section 3.4.6 also allows simulator self-assignment without RF radiation. This exception is preserved, but is not an operational spacecraft-link witness for the selected AOS column. A laboratory or terrestrial reuse of AOS bytes is not silently substituted for that deployment. The decision does not require public IP addresses or DNS, and does not apply to LTP or BPv7 in isolation. It is a documentary inference from the selected space-link scope and explicit assignment rule, not an executed deployment or an assertion that local SCID values cannot be encoded." }, { "id": "S03-LP", "feature": "S03", "stack": "LP", "status": "Y", "reason": "Independent deployment is now explicitly restricted to cooperating private IPv4 networks with numeric peers and locally generated overlay identities. RFC 1918 permits this address use without an external registry assignment, just as for PI. Internal prefix configuration, collisions on network merger and public Internet allocation remain separate requirements.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "S03-TO", "feature": "S03", "stack": "TO", "status": "N", "reason": "The selected composition uses the existing public Tor network. Its relay infrastructure requires public IPv4 reachability, so the complete composition is not independent of external address allocation, even when an onion name is self-generated. A separately operated private Tor test network is a different profile.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://community.torproject.org/relay/relays-requirements/" ], "editorial_references": [], "qualification": "" }, { "id": "S03-I2", "feature": "S03", "stack": "I2", "status": "Y", "reason": "An independent private-IPv4 deployment can enable i2np.allowLocal and supply fresh RouterInfos, numeric NTCP2 contacts and destination keys locally. The NTCP2 address checks explicitly admit local addresses under that setting. No public address allocation is required within this boundary.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/transport/ntcp/NTCPTransport.java" ], "editorial_references": [], "qualification": "Configure all routers consistently, local network/bootstrap and floodfill roles, allowLocal, keys and clock; disable external reseed/DNS. Validate fresh private RouterInfo admission and end-to-end tunnels. Full isolated deployment untested." }, { "id": "S03-YG", "feature": "S03", "stack": "YG", "status": "Y", "reason": "Independent deployment is now explicitly restricted to cooperating private IPv4 networks with numeric peers and locally generated overlay identities. RFC 1918 permits this address use without an external registry assignment, just as for PI. Internal prefix configuration, collisions on network merger and public Internet allocation remain separate requirements.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "S03-CJ", "feature": "S03", "stack": "CJ", "status": "Y", "reason": "Independent deployment is now explicitly restricted to cooperating private IPv4 networks with numeric peers and locally generated overlay identities. RFC 1918 permits this address use without an external registry assignment, just as for PI. Internal prefix configuration, collisions on network merger and public Internet allocation remain separate requirements.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "S03-MQ", "feature": "S03", "stack": "MQ", "status": "Y", "reason": "The independent deployment uses RFC 1918 IPv4 with numeric peers and local certificate trust, requiring neither public address allocation nor DNS delegation. Address/subnet configuration remains necessary (F03 No); global Internet reachability and private-network mergers are outside this result.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html#section-3" ], "editorial_references": [], "qualification": "" }, { "id": "S03-SC", "feature": "S03", "stack": "SC", "status": "N", "reason": "SCION uses globally unique AS numbers and ISD identifiers with allocation rules. Locally scoped endpoint addresses do not remove the external inter-domain numbering dependency of the selected composition.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://docs.scion.org/en/latest/overview.html#isd-and-as-numbering" ], "editorial_references": [], "qualification": "" }, { "id": "S03-RT", "feature": "S03", "stack": "RT", "status": "Y", "reason": "Reticulum supports local identity creation and independently operated networks. The selected serial profile requires no IP allocator, name delegation or global authority.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [ "https://reticulum.network/manual/whatis.html" ], "editorial_references": [], "qualification": "" }, { "id": "S03-NS", "feature": "S03", "stack": "NS", "status": "N", "reason": "The selected public WSS-hostname profile depends on DNS delegation. A self-operated numeric-address or private-name profile would need its own column.", "method": "Documentary analysis", "source_label": "Primary specification / selected profile", "sources": [], "editorial_references": [ "index.html#nostr" ], "qualification": "" }, { "id": "S03-MT", "feature": "S03", "stack": "MT", "status": "Y", "reason": "The independent radio deployment uses locally generated node identities and agreed channel settings, without public IP allocation or DNS delegation. This does not establish globally unique 32-bit identifiers or unrestricted spectrum use.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://meshtastic.org/docs/configuration/radio/security/" ], "editorial_references": [], "qualification": "" }, { "id": "S03-GN", "feature": "S03", "stack": "GN", "status": "Y", "reason": "The selected private-IPv4 underlay and local peer keys/HELLO contacts need no external address allocation for independent deployment. Public Internet reachability and its allocation requirements are separate.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "GNUnet v0.20.x configuration", "sources": [ "https://docs.gnunet.org/v0.20.x/users/configuration.html", "https://docs.gnunet.org/v0.20.x/about.html#peer-identities", "https://docs.gnunet.org/v0.20.x/developers/transport/transport.html", "https://www.rfc-editor.org/rfc/rfc1918.html" ], "editorial_references": [], "qualification": "Exercise the private-IPv4 underlay and supplied HELLO contacts without public allocation or bootstrap. No claim about public routing." }, { "id": "S03-ND", "feature": "S03", "stack": "ND", "status": "Y", "reason": "Locally agreed names and direct Ethernet faces require neither public IP allocation nor DNS delegation.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "NFD 24.07 face management", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "" }, { "id": "S03-AX", "feature": "S03", "stack": "AX", "status": "Y", "reason": "An isolated direct-serial deployment can use locally agreed syntactically valid AX.25-format labels and NET/ROM routes. asc2ax encodes the label/SSID locally; nr_set_mac_address installs the local node address and nr_add_node accepts a locally supplied route. No public IP allocation, DNS delegation or external domain identifier is required for that private deployment. Address uniqueness must still be coordinated locally. This does not infer lawful use of unassigned callsigns on regulated radio, public-network acceptance or global reachability.", "method": "Pinned primary-source inspection and bounded configuration/topology inference; no execution", "source_label": "Linux v6.12 source; NET/ROM 1.3 manual where indicated", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ax25/ax25_addr.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_dev.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c", "https://hamgate.ampr.org/docs/1987_netrom_version_1_3.pdf" ], "editorial_references": [], "qualification": "Provision private serial node labels with no reused public identity assumptions, add routes and communicate while all external naming/allocation services are unavailable. Avoid RF transmission; deployment regulations are outside this classification." }, { "id": "S03-BA", "feature": "S03", "stack": "BA", "status": "Y", "reason": "Locally administered MAC addresses need no public IP allocation or DNS delegation.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Linux 6.12 batman-adv documentation", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "S03-BL", "feature": "S03", "stack": "BL", "status": "Y", "reason": "Locally assigned ULA space supports independent deployment without public address allocation; Internet reachability is separate.", "method": "Documentary analysis and explicit selected-profile inference; no execution", "source_label": "Locally assigned IPv6 ULA, RFC 4193", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [], "qualification": "" }, { "id": "S03-RI", "feature": "S03", "stack": "RI", "status": "Y", "reason": "The selected locally generated ULA prefix, local link configuration and numeric peers permit independent deployment without public IP allocation or DNS delegation.", "method": "Documentary composition review; no runtime or sleep experiment", "source_label": "RPL, ULA, DTLS 1.3 and TLS 1.3 specifications; unchanged IoT profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [ "round256-sources.json", "round244.html" ], "qualification": "Address uniqueness and local administration remain necessary. No public Internet reachability or right to use a particular radio channel is inferred." }, { "id": "S03-HP", "feature": "S03", "stack": "HP", "status": "Y", "reason": "The independent deployment uses RFC 1918 private IPv4 locators, locally generated HIP identities and pinned numeric peers. These choices require neither public address allocation nor DNS delegation.", "method": "Documentary dependency and state inventory; no execution", "source_label": "Primary protocol specifications and selected local deployment/trust configuration", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html#section-3" ], "editorial_references": [ "round264-sources.json" ], "qualification": "HIT derivation is local; the standardized identifier format does not require an individual allocation request. Private addressing does not provide public Internet reachability, and independently configured networks can have overlapping addresses." }, { "id": "S03-CX", "feature": "S03", "stack": "CX", "status": "Y", "reason": "The selected CCNx deployment combines private IPv4 UDP peers with locally chosen content names and configured name-prefix routes. Producer keys are locally generated and trusted; no external address allocator or name delegation is required.", "method": "Documentary dependency and state inventory; no execution", "source_label": "Primary protocol specifications and selected local deployment/trust configuration", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.3", "https://www.rfc-editor.org/rfc/rfc1918.html" ], "editorial_references": [ "round264-sources.json" ], "qualification": "This bounded deployment does not claim globally unique human-readable names or automatic Internet reachability. Local naming conflicts and private-address overlap still require local handling." }, { "id": "S03-LI", "feature": "S03", "stack": "LI", "status": "Y", "reason": "A cooperating private deployment can provision IPv4 EIDs, RLOCs and numeric mapping-service addresses from RFC 1918 space. Its participant-operated mapping system and local registration keys need no public DNS delegation or external address allocator. This is the independent-domain capability assessed by S03, not global Internet reachability.", "method": "Documentary scope review", "source_label": "Primary RFCs and IETF Trust provisions", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html#section-3", "https://www.rfc-editor.org/rfc/rfc9300.html#section-1.1", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "Use non-overlapping private subnets within the cooperating domain and participant-operated mappings. Public routing, public EID uniqueness and Internet interconnection require separate arrangements; no change to global-scale verdicts." }, { "id": "S03-IL", "feature": "S03", "stack": "IL", "status": "Y", "reason": "ILNP permits local Locators based on IPv6 ULA prefixes. An independent domain can combine those locally generated prefixes with local NIDs and locally administered DNS NID/L64 records, without public address allocation or DNS delegation. RFC 6748 describes local numbering and local DNS operation.", "method": "Documentary scope review", "source_label": "Primary RFCs and IETF Trust provisions", "sources": [ "https://www.rfc-editor.org/rfc/rfc6748.html#section-2.1", "https://www.rfc-editor.org/rfc/rfc6748.html#section-2.4", "https://www.rfc-editor.org/rfc/rfc4193.html" ], "editorial_references": [], "qualification": "Independent-domain witness only, without public connectivity or locator rewriting. DNS is still required in this composition and remains a local authority; this does not change S01 or claim that the baseline external-DNS bootstrap works through an outage." }, { "id": "S03-TS", "feature": "S03", "stack": "TS", "status": "N", "reason": "The selected managed deployment depends on externally delegated service names and publicly allocated infrastructure addresses for coordination and relay access. Private overlay addresses do not make that complete deployment independent of allocation authorities.", "method": "Primary documentation, pinned source and explicit whole-stack inference", "source_label": "Tailscale bootstrap DNS, infrastructure requirements and RFC 4271", "sources": [ "https://tailscale.com/docs/reference/faq/firewall-ports", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/net/dnsfallback/dnsfallback.go", "https://tailscale.com/docs/reference/faq/firewall-ports", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2" ], "editorial_references": [ "round590.html", "round590-sources.json" ], "qualification": "Users need not obtain their own domain or public prefix. This evaluates the whole selected hosted composition; a privately operated alternative control plane is not selected." }, { "id": "S03-RA", "feature": "S03", "stack": "RA", "status": "Y", "reason": "Participants configure their own DIF and application names and Ethernet VLAN. The documented deployment requires no public address allocation or DNS delegation.", "method": "Primary deployment documentation and architectural dependency inference; no execution", "source_label": "IRATI Ethernet tutorial and software architecture documentation", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round651.html" ], "qualification": "Local independent deployment only. Configuration, local address uniqueness and membership coordination remain necessary. This does not establish automatic global name uniqueness or global reachability." }, { "id": "S04-PN", "feature": "S04", "stack": "PN", "status": "Y", "reason": "PRP Architecture sections 5.4–5.6 place authority in local relationship policy or explicit delegation and require operation from sufficient local relationship information without a mandatory global naming, routing, identity, governance or ledger service. The selected known-peer profile does not add an external service. Participants can therefore administer the necessary policy, keys and communication infrastructure themselves.", "method": "Documentary review; no new sleep, load or network execution", "source_label": "Pinned PRP architecture/lifecycle and primary IP RFCs; retained bytes, 2026-10-15", "sources": [], "editorial_references": [ "round247-sources.json", "round247-sources.json" ], "qualification": "Documentary capability, not proof of global routing completion or deployed implementation maturity. The compatible native carrier must still be provisioned and access authorized." }, { "id": "S04-PI", "feature": "S04", "stack": "PI", "status": "Y", "reason": "PRP Architecture sections 5.4–5.6 place authority in local relationship policy or explicit delegation and require operation from sufficient local relationship information without a mandatory global naming, routing, identity, governance or ledger service. The selected known-peer profile does not add an external service. Participants can therefore administer the necessary policy, keys and communication infrastructure themselves.", "method": "Documentary review; no new sleep, load or network execution", "source_label": "Pinned PRP architecture/lifecycle and primary IP RFCs; retained bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc4193.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round247-sources.json", "round247-sources.json" ], "qualification": "Documentary capability, not proof of global routing completion or deployed implementation maturity. The selected private IPv4/UDP underlay can also be locally administered; public Internet allocation and access remain separate." }, { "id": "S04-IP", "feature": "S04", "stack": "IP", "status": "Y", "reason": "The declared independent-deployment profile permits locally provisioned private IPv4 or IPv6 ULA addressing and routes. Participants can operate routers and any selected routing-control roles themselves; the datagram service does not mandate a vendor cloud, activation authority or external trust service.", "method": "Documentary review; no new sleep, load or network execution", "source_label": "Pinned PRP architecture/lifecycle and primary IP RFCs; retained bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc1918.html", "https://www.rfc-editor.org/rfc/rfc4193.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "round247-sources.json" ], "qualification": "Credit administration of the independent network, not global public reachability or issuer-free cryptographic identity. RFC 4193 also permits locally assigned ULA prefixes. Local network administrators and allocation choices remain; they are allowed by S04." }, { "id": "S04-BP", "feature": "S04", "stack": "BP", "status": "Y", "reason": "The selected BP/TCPCL composition uses participant-operated CAs, locally installed trust, numeric peers and locally provisioned BPSec keys. Its mandatory transport, certification and bundle-forwarding roles can be operated by the participants; public CA, online OCSP and hosted discovery are not selected.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "Certificate path and NODE-ID validation still apply. Local administration does not establish global EID reachability, interoperability, or absence of certification roles. Assessment follows the existing local-trust profile." }, { "id": "S04-CG", "feature": "S04", "stack": "CG", "status": "Y", "reason": "SABR consumes contact/range plans and local routing state; section 2.3 and annex B leave plan distribution outside its protocol rather than mandate a particular external operator. In the selected composition participants supply those plans, clocks, numeric peers, certificate trust and BPSec keys themselves. Bundle forwarding, TCPCL trust and route calculation can therefore remain under participant administration.", "method": "Documentary composition review; no new execution", "source_label": "Primary protocol documents and Linux v6.12 local management source", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9174.html" ], "editorial_references": [ "round252-sources.json", "round249.html" ], "qualification": "The plan must be maintained and its updates secured. This is not automatic discovery, authority-free planning, or a verified BPv7/SABR executable integration. Public allocation and global reachability remain separate." }, { "id": "S04-LT", "feature": "S04", "stack": "LT", "status": "Y", "reason": "LTP section 5 assigns link timing and operational inputs to the local operating environment. AOS 732.0-B-4 section 5 defines managed parameters without prescribing a particular management implementation. With locally supplied SABR plans, engine/peer mappings and BPSec keys, the selected mission can administer its mandatory operational components without a fixed external service provider.", "method": "Documentary composition review; no new execution", "source_label": "Primary protocol documents and Linux v6.12 local management source", "sources": [ "https://www.rfc-editor.org/rfc/rfc5326.html#section-5", "https://ccsds.org/Pubs/732x0b4.pdf", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round252-sources.json", "round195.html" ], "qualification": "This does not waive AOS spacecraft identifier allocation or settle S03-LT. S04 permits local mission coordination and excludes identifier allocation from its test. Complete BPv7/SABR/LTP/Encapsulation/AOS integration, conformance and runtime qualification remain open." }, { "id": "S04-LP", "feature": "S04", "stack": "LP", "status": "Y", "reason": "The selected QUIC transport accepts numeric IP/UDP multiaddresses and authenticates the known Peer ID through libp2p TLS. The TLS specification uses a self-signed certificate carrying a host-key proof, rather than a public CA chain. Participants can provision keys, peer contacts and admission policy locally without a mandatory external discovery or certification operator.", "method": "Documentary dependency review; no runtime execution", "source_label": "Primary protocol and configuration documentation; selected composition", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/quic/README.md", "https://raw.githubusercontent.com/libp2p/specs/master/tls/tls.md" ], "editorial_references": [ "round251-sources.json" ], "qualification": "This applies to the existing known-peer profile. It does not add public DHT bootstrap, relays or NAT services, nor claim that arbitrary libp2p applications avoid external services." }, { "id": "S04-TO", "feature": "S04", "stack": "TO", "status": "N", "reason": "The selected public Tor/onion-service composition relies on the public network directory authorities and their signed consensus. Ordinary participants cannot place those indispensable public-network roles under their own administration merely by operating a client, relay or onion service.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://spec.torproject.org/dir-spec/outline.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "A separately administered private Tor network would be a different deployment. This No does not deny open implementation, onion-service key ownership or censorship-resistance properties; it applies to the selected public network and the S04 control requirement." }, { "id": "S04-I2", "feature": "S04", "stack": "I2", "status": "Y", "reason": "I2P distributes origin-signed RouterInfo and LeaseSet records through floodfill routers, whose role is not assigned by a central directory authority. Together with the already selected local RouterInfo bootstrap, known destination keys and private-IP allowLocal configuration, participants can operate routing, floodfill and destination roles under their own administration.", "method": "Documentary dependency review; no runtime execution", "source_label": "Primary protocol and configuration documentation; selected composition", "sources": [ "https://i2p.net/en/docs/overview/network-database/", "https://i2p.net/en/docs/overview/faq/", "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/transport/ntcp/NTCPTransport.java" ], "editorial_references": [ "round251-sources.json" ], "qualification": "Fresh bootstrap data, enough reachable routers for the selected tunnels and a correct clock remain necessary. This credits the existing independent-deployment profile, not a new substitution for the public Internet case. Full isolated-stack execution and anonymity qualification remain unproven." }, { "id": "S04-YG", "feature": "S04", "stack": "YG", "status": "Y", "reason": "Yggdrasil supports locally generated node keys and explicitly configured peer connections; public-peer lists are optional assistance. The selected private-IP, numeric-peer TLS mesh can keep its peer configuration, keys and forwarding nodes under participant administration without a vendor activation or mandatory public directory.", "method": "Documentary dependency inventory; no new runtime execution", "source_label": "Official configuration documentation and existing selected composition", "sources": [ "https://yggdrasil-network.github.io/configuration.html" ], "editorial_references": [ "round250-sources.json" ], "qualification": "This applies to the selected adjacent private-IP mesh with pinned keys. It does not claim Internet-wide reachability, absence of local setup, or measured global capacity." }, { "id": "S04-CJ", "feature": "S04", "stack": "CJ", "status": "Y", "reason": "The pinned route server reads participant-supplied configuration, starts its own HTTP/WebSocket service, optionally connects to the local cjdns router, and connects to the explicit config.peers list. The example's numeric server address is configurable, not a fixed operational authority. Combined with the selected local node keys and private numeric peer credentials, participants can administer the required routing and replication roles themselves.", "method": "Source and protocol dependency review; no runtime execution", "source_label": "Pinned cjdns route-server source and RFC 1034", "sources": [ "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/main.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/config.example.json" ], "editorial_references": [ "round253-sources.json", "round215.html" ], "qualification": "This is a dependency finding for the selected route-server design, not a return to a DHT-only profile. E03-CJ and the client/server version-binding and interoperability qualifications remain open. The source comment recommending an existing scanning server is not a protocol requirement; no scanner or network process was started." }, { "id": "S04-MQ", "feature": "S04", "stack": "MQ", "status": "Y", "reason": "The selected QUIC/TLS composition uses locally generated mutually trusted certificates and numeric peers. TLS authentication does not force a public CA or vendor-operated identity service; participants operate endpoints and provision trust themselves.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "This is a profile-level dependency conclusion, not proof of multipath implementation interoperability. Certificate acceptance policy is still required; global address allocation and public reachability remain separate." }, { "id": "S04-SC", "feature": "S04", "stack": "SC", "status": "Y", "reason": "SCION assigns trust roots, voting keys and TRC update policy to an ISD. Participants administering that domain can operate its certification and control roles themselves; no specific external vendor is mandated by these mechanisms.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://docs.scion.org/en/latest/cryptography/trc.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "This is participant-controlled domain administration, not authority-free communication. S01 remains separate; AS/ISD allocation and interdomain admission are not waived. Bootstrap trust and timely certificate/TRC renewal remain necessary." }, { "id": "S04-RT", "feature": "S04", "stack": "RT", "status": "Y", "reason": "Reticulum 1.5.5 places configuration and local identity in an operator-controlled directory. Participants can enable transport nodes and configure direct serial interfaces and secret IFAC credentials themselves. The selected serial mesh requires no hosted bootstrap, cloud identity provider or IP service.", "method": "Documentary dependency inventory; no new runtime execution", "source_label": "Official configuration documentation and existing selected composition", "sources": [ "https://reticulum.network/manual/using.html", "https://reticulum.network/manual/interfaces.html" ], "editorial_references": [ "round250-sources.json" ], "qualification": "This dependency conclusion does not resolve the separate global-scale announce/path-discovery workload. Local interface and credential provisioning remain necessary; no energy, sleep or throughput result follows." }, { "id": "S04-NS", "feature": "S04", "stack": "NS", "status": "Y", "reason": "A participant-administered deployment can retain the selected two WSS relay paths and DNS hostnames without mandatory outside naming or certificate services. Unbound static local zones answer both positive and negative queries from maintained configuration, rather than a finite recursive cache. Pinned python-nostr forwards per-relay ssl_options to websocket-client; the latter accepts an explicit SSLContext and resolves the WSS hostname through the OS resolver. A local CA bundle, required certificate/hostname verification and TLS 1.3 can therefore be selected without a public CA. Nginx supports local certificate/key files and WebSocket Upgrade forwarding to each operator-controlled nostr-rs-relay. Participant administrators maintain DNS records, issue/renew certificates and distribute trust changes themselves.", "method": "Complete naming/trust administrative dependency trace; configured plausibility witness, no runtime certification", "source_label": "Pinned Nostr client and WebSocket source; authoritative Unbound, nginx and Python TLS documentation", "sources": [ "https://nlnetlabs.nl/documentation/unbound/unbound.conf/", "https://raw.githubusercontent.com/jeffthibault/python-nostr/37cb66ba2d3968b2d75cc8ad71c3550415ca47fe/nostr/relay.py", "https://raw.githubusercontent.com/websocket-client/websocket-client/3dc494588c4bc6ca1cbb745e9d110108f6bf04f0/websocket/_http.py", "https://nginx.org/en/docs/http/ngx_http_ssl_module.html", "https://nginx.org/en/docs/http/websocket.html", "https://docs.python.org/3.12/library/ssl.html" ], "editorial_references": [ "round329-sources.json", "round329-witness.json" ], "qualification": "Conditional documentary deployment witness, not a performed integration test or default behavior of every Nostr client. Clients use participant resolvers with static records for both actual relay hostnames, no external resolver/proxy fallback, and locally administered TLS roots; certificate SANs match the names and validity is maintained with a local clock policy. Keep the two separate relay paths, regular NIP-01 events, existing in-memory/no-log profile and separate author contexts. Disable optional external NIP-05 validation, gRPC authorization, payments, NIP-42 and outsourced certificate automation. Public hostname/address allocation is still S03; global reachability and BGP are still G01. This does not replace a fixed public network with a private clone: the selected profile already specifies operator-controlled relays. No other cell or profile is changed." }, { "id": "S04-MT", "feature": "S04", "stack": "MT", "status": "Y", "reason": "The selected standalone LoRa mesh operates through participant-configured radios, local serial clients and matching radio parameters. Channel keys and endpoint trust are provisioned locally; neither MQTT nor Internet/cellular service is required. No vendor account or hosted coordination service is part of this composition.", "method": "Documentary dependency inventory; no new runtime execution", "source_label": "Official configuration documentation and existing selected composition", "sources": [ "https://meshtastic.org/docs/overview/", "https://meshtastic.org/docs/configuration/radio/channels/" ], "editorial_references": [ "round250-sources.json" ], "qualification": "This conclusion retains the pinned firmware and existing PKI/private-channel choices. Current documentation is used only for local configuration and offline operation; no new cipher or feature is silently enabled. Radio regulation and hardware compatibility remain separate obligations." }, { "id": "S04-GN", "feature": "S04", "stack": "GN", "status": "Y", "reason": "The 0.20.x manual documents disabling default bootstrap contacts and directly importing a peer HELLO. With the selected numeric private-IP neighbors and local keys, participants can administer the UDP/CORE/CADET/R5N nodes and discovery roles themselves; a gnunet.org hostlist is not mandatory.", "method": "Documentary dependency review; no runtime execution", "source_label": "Primary protocol and configuration documentation; selected composition", "sources": [ "https://docs.gnunet.org/v0.20.x/users/configuration.html" ], "editorial_references": [ "round251-sources.json", "round125.html" ], "qualification": "Disable bundled external contacts and hostlist learning as required by the existing profile; importing local HELLOs is not automatic zero-configuration discovery. Complete executable integration and global capacity remain separate qualifications." }, { "id": "S04-ND", "feature": "S04", "stack": "ND", "status": "Y", "reason": "NFD 24.07 exposes local Ethernet-face creation and local name-prefix route management. With the selected known content/key names and locally configured trust anchors, participants can operate forwarders, producers and consumer trust without public testbed enrollment or an external naming or certification service.", "method": "Documentary dependency inventory; no new runtime execution", "source_label": "Official configuration documentation and existing selected composition", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html", "https://docs.named-data.net/NFD/24.07/manpages/nfdc-route.html" ], "editorial_references": [ "round250-sources.json" ], "qualification": "Local names, routes and trust must be provisioned. This does not claim automatic global discovery, public namespace recognition, consumer authentication or encrypted content. Public-testbed administration is not part of this selected composition." }, { "id": "S04-AX", "feature": "S04", "stack": "AX", "status": "Y", "reason": "For the already selected private direct-serial deployment, Linux NET/ROM exposes locally provisioned node addresses and route insertion through nr_set_mac_address and nr_add_node. Participants administer the interfaces, node labels and routes; there is no required external directory, identity signer, activation or hosted coordination service in that composition.", "method": "Documentary composition review; no new execution", "source_label": "Primary protocol documents and Linux v6.12 local management source", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_dev.c" ], "editorial_references": [ "round252-sources.json", "round118.html" ], "qualification": "This preserves the private serial witness used by S01/S03. It makes no claim about permission to transmit on amateur spectrum, public callsign assignment, cryptographic authentication, or unprivileged interface configuration. No new circuit execution was performed." }, { "id": "S04-BA", "feature": "S04", "stack": "BA", "status": "Y", "reason": "Linux batman-adv forms the selected native layer-2 mesh through locally created mesh interfaces and attached participant-controlled links. Its distributed forwarding does not require a vendor activation, external directory or public trust service.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "Gateway service is disabled in the selected composition. No end-to-end authentication, global reachability or unprivileged kernel-module administration is inferred." }, { "id": "S04-BL", "feature": "S04", "stack": "BL", "status": "Y", "reason": "Babel exchanges routing information among locally administered routers. The selected IPv6/ULA composition uses numeric destinations and local interface and route policy, without a mandatory public directory, cloud controller or external issuer.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "Router configuration and participant policy remain necessary. This verdict does not establish Internet-scale routing, endpoint authentication or independence from public allocations when a different deployment uses them." }, { "id": "S04-RI", "feature": "S04", "stack": "RI", "status": "Y", "reason": "The selected IoT composition places the RPL root, routers, ULA configuration and numeric peers under participant administration. Its DTLS 1.3 pairwise external PSKs are provisioned locally; no manufacturer cloud, DNS or public CA is a mandatory component.", "method": "Documentary dependency inventory; profile-level inference, no runtime test", "source_label": "Official protocol documentation and existing selected composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round249-sources.json" ], "qualification": "A local RPL root remains a coordination role. Selected RPL control is unsecured on an access-controlled link; DTLS application protection does not authenticate routing. No full-stack execution or global scalability result is claimed." }, { "id": "S04-HP", "feature": "S04", "stack": "HP", "status": "Y", "reason": "Known peers can administer their identities, trust policy and direct HIP/ESP communication themselves; this profile requires no fixed external service.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Scoped to the declared independent private-IP network, not arbitrary public reachability or operation through unsupported NATs. The ECDSA HIT-suite hash is corrected explicitly to SHA-384; ESP remains HMAC-SHA-256." }, { "id": "S04-CX", "feature": "S04", "stack": "CX", "status": "Y", "reason": "Participants operate the selected forwarders, configure FIB entries and supply producer/consumer trust locally. CCNx leaves trust policy to the deployment rather than requiring one fixed outside authority.", "method": "Documentary classification, no new runtime or interoperability test", "source_label": "Primary RFCs and explicit selected composition; retained source bytes, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round246-sources.json", "round245.html" ], "qualification": "Local administration is allowed by S04. Static configured names do not demonstrate automatic routing or global-scale discovery." }, { "id": "S04-LI", "feature": "S04", "stack": "LI", "status": "Y", "reason": "The selected Map-Server, Map-Resolver, xTR and registration-key roles can be administered by the participants. RFC 9301 defines their interfaces without requiring one particular vendor or external service operator. This credits a participant-controlled operational domain, not authority-free operation or global allocation independence.", "method": "Specification review; unchanged selected profile", "source_label": "rfc9301.html#section-4; rfc9300.html#section-1.1", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-4", "https://www.rfc-editor.org/rfc/rfc9300.html#section-1.1" ], "editorial_references": [], "qualification": "Provision all necessary mapping and routing components in the participant-controlled domain; global reachability and implementation interoperability remain separate qualifications." }, { "id": "S04-IL", "feature": "S04", "stack": "IL", "status": "Y", "reason": "The required ILNP endpoint functions, routers and authoritative DNS NID/L64 service can be deployed within a participant-administered domain. The standard DNS record formats and ILNP interfaces impose no indispensable designated external operator. Local naming authority remains present, so this does not change S01.", "method": "Specification review; unchanged selected profile", "source_label": "rfc6740.html#section-4; rfc6741.html; rfc6742.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6742.html" ], "editorial_references": [], "qualification": "Bounded independently administered domain only; does not establish public DNS delegation, globally routable prefixes or interoperability of an untested executable composition." }, { "id": "S04-TS", "feature": "S04", "stack": "TS", "status": "N", "reason": "Participants administer their tailnet policy but do not administer the mandatory hosted coordination service. Headscale would be a different selected composition.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "S04-RA", "feature": "S04", "stack": "RA", "status": "Y", "reason": "IRATI places management, enrollment, naming and flow/resource management in locally operated IPC managers and IPC-process daemons. These components can be administered by the participants; the documented local setup does not require a vendor-hosted coordination service.", "method": "Primary deployment documentation and architectural dependency inference; no execution", "source_label": "IRATI Ethernet tutorial and software architecture documentation", "sources": [ "https://github.com/IRATI/stack/wiki/Software-architecture-overview", "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)" ], "editorial_references": [ "round651.html" ], "qualification": "Credits participant administration, not absence of all authorities. Local managers still enforce permissions. No managed public service or remote activation is selected; no fresh runtime or production-adoption claim." }, { "id": "G01-PN", "feature": "G01", "stack": "PN", "status": "Y", "reason": "Yes at the architectural level for native PRP. The scoped Bloom discovery construction retains local destination catalogs, adjacency state and bounded nonrecursive horizon summaries; requester-directed exploration obtains further hints through contacts and confirms the destination exactly. Paths learned by the requester can be retained selectively. This construction does not require a transit router or control service to enumerate all globally reachable identities. Summary positives are candidates, not exact global routes. The global graph/catalog arrays in the experimental harness describe the simulated environment, not a mandatory directory queried by the deployed requester. The earlier DISC-005 authorized-introduction gate concerned a specific discovery exchange and is not a necessary condition for this state-placement criterion. This decision follows the mechanism inventory, not merely G05's Yes.", "method": "Architectural state inventory and reconciliation of later evidence", "source_label": "PRP architecture section 8.4; BloomRoute scoped catalogs, bounded horizons and observed-path exploration", "sources": [], "editorial_references": [ "round410.html", "round410-evidence.json", "round402-evidence.json", "round402.html", "round364-sources.json" ], "qualification": "Conditional on reachable, published targets within the selected relationship views and usable adjacencies. G01 does not grant application access, require discovery of unpublished identities, or guarantee cheap exhaustive search. False positives, saturation and finite exploration budgets can make discovery expensive or unsuccessful; the adverse BloomRoute results remain relevant. The evidence is an architectural construction with modeled path/session transport, not integrated HS2 or normative DISC-005 interoperability. It does not establish measured world-scale capacity, latency or zero routing state. Optional recursive/global catalogs are not credited as the witness. PRP over the selected globally BGP-routed IP underlay remains No for whole-stack G01." }, { "id": "G01-PI", "feature": "G01", "stack": "PI", "status": "N", "reason": "Fix the previously unspecified global underlay of the IPv4/UDP/PRP column to the conventional BGP-routed Internet, consistently with IP, multipath QUIC and the global profiles refined in round119. Under that composition, PRP packets still require IP reachability between their transport peers. A default route at the endpoint moves global prefix reachability into upstream infrastructure rather than removing it. G01 evaluates the complete stack, so this selected composition is No regardless of how PRP partitions its own identity discovery. This is not a theorem that every IP topology needs BGP, that every router has a full table, or that PRP requires a global identity table. Adjacent-only/private IP meshes and native PRP are distinct constructions. Native G01-PN remains Pending; its discovery-signaling evidence is unchanged.", "method": "Explicit whole-stack deployment inference; no network or scale experiment", "source_label": "RFC 4271 and the same global-underlay convention already used in round119", "sources": [ "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2" ], "editorial_references": [ "round119.html", "round127.html" ], "qualification": "" }, { "id": "G01-IP", "feature": "G01", "stack": "IP", "status": "N", "reason": "The declared conventional global-unicast deployment retains global prefix reachability in its BGP/MP-BGP routing infrastructure. Edge defaults relocate responsibility; they do not eliminate it.", "method": "Documentary analysis", "source_label": "Primary specification / explicit IP composition", "sources": [ "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-BP", "feature": "G01", "stack": "BP", "status": "N", "reason": "Explicit deployment refinement: use conventional globally routed IPv4/BGP, as already selected for IP and MQ. Edge defaults relocate global prefix reachability upstream rather than eliminate it. BP endpoint aggregation and contact/gateway rules do not replace the selected TCPCLv4 transport routing. This verdict does not require every bundle node to keep every EID, and does not deny disconnected or private BP deployments. This is a whole-stack verdict for that deployment, not a theorem about every possible IP topology.", "method": "Documentary composition analysis; no execution", "source_label": "Primary transport/discovery documentation and RFC 4271; declared deployment inference", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "Shared G01/G03 qualification: pin a BP implementation supporting aggregate ipn exits and the selected TCPCLv4/BPSec profile; validate gateway lookup and inventory local routes, group fanout and retained-bundle state. ION documentation establishes the routing mechanism, not interoperability of the complete comparison profile. No execution performed." }, { "id": "G01-CG", "feature": "G01", "stack": "CG", "status": "Y", "reason": "A constructive hierarchy avoids a complete global reachability table: assign contiguous ipn node-number ranges to subtrees. Each gateway keeps its own endpoint, immediate-child ranges and a parent default exit. ION documents narrowest-range exit selection after local CGR/direct-neighbor routing, and re-forwarding toward a reachable gateway. Provision only adjacent egress/contact data. A bundle ascends until a gateway contains the destination in a child range, then descends to it. Root gateways retain child aggregates rather than every destination; no global directory or replicated global contact graph is required by this construction.", "method": "Constructive documentary plausibility; no runtime or capacity experiment", "source_label": "Pinned ION ipnrc: exit semantics, routing precedence and gateway reachability", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/ipnrc.pod" ], "editorial_references": [ "round306-sources.json", "round309-sources.json" ], "qualification": "For the selected private-IPv4 TCPCL/TLS composition, use directly adjacent numeric private-IP peers and per-neighbor trust. BP provides long-haul forwarding; the witness does not require IP transit or a BGP Internet underlay. This is a deployment condition, not a claim that ordinary Internet routing avoids global tables. Architectural plausibility under an explicitly provisioned finite hierarchy, unique hierarchical node numbers and usable adjacent contacts within bundle lifetime. Every exit gateway needs an actual local egress plan or computable local route. Regional contact/trust administration is local, not a hidden global planner. No claim of automatic numbering, automatic convergence, arbitrary-topology routing, failure recovery, optimal routes, full ION/profile execution or measured global capacity. A failed child path may invalidate the witness; this is not a resilience proof. G05 remains Pending." }, { "id": "G01-LT", "feature": "G01", "stack": "LT", "status": "Y", "reason": "A constructive hierarchy avoids a complete global reachability table: assign contiguous ipn node-number ranges to subtrees. Each gateway keeps its own endpoint, immediate-child ranges and a parent default exit. ION documents narrowest-range exit selection after local CGR/direct-neighbor routing, and re-forwarding toward a reachable gateway. Provision only adjacent egress/contact data. A bundle ascends until a gateway contains the destination in a child range, then descends to it. Root gateways retain child aggregates rather than every destination; no global directory or replicated global contact graph is required by this construction.", "method": "Constructive documentary plausibility; no runtime or capacity experiment", "source_label": "Pinned ION ipnrc: exit semantics, routing precedence and gateway reachability", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/ipnrc.pod" ], "editorial_references": [ "round306-sources.json", "round309-sources.json" ], "qualification": "Use adjacent LTP engines over the selected Encapsulation/AOS links with local engine/channel mappings. No global engine directory or IP underlay is introduced. Space-link identifier allocation and S03 are separate and unchanged. Architectural plausibility under an explicitly provisioned finite hierarchy, unique hierarchical node numbers and usable adjacent contacts within bundle lifetime. Every exit gateway needs an actual local egress plan or computable local route. Regional contact/trust administration is local, not a hidden global planner. No claim of automatic numbering, automatic convergence, arbitrary-topology routing, failure recovery, optimal routes, full ION/profile execution or measured global capacity. A failed child path may invalidate the witness; this is not a resilience proof. G05 remains Pending." }, { "id": "G01-LP", "feature": "G01", "stack": "LP", "status": "N", "reason": "Explicit deployment refinement: use conventional globally routed IPv4/BGP, as already selected for IP and MQ. Edge defaults relocate global prefix reachability upstream rather than eliminate it. Known numeric peers and Peer IDs still require QUIC transport reachability. Peer discovery remains distinct from IP forwarding. No DHT or circuit relay is implicitly added; an optional partitioned peer directory would not remove the selected global IP infrastructure. This is a whole-stack verdict for that deployment, not a theorem about every possible IP topology.", "method": "Documentary composition analysis; no execution", "source_label": "Primary transport/discovery documentation and RFC 4271; declared deployment inference", "sources": [ "https://libp2p.io/docs/listen-and-dial/", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-TO", "feature": "G01", "stack": "TO", "status": "N", "reason": "The selected public Tor composition retains a common global catalog of eligible public relays in its directory consensus. Authorities compute the same complete consensus, including relay identity and reachability records, rather than partitioning that catalog among independent lookup domains. Local circuit forwarding does not remove this required control-plane inventory. The catalog is of public relays, not all clients, bridges or onion services; this negative does not assert that every relay stores every endpoint.", "method": "Criterion migration / documentary review", "source_label": "Primary specification / selected profile", "sources": [ "https://spec.torproject.org/dir-spec/computing-consensus.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-I2", "feature": "G01", "stack": "I2", "status": "N", "reason": "Explicit deployment refinement: use conventional globally routed IPv4/BGP, as already selected for IP and MQ. Edge defaults relocate global prefix reachability upstream rather than eliminate it. Partial floodfill knowledge and iterative netDb referrals remain valid. The No concerns NTCP2 transport over the declared global IPv4 deployment, including RouterInfo publication, not a supposed compulsory complete netDb at every I2P router. This is a whole-stack verdict for that deployment, not a theorem about every possible IP topology.", "method": "Documentary composition analysis; no execution", "source_label": "Primary transport/discovery documentation and RFC 4271; declared deployment inference", "sources": [ "https://github.com/i2p/i2p.www/blob/3afd7340f51d53e407986e2d2ca9cf004b708b35/i2p2www/pages/site/docs/how/network-database.html", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-YG", "feature": "G01", "stack": "YG", "status": "Y", "reason": "Architectural credit for an explicit connected mesh whose TCP/TLS peerings use only adjacent private-IP links. Distributed tree coordinates, keyspace routing and path setup provide multi-hop reachability; the documented routing design requires no node, including the tree root, to maintain a complete destination routing table. Adjacent IP links introduce no global IP routing dependency. This is not a verdict for the Internet-backed public testbed or a quantitative scale result.", "method": "Criterion migration / documentary review", "source_label": "Primary specification / selected profile", "sources": [ "https://yggdrasil-network.github.io/implementation.html" ], "editorial_references": [], "qualification": "Bind the adjacent-link topology to the pinned Yggdrasil/Ironwood implementation; inventory root, tree, keyspace, Bloom and path-cache state, convergence and lookup completion. Verify no remote IP peer or external discovery dependency is introduced. No global deployment, worst-case state bound or G05 capacity measurement was executed." }, { "id": "G01-CJ", "feature": "G01", "stack": "CJ", "status": "N", "reason": "In the selected replicated route-server design, a server answers gr queries from its own node inventory and Dijkstra graph. Both source and target must exist locally; a missing target produces a reply without a route, not a delegated lookup. Peer synchronization exchanges known announcement inventories and fetches missing announcements. A server providing arbitrary global destination lookup therefore needs global destination reachability records and a connecting graph. This is control-plane replication, despite compact labels at transit switches. It does not require every possible edge or every client to hold a complete table, and is not a verdict for the older cjdns DHT design.", "method": "Read-only source analysis and whole-stack architectural inference", "source_label": "Pinned route-server query, local graph and announcement synchronization", "sources": [ "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server/service.rs#L200", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server/route.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/peer.rs" ], "editorial_references": [], "qualification": "The selected route-server composition still requires cjdns client/server interoperability qualification, including announcement signatures/state hashes and route replies. No global deployment or resource-capacity experiment was performed. G04 query distribution remains Yes; G05 capacity remains Pending. This negative is derived from the selected control-plane design and does not rely on assuming a conventional Internet underlay." }, { "id": "G01-MQ", "feature": "G01", "stack": "MQ", "status": "N", "reason": "The global witness selects IPv6 with BGP/MP-BGP prefix routing. For global deployment, explicitly select the same conventional BGP-routed IPv4/IPv6 Internet underlay used by the IP column. QUIC and its multipath extension select endpoint paths over that underlay; they do not replace its global prefix reachability infrastructure. Edge defaults and multiple QUIC paths do not remove those upstream tables. This is a whole-stack profile verdict, not a claim that every possible IP topology requires a full table or that QUIC itself maintains BGP routes.", "method": "Documentary/code analysis; no protocol execution", "source_label": "Primary specification / pinned source and explicit deployment profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc4271.html", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-SC", "feature": "G01", "stack": "SC", "status": "N", "reason": "The documented SCION core control plane receives beacons from every other core AS and selects paths per origin core AS. It therefore retains global core-AS reachability, although non-core down-segments are distributed among the relevant cores. G01 includes complete global transit/control catalogs, as in the Tor decision; it does not require a table of every endpoint. Packet-carried forwarding does not eliminate this core inventory. This is not a claim that every AS holds all non-core routes, nor that SCION needs global BGP for neighbor-only underlay links.", "method": "Documentary/code analysis; no protocol execution", "source_label": "Primary specification / pinned source and explicit deployment profile", "sources": [ "https://docs.scion.org/en/latest/control-plane.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-RT", "feature": "G01", "stack": "RT", "status": "Y", "reason": "In Reticulum 1.5.5, serial transport interfaces can enable recursive_prs. Transport.path_request forwards an unknown-destination query to other eligible interfaces and a local destination answers with an announce; it does not require any node to possess a complete destination inventory before lookup. Select this recursive-discovery profile on the connected serial mesh. Destination caches, discovery traffic, timeouts and hop limits remain. This is an architectural capability, not a bound on worst-case table growth or proof of global-scale performance.", "method": "Documentary/code analysis; no protocol execution", "source_label": "Primary specification / pinned source and explicit deployment profile", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Reticulum.py" ], "editorial_references": [], "qualification": "Run recursive discovery across a serial mesh with deliberately incomplete destination tables; inventory query/announce state at every role, enforce timeout/hop limits and demonstrate reachable-target completion. No such execution or billion-device model was performed." }, { "id": "G01-NS", "feature": "G01", "stack": "NS", "status": "N", "reason": "For globally reachable WSS relays, explicitly select conventional BGP-routed IPv4 Internet service. NIP-01 connects clients to relays through WebSocket; it supplies no replacement for the underlay's global prefix reachability infrastructure. Separate author identities, multiple relays and distributed DNS do not remove that dependency. This verdict is for the declared Internet-backed stack, not a claim that the Nostr protocol intrinsically requires a centralized catalog of all authors or relays.", "method": "Documentary/code analysis; no protocol execution", "source_label": "Primary specification / pinned source and explicit deployment profile", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-MT", "feature": "G01", "stack": "MT", "status": "?", "reason": "The ordinary CLIENT profile has a bounded packet reachability envelope, not a demonstrated requirement for a global destination catalog. HOP_MAX is seven; the source transmission does not consume a relay decrement, and each subsequent ordinary relay sends with one less remaining hop. A destination can receive the zero-budget transmission, so the bound is eight radio edges, not an assertion of seven physical links. Radio serialization clamps an oversized hop value. Zero-cost favorite-router forwarding requires other roles and cannot be imported into this profile. The zero-budget exhaustHops branch appears to be an exception, but its controlling TrafficManagementModule flag is initialized/reset false and never enabled in this pinned implementation. Opaque forwarding also decrements. A graph whose diameter exceeds eight necessarily contains pairs unreachable by this forwarding mechanism; a star has diameter two and is not ruled out by the hop counter alone. Neither fact supplies a worldwide radio topology. Published range records are observations, not universal physical range ceilings; multiplying one by eight cannot prove global operation impossible. G01 stays Pending until a complete geographic link/state construction is established, or a profile-wide impossibility proof is available. The independent 32-bit G05 namespace contradiction remains unchanged.", "method": "Pinned forwarding/radio/traffic-management source trace and reachability-bound analysis; no firmware or RF execution", "source_label": "Meshtastic 8e6a88d: MeshTypes, Router, NextHopRouter, RadioInterface and TrafficManagementModule", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/RadioInterface.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/TrafficManagementModule.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/TrafficManagementModule.h", "https://meshtastic.org/docs/overview/range-tests/" ], "editorial_references": [ "round142-sources.json", "round142.html" ], "qualification": "For ordinary CLIENT forwarding, HOP_MAX=7 permits at most seven relays after the originating radio transmission: at most eight radio edges for one packet, absent an added gateway/reoriginator. Router preservation is unavailable to this role; opaque forwarding decrements too. The apparent exhaustHops zero-budget relay exception is inactive in the pinned TrafficManagementModule, whose flag is initialized/reset false and never enabled. Supply a connected geographic radio construction within this diameter, unique destination identities, compatible radio settings and all-role state inventory. A short-diameter abstract graph is not a global RF deployment; an observed range record is not a physical upper bound. See round142.html." }, { "id": "G01-GN", "feature": "G01", "stack": "GN", "status": "N", "reason": "Explicit deployment refinement: use conventional globally routed IPv4/BGP, as already selected for IP and MQ. Edge defaults relocate global prefix reachability upstream rather than eliminate it. R5N discovery and CADET routing do not replace the selected UDP transport underlay. Partitioned peer discovery is compatible with this No: the global prefix tables reside in the declared IP infrastructure, not necessarily in each GNUnet peer. This is a whole-stack verdict for that deployment, not a theorem about every possible IP topology.", "method": "Documentary composition analysis; no execution", "source_label": "Primary transport/discovery documentation and RFC 4271; declared deployment inference", "sources": [ "https://docs.gnunet.org/handbook/gnunet.html", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "" }, { "id": "G01-ND", "feature": "G01", "stack": "ND", "status": "Y", "reason": "Select a connected tree of direct Ethernet adjacencies. Every transit node has a root-prefix FIB entry listing its neighbors and the native multicast v5 strategy at /. Producers register their own names locally. For known globally scoped names without forwarding hints, longest-prefix lookup uses the local producer registration where present and otherwise /. The multicast implementation sends to eligible next hops, excluding the incoming non-ad-hoc face. Induction along the unique tree path therefore reaches each producer; signed Data returns through pending Interest records. No transit node, root node or control service needs a catalog of remote producers, names or prefixes. Set hop budget and Interest lifetime to cover the finite diameter and provision the offered load. Root-prefix neighbor lists are adjacency state, not a global reachability catalog. This is a concrete native construction permitted by the existing local-FIB profile, not NLSR or an added overlay. Flooding can consume network-wide bandwidth and PIT memory per request; G05 remains Pending and no efficient billion-device operation is asserted.", "method": "Constructive architecture inference from NFD 24.07 source; no NFD or scale execution", "source_label": "NFD multicast v5, next-hop eligibility, longest-prefix lookup and PIT Data return", "sources": [ "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/fw/multicast-strategy.cpp", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/fw/algorithm.cpp", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/fw/strategy.cpp", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [ "round135-sources.json", "round135.html" ], "qualification": "Validate a branched direct-Ethernet topology with producers in different branches, empty caches and known non-local names. Inspect FIB/RIB, PIT and producer registration at every role; exercise withdrawal and re-registration locally. No capacity claim follows." }, { "id": "G01-AX", "feature": "G01", "stack": "AX", "status": "N", "reason": "Classic NET/ROM forwards using explicit destination-node entries and discards unknown destinations. Reaching arbitrary nodes requires those destination routes, not a partitioned lookup mechanism. Table-size limits restrict reachability rather than remove that requirement.", "method": "Primary-document analysis and selected-profile inference; no execution", "source_label": "The NET/ROM Protocol: network/transport format and routing; historical primary document", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "" }, { "id": "G01-BA", "feature": "G01", "stack": "BA", "status": "N", "reason": "Both BATMAN_IV and BATMAN_V create per-originator entries in orig_hash from originator announcements. The common unicast forwarding path looks up the destination originator and its next-hop route; missing state causes a drop rather than a recursive global lookup. Thus reachability to arbitrary originators in the connected native mesh depends on mesh-wide originator reachability state, although nodes need not store a complete link-topology map. Keeping only next hops per destination is not eliminating the destination table. Attached-client translation adds another mapping layer and does not remove this requirement. The declared native Ethernet stack adds no hierarchical inter-mesh routing system that partitions this global namespace. This supports No for G01 under either algorithm; it is not a measured capacity ceiling, nor a claim that every endpoint application stores the mesh table. Loss, expiry or scoped announcements can make tables incomplete, but that does not establish arbitrary global reachability without them.", "method": "Linux v6.12 source inspection across BATMAN_IV and BATMAN_V; no scale test", "source_label": "bat_iv_ogm.c and bat_v_ogm.c originator creation; routing.c unicast destination lookup", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_v_ogm.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_iv_ogm.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c" ], "editorial_references": [], "qualification": "" }, { "id": "G01-BL", "feature": "G01", "stack": "BL", "status": "Y", "reason": "An explicit provisioned hierarchy resolves the previously missing all-role inventory. Partition one locally assigned ULA /48 recursively into binary subdomains. Each router maintains a local discard route for its own aggregate and redistributes only that aggregate upward; it learns only its immediate child aggregates and the root /48 from its parent. It advertises only the root /48 downward. Exact-prefix/interface filters prevent leaf specifics from propagating globally. Leaf connected LAN routes override the local discard aggregate. For a reachable destination outside the local subtree, the root /48 takes traffic upward; at the lowest containing ancestor, more-specific child routes take it downward to the leaf. Every transit role, including the root, stores only local partitions, not the complete catalog of independently originated remote subdomains or leaf LANs. Babel source/feasibility records likewise cover only accepted parent/child origins under these filters; neighbor, local redistribution and temporary withdrawal state remain bounded by local degree for the fixed topology. A withdrawn child route first has unreachable hold state, then falls into the local discard aggregate rather than back toward the parent. Native prefix/interface filters and static-route redistribution support this construction without a new overlay or control service. It requires coordinated hierarchical addressing and topology; it does not establish ordinary Internet/BGP replacement, efficient operation at ten billion devices, multihoming or uninterrupted reachability during partition.", "method": "Constructive routing/state proof with native Babel filtering and redistribution; symbolic LPM checks, no Babel daemon execution", "source_label": "RFC 8966 filtering/hold behavior and babeld 1.13 native prefix/interface filters and route redistribution", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-C", "https://github.com/jech/babeld/blob/babeld-1.13/babeld.man", "https://github.com/jech/babeld/blob/babeld-1.13/kernel_netlink.c", "https://github.com/jech/babeld/blob/babeld-1.13/xroute.c" ], "editorial_references": [ "round139-model-result.json", "round139-configs.json", "round139.html" ], "qualification": "Run the generated per-role configurations with a pinned Babel daemon and real kernel routing in an isolated topology. Confirm import/advertisement of non-default static discard aggregates, exact filters, selected/fallback/source tables, unreachable hold and recovery. The executed model tests only converged LPM states; it does not emulate Babel sequence numbers, timers, reconvergence or kernel installation. No daemon, network or capacity experiment ran." }, { "id": "G01-RI", "feature": "G01", "stack": "RI", "status": "Y", "reason": "Constructive deployment inference: RFC 6550 permits independent DODAG roots and external IPv6 connectivity. Partition the selected non-storing deployment into multiple local DODAGs; each root retains its own downward topology, not all remote endpoints. Interconnect their provisioned ULA subnets through a static binary prefix hierarchy: each transit router needs only child aggregates, an upward covering route and its own discard aggregate. Destination-specific routes stay in the destination DODAG. No directory or BGP service is required by this particular configuration. Numeric endpoint addresses and local pairwise DTLS keys avoid a compulsory global lookup or trust catalog.", "method": "Constructive architectural inference from primary specifications; no runtime or capacity experiment", "source_label": "RFC 6550 independent roots and border forwarding; RFC 4193 subnet structure; RFC 7608 prefix forwarding", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-3.1.3", "https://www.rfc-editor.org/rfc/rfc6550.html#section-11.2.2.1", "https://www.rfc-editor.org/rfc/rfc4193.html#section-3.1", "https://datatracker.ietf.org/doc/html/rfc7608#section-2" ], "editorial_references": [ "round310-sources.json" ], "qualification": "Explicit private interconnection witness, not conventional public-Internet routing or arbitrary autonomous topology. Subdivide the Subnet ID space inside one legitimately generated ULA /48; do not assign sequential Global IDs contrary to RFC 4193. Recursive allocation needs only immediate child assignments. Each RPL root must have a configured mapping to its local instance and working non-storing source-route handling; RPL packet information is removed on exit and inserted on entry. Configure external reachability at each root. A connected provisioned topology, adequate hop limits and usable local radio paths are assumed. Local /64 and neighbor state, per-DODAG topology, DTLS peer keys and link hardware remain required. No new overlay, global route service or automatic prefix aggregation is credited. G05 quantitative capacity, root memory, control traffic and discovery remain Pending; no daemon, radio or interoperability experiment ran." }, { "id": "G01-HP", "feature": "G01", "stack": "HP", "status": "N", "reason": "The global witness selects IPv6 with BGP/MP-BGP prefix routing. For the global case, explicitly select conventional BGP-routed IPv4/IPv6, using the same convention as IP, PRP-over-IP and Multipath QUIC. HIP decouples host identity from locators but still sends to IP locators. Its identity and mobility mechanisms do not replace the global prefix reachability infrastructure of this selected underlay. Endpoint default routes relocate that responsibility upstream.", "method": "Documentary composition and evidence reconciliation; no new runtime execution", "source_label": "Primary RFCs, explicit deployment convention and retained local experiment receipts", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-1", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [ "round134.html", "round279-sources.json" ], "qualification": "This is a whole-stack verdict for the declared global Internet deployment, not a claim that HIP requires a global identity directory, that all routers hold full tables or that every possible IP topology needs BGP. Private operation and S03/S04 remain unchanged. No G05 capacity or runtime conclusion follows." }, { "id": "G01-CX", "feature": "G01", "stack": "CX", "status": "N", "reason": "For the global case, explicitly select the same conventional BGP-routed IPv4 underlay used for IP, PRP-over-IP and Multipath QUIC. CCNx names, FIB aggregation and pending-Interest state do not remove IP reachability between UDP forwarders in that composition. The whole-stack criterion includes the upstream global prefix tables even when an individual CCNx forwarder only knows its next hop.", "method": "Documentary composition and evidence reconciliation; no new runtime execution", "source_label": "Primary RFCs, explicit deployment convention and retained local experiment receipts", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2" ], "editorial_references": [ "round119.html", "round279-sources.json" ], "qualification": "This does not assert that native CCNx or an adjacent-only private IP mesh intrinsically requires global name or prefix tables. Those are different global constructions and have not been selected here. The independent private configuration remains available for S03/S04. No claim is made about a complete catalog of names, global scalability or packet measurements." }, { "id": "G01-LI", "feature": "G01", "stack": "LI", "status": "N", "reason": "The conventional Internet deployment still routes outer RLOCs through IP prefix-routing infrastructure. A partial EID Map-Cache does not remove the global-prefix responsibility of that underlay. This applies the same complete-stack boundary as G01-IP.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-4", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3" ], "editorial_references": [], "qualification": "Bounded to conventional global Internet interconnection, not a theorem about every possible IP routing design. LISP can distribute EID mappings and reduce their exposure to transit; that is not elimination of underlay global reachability state. Private-domain operation is a separate result." }, { "id": "G01-IL", "feature": "G01", "stack": "IL", "status": "N", "reason": "ILNP routes on Locator prefixes using existing IPv6 routing. In conventional global Internet deployment, prefix reachability remains in the interdomain routing infrastructure even though Node Identifiers are not globally routed. DNS partitioning does not remove that routing responsibility.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [], "qualification": "Same conventional-Internet boundary as G01-IP; no claim that all conceivable IPv6 routing designs require one complete table. Aggregation can reduce entries; this is not a quantitative failure of G05 or a requirement to store every endpoint." }, { "id": "G01-TS", "feature": "G01", "stack": "TS", "status": "N", "reason": "The selected routed Internet underlay retains conventional BGP global prefix reachability. A small endpoint routing table or partitioned tailnet discovery moves that dependency upstream rather than removing it.", "method": "Primary documentation, pinned source and explicit whole-stack inference", "source_label": "Tailscale bootstrap DNS, infrastructure requirements and RFC 4271", "sources": [ "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/net/dnsfallback/dnsfallback.go", "https://tailscale.com/docs/reference/faq/firewall-ports", "https://www.rfc-editor.org/rfc/rfc4271.html#section-3.2" ], "editorial_references": [ "round590.html", "round590-sources.json" ], "qualification": "Applies the same whole-stack Internet-underlay convention as IP and PRP-over-IP. It does not assert that every router holds a full table or that every possible private IP topology needs BGP. This does not decide G05 scalability." }, { "id": "G01-RA", "feature": "G01", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Inventory every transit and control role, including discovery, upper aggregators and the underlay. Establish how arbitrary reachable destinations are located without a mandatory complete global table. A local default route, local labels or a small private deployment alone are insufficient. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "G02-PN", "feature": "G02", "stack": "PN", "status": "Y", "reason": "Consider a destination D with two already authenticated and validated paths through attachments A and B, bound to its existing relationships. Outside the access region, each relevant communicating peer changes its selected destination trajectory from the A path to the B path; D migrates eligible work and drains A. Lifecycle sections 3.4, 4 and 7 permit simultaneous eligible trajectories and replacement without replacing participant identity or the session generation. The affected state belongs to D, the prepared paths and peers maintaining those relationships. No individual identity/location update to unrelated network participants is needed in this provisioned witness. This changes actual forwarding toward the destination, rather than merely reconnecting an initiating client.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned PRP lifecycle sections 3.4, 4 and 7; current wire retirement scope", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-relationship-lifecycle-v1.md" ], "editorial_references": [ "round571.html", "round571.html", "round571-sources.json" ], "qualification": "Architectural witness over already valid, preinstalled paths and scoped forwarding state, not a new-session or Member Route Intent activation procedure. Retain a usable authorized reverse path where bilateral service requires one. Reachability from outside is demonstrated for provisioned remote relationships with an eligible B trajectory; this is not universal cold discovery, arbitrary simultaneous movement, or a globally bounded convergence claim. Publication/discovery coverage is held fixed and no new network-wide destination announcement is assumed. Missing alternate state, invalid sessions or movement beyond the prepared scope requires separate recovery evidence. Wire-v4 section 1.1 retires the historical HS2 path; it preserves independently valid session state and does not qualify successor establishment. The native witness uses already authorized native-carrier paths; no IP routing service is introduced." }, { "id": "G02-PI", "feature": "G02", "stack": "PI", "status": "Y", "reason": "Consider a destination D with two already authenticated and validated paths through attachments A and B, bound to its existing relationships. Outside the access region, each relevant communicating peer changes its selected destination trajectory from the A path to the B path; D migrates eligible work and drains A. Lifecycle sections 3.4, 4 and 7 permit simultaneous eligible trajectories and replacement without replacing participant identity or the session generation. The affected state belongs to D, the prepared paths and peers maintaining those relationships. No individual identity/location update to unrelated network participants is needed in this provisioned witness. This changes actual forwarding toward the destination, rather than merely reconnecting an initiating client.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Pinned PRP lifecycle sections 3.4, 4 and 7; current wire retirement scope", "sources": [ "https://github.com/prp-protocol/specifications/blob/9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b/specifications/prp-relationship-lifecycle-v1.md" ], "editorial_references": [ "round571.html", "round571.html", "round571-sources.json" ], "qualification": "Architectural witness over already valid, preinstalled paths and scoped forwarding state, not a new-session or Member Route Intent activation procedure. Retain a usable authorized reverse path where bilateral service requires one. Reachability from outside is demonstrated for provisioned remote relationships with an eligible B trajectory; this is not universal cold discovery, arbitrary simultaneous movement, or a globally bounded convergence claim. Publication/discovery coverage is held fixed and no new network-wide destination announcement is assumed. Missing alternate state, invalid sessions or movement beyond the prepared scope requires separate recovery evidence. Wire-v4 section 1.1 retires the historical HS2 path; it preserves independently valid session state and does not qualify successor establishment. For the IP carrier, provision both attachment locators and ordinary underlay reachability beforehand. Selecting B changes PRP trajectory/UDP-IP destination use, not global BGP host-route advertisements; NAT traversal and new underlay reachability are outside this witness." }, { "id": "G02-IP", "feature": "G02", "stack": "IP", "status": "Y", "reason": "In the C01 private-IPv4 witness, a host retains a /32 while replacing its final access through router A with access through B. An ingress router outside those access links changes its host route from A to B; the administrator confines that route and its updates to the affected routing region. Other regions retain a covering route toward the ingress. Thus delivery state used for external traffic changes without distributing the individual host's new attachment throughout the network. RFC 1812 supports static routes and control over their propagation.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 1812 static-route export control and RFC 1122 weak-host attachment witness", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html#section-7.4", "https://www.rfc-editor.org/rfc/rfc1812.html#section-2.2.5.2", "https://www.rfc-editor.org/rfc/rfc1122.html#section-3.3.4.2", "https://docs.kernel.org/6.12/networking/ip-sysctl.html" ], "editorial_references": [ "round561.html", "round561-sources.json" ], "qualification": "Preprovision both paths, retain the address on a logical host interface, permit weak-host reception and provide a return route. Authorized administrators must update the affected routes and prevent export of the /32 beyond the region. The covering route must remain valid. This is configured native routing, not ordinary address portability between unrelated providers or endpoint-controlled mobility. Cross-region movement may require wider changes. No Mobile IP, tunnel, DNS, globally advertised /32, automatic convergence or runtime result is credited." }, { "id": "G02-BP", "feature": "G02", "stack": "BP", "status": "Y", "reason": "A destination keeps its singleton EID and initiates a fresh authenticated TCPCL session to a known relay after changing IP attachment. With the existing C01 forwarding policy, the relay associates that EID/node with the new live session and delivers queued bundles through it. Session and delivery state change at the relay outside the access region; upstream EID routes remain directed there. This does not require distributing the destination's new IP address throughout the bundle network.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "BPv7 forwarding and TCPCLv4 active-only sessions with authenticated node identity", "sources": [ "https://www.rfc-editor.org/rfc/rfc9174.html#section-3.5", "https://www.rfc-editor.org/rfc/rfc9174.html#section-4.6", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round560.html", "round560-sources.json" ], "qualification": "Provision the relay, EID/node association, NODE-ID validation, endpoint registration and session-selection policy. Both access prefixes must already be routed and allow the new connection. Active-only polling is an RFC 9174 policy; BP does not automatically supply location discovery or this routing configuration. Relay failure, expired bundles, storage limits and unavailable connectivity can prevent delivery. Other topologies may require wider updates. No old TCP-session continuity, unrestricted relay relocation, global-capacity or integrated runtime qualification is credited." }, { "id": "G02-CG", "feature": "G02", "stack": "CG", "status": "Y", "reason": "A destination keeps its EID/node mapping while its final contact changes from A-to-D to B-to-D within a prepared region. Using the documented ION exit hierarchy, outside nodes retain an aggregate exit toward the regional gateway. Operators update contact information at the gateway and affected regional nodes, which recompute delivery toward B. The final route changes without distributing D's individual contact change throughout the network.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "SABR contact-plan handling and pinned ION regional exit routing", "sources": [ "https://public.ccsds.org/Pubs/734x3b1.pdf", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/ipnrc.pod" ], "editorial_references": [ "round570.html", "round570-sources.json" ], "qualification": "The gateway must remain reachable, the regional plan must include usable contacts within bundle lifetime, and EID/node mapping must remain correct. SABR leaves plan distribution unspecified; this is an explicit local-administration witness, not automatic regional dissemination. Recompute invalidated routes after plan changes. Movement outside the prepared region or failure of its gateway may require broader updates. Retain provisioned numeric TCPCL peers and NODE-ID/BPSec trust. No complete executable integration or runtime result." }, { "id": "G02-LT", "feature": "G02", "stack": "LT", "status": "Y", "reason": "A destination keeps its EID/node mapping while its final contact changes from A-to-D to B-to-D within a prepared region. Using the documented ION exit hierarchy, outside nodes retain an aggregate exit toward the regional gateway. Operators update contact information at the gateway and affected regional nodes, which recompute delivery toward B. The final route changes without distributing D's individual contact change throughout the network.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "SABR contact-plan handling and pinned ION regional exit routing", "sources": [ "https://public.ccsds.org/Pubs/734x3b1.pdf", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/ipnrc.pod" ], "editorial_references": [ "round570.html", "round570-sources.json" ], "qualification": "The gateway must remain reachable, the regional plan must include usable contacts within bundle lifetime, and EID/node mapping must remain correct. SABR leaves plan distribution unspecified; this is an explicit local-administration witness, not automatic regional dissemination. Recompute invalidated routes after plan changes. Movement outside the prepared region or failure of its gateway may require broader updates. Retain provisioned LTP engine and Encapsulation/AOS channel mappings; LTP does not itself locate endpoints. No IP layer, complete executable integration or runtime result." }, { "id": "G02-LP", "feature": "G02", "stack": "LP", "status": "Y", "reason": "With overlapping reachable attachments, a destination peer advertises its new numeric QUIC listen address through Identify Push to connected peers. They update their peerstores under the unchanged Peer ID and can subsequently dial the new attachment. Pinned go-libp2p sends pushes over its existing connection set, rather than flooding a global membership directory. Remote communication state therefore changes while unrelated participants receive no per-peer location update.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "libp2p Identify Push and Tor onion descriptor distribution", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/identify/README.md", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/protocol/identify/id.go", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/net/swarm/swarm_dial.go" ], "editorial_references": [ "round554.html", "round554-sources.json" ], "qualification": "Use the existing C01 witness: learn the new address before the only old path fails, retain it until redial, and satisfy ConnectionGater and address filters. Both underlay prefixes are already routed; local attachment and interested peerstore state change. Cold discovery by arbitrary disconnected peers is not provided by this composition. Abrupt movement with no reachable known address can fail. No DHT, DNS, relay discovery, uninterrupted stream or global convergence guarantee is added." }, { "id": "G02-TO", "feature": "G02", "stack": "TO", "status": "Y", "reason": "A destination onion service retains its identity across an access change, rebuilds introduction circuits and uploads current descriptors to the responsible HSDirs. Clients obtain those descriptors and build new introduction/rendezvous circuits. Updates concern those directories, participating circuit relays and interested clients; they are not a per-service announcement to every Tor relay or Internet router. The introduction information used outside the affected access region actually changes.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "libp2p Identify Push and Tor onion descriptor distribution", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [ "round554.html", "round554-sources.json" ], "qualification": "Retain service identity and client-authorization material, reachable Tor access and usable directory information. The new access prefix is already routed; the ordinary global relay consensus remains a dependency but is not updated with each onion service's attachment. Descriptor replicas, rotation and caches remain relevant control state. Stale descriptors and unavailable guards/directories can delay recovery. No preservation of existing streams, OnionBalance, Conflux execution or bounded recovery time is credited. This is an architectural witness, not a mobility experiment." }, { "id": "G02-I2", "feature": "G02", "stack": "I2", "status": "Y", "reason": "A destination retains its identity while its router changes NTCP2 attachment, rebuilds inbound tunnels and publishes their gateways and tunnel IDs in a new LeaseSet. RouterInfo carries changed transport contacts. Publication targets selected floodfills and the responsible routing-key neighborhood; forwarded replicas with a zero reply token do not reflood. Interested peers retrieve updated records. Reachability information changes outside the access region without requiring every participant to receive each destination's attachment update.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "I2P netDb distribution and pinned Java tunnel/transport sources", "sources": [ "https://www.i2p.net/en/docs/overview/network-database/", "https://github.com/i2p/i2p.i2p/blob/37039e6594f1372368f0c1cf8258cdaf805a7fb4/router/java/src/net/i2p/router/tunnel/pool/TunnelPool.java" ], "editorial_references": [ "round555.html", "round555-sources.json" ], "qualification": "Use the existing C01 witness with preserved destination keys, reachable peers and successful replacement tunnels on already-routed access prefixes. Responsible directory participants need not be geographically local. Replica rotation, verification, retries and peer lookups add recipients and traffic; this is not a fixed total-cost bound. Stale records and isolation can delay recovery. Existing streams need not survive. No global-scale benchmark, instant convergence, MetaLeaseSet or i2pd post-quantum implementation qualification is inferred." }, { "id": "G02-YG", "feature": "G02", "stack": "YG", "status": "Y", "reason": "The selected Ironwood supports a scoped destination-reattachment witness: retain a leaf destination key, establish its new adjacent peering before withdrawing the old one, and preserve the root and unrelated parent choices. router._sendAnnounces sends ancestry information relevant to each adjacent peer, not a complete participant inventory. bloomfilter._getBloomFor unions the local key with filters from other tree branches. For unchanged tree cuts outside the old-to-new attachment corridor, the reachable key set remains the same; equal filters suppress change-triggered transmission. External senders can still discover the destination through Bloom-guided lookup and receive its new signed path via pathfinder, updating relevant path caches rather than broadcasting that location to every participant. This is a source-derived constructive witness, not a measured convergence result.", "method": "Constructive stable-root leaf reattachment analysis; no runtime test", "source_label": "Pinned Ironwood ancestry, aggregate-filter and path-discovery source", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/bloomfilter.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go" ], "editorial_references": [ "round631.html", "round631-sources.json" ], "qualification": "Credit is conditional on stable-root leaf reattachment with overlapping connectivity, not arbitrary root replacement, partition/merge or movement of a large subtree. Those events can affect wider areas. A complete offline interval may cause broader membership withdrawal/reinsertion. Periodic filter refresh remains, and transient stale filters, false positives, path retries or packet loss are not excluded. No bounded convergence time, uninterrupted session or global capacity is inferred. Selected private adjacent IP links must be provisioned at the new attachment; the witness does not advertise a mobile individual IP route globally. Changes elsewhere in the underlay or tree are outside this bounded witness." }, { "id": "G02-CJ", "feature": "G02", "stack": "CJ", "status": "N", "reason": "In the selected replicated route-server composition, destination attachment changes alter peer/link announcements. server.rs applies those announcements to the destination node and inward-link graph and passes accepted announcements to Peers.add_ann. peer.rs advertises new inventory hashes to incoming replication peers; newly connected peers receive the known inventory, and outgoing peers request every unknown advertised announcement. There is no regional or communicating-peer subscription filter in this exchange. Globally capable route-server replicas therefore disseminate individual attachment state beyond the affected region and active communicating parties. This fails G02 even though ordinary transit switches and endpoints do not all receive that state.", "method": "Whole selected composition source analysis; no runtime experiment", "source_label": "Pinned cjdns route-server announcement, replication and route-query source", "sources": [ "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/peer.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server/service.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/src/server/route.rs" ], "editorial_references": [ "round630.html", "round630-sources.json" ], "qualification": "This is a source-derived architectural verdict for the explicitly selected replicated route-server design, not the older DHT-only cjdns design or every possible deployment. Replication follows configured directed peer relationships; it is not an all-client broadcast. Disconnected replicas need not receive an update, but their absence does not establish preserved arbitrary remote reachability: route queries use the local graph and require the destination locally. No timing, convergence, capacity, security or runtime failure is inferred. Independent private-IP underlay operation does not remove this overlay update requirement. Existing implementation/interoperability qualifications remain." }, { "id": "G02-MQ", "feature": "G02", "stack": "MQ", "status": "Y", "reason": "A server can advertise a preferred address for its replacement access during the handshake. After confirmation, the client validates that address and transfers the connection's traffic to it; the server validates the return path before completing the switch. Peer-address and connection state change at the communicating endpoints, without a network-wide host-location announcement. Multipath-21 section 2.2 explicitly retains this preferred-address migration, with path ID 0 when the client's local address is unchanged.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 9000 preferred server address and multipath-21 section 2.2", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-9.6", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html#section-2.2" ], "editorial_references": [ "round569.html", "round569-sources.json" ], "qualification": "Bounded planned destination handover: provision both server attachments on already-routed prefixes, retain connection state and keep the initial path usable until validation succeeds. This is not an arbitrary mid-connection server-address update; discovery beyond the advertised address remains outside multipath-21. The address is valid only for that connection, and simultaneous use of both server addresses must not be assumed. C01 remains No because the numeric destination changes; F23's client-migration result is separate. No runtime experiment or latest-draft claim." }, { "id": "G02-SC", "feature": "G02", "stack": "SC", "status": "Y", "reason": "Within the C01 same-AS witness, a destination retains its ISD-AS and local IPv4 address while replacing its final access. The AS ingress or its underlay delivery routers change the host route toward that address. SCION's pinned final-delivery code derives the underlay destination from the packet's host address, so incoming traffic uses the repaired internal route. The individual attachment update stays inside the destination AS; other ASes need no new host-location announcement.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "SCION AS/local-address separation, pinned final-delivery code and configured IPv4 routing", "sources": [ "https://docs.scion.org/en/latest/overview.html", "https://raw.githubusercontent.com/scionproto/scion/v0.12.0/router/dataplane.go", "https://www.rfc-editor.org/rfc/rfc1812.html#section-7.4", "https://www.rfc-editor.org/rfc/rfc1122.html#section-3.3.4.2" ], "editorial_references": [ "round563.html", "round563-sources.json" ], "qualification": "Credit the selected composition, including configured IPv4, not SCION alone. Provision both accesses, preserve the host address and UDP endpoint, permit weak-host reception, and update affected routes without exporting host specifics. This is a real final-delivery route change, not merely choosing another unchanged ingress path. SCION explicitly leaves intra-AS routing to the underlying network. Inter-AS relocation, topology failures and changes to AS-level paths may require broader updates. No autonomous endpoint mobility, guaranteed convergence or runtime qualification is inferred." }, { "id": "G02-RT", "feature": "G02", "stack": "RT", "status": "Y", "reason": "A configured regional transport node can learn a destination's changed serial attachment while suppressing unsolicited announcements toward an external access_point interface. A requester on that interface can obtain the updated path: Transport answers from its learned announcement, binds the response to the requesting interface and marks it PATH_RESPONSE to suppress ordinary rebroadcast. The node's destination/interface state and the interested requester's path can therefore change without disseminating the move to every participant.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Reticulum 1.5.5 interface modes and path-response handling", "sources": [ "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Transport.py", "https://reticulum.network/manual/interfaces.html#interface-modes", "https://raw.githubusercontent.com/markqvist/Reticulum/1.5.5/RNS/Destination.py" ], "editorial_references": [ "round559.html", "round559-sources.json" ], "qualification": "Bounded witness: retain destination identity/name and IFAC credentials; move between admitted serial attachments behind the same transport node; accept a fresh announcement there before the external requester retries discovery. Configure the requester-facing interface as access_point, keep it reachable and permit path responses. A fresh Link is allowed. This is native mode configuration, not a claim for default full-mode meshes or arbitrary inter-region moves. Stale caches, rate limits and recursive discovery can delay or broaden other cases. No global-capacity or uninterrupted-session result is inferred." }, { "id": "G02-NS", "feature": "G02", "stack": "NS", "status": "N", "reason": "NIP-01 lets a publisher reconnect to known relays and submit the same signed event from a new access. Readers still request the event from those relays; no route or location mapping to the publisher is updated for external delivery. Event availability and the publisher's WebSocket connection change, but this is the initiating-client reconnection case explicitly excluded by G02. Basic Nostr does not supply a destination-attachment update mechanism at this service boundary.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "NIP-01 client/relay boundary and G02 destination-update requirement", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round487.html#G02", "round537.html", "round565.html", "round565-sources.json" ], "qualification": "C01 remains Yes for retrieval of the unchanged event ID after republication. That content-level recovery does not establish scoped location updates, and absence of a global announcement alone is insufficient. This No does not claim that Nostr floods location changes or lacks useful mobility for its users. The selected composition has known relays and NIP-01; no relay-discovery/migration extension or separate IP host-mobility arrangement is credited. Relay acceptance, retention and connectivity still govern content availability. No runtime experiment." }, { "id": "G02-MT", "feature": "G02", "stack": "MT", "status": "N", "reason": "After a destination moves and a learned next hop fails, the selected recovery mechanism clears the next-hop preference and retries through managed flooding. That packet exposes the destination NodeID to eligible relays across its remaining hop horizon, including branches unrelated to the affected attachment or prior communication path. Replies can then establish new next-hop state. The mechanism does not confine discovery/update traffic to the changed region and relevant communication participants.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Meshtastic managed-flooding recovery and next-hop learning", "sources": [ "https://meshtastic.org/docs/overview/mesh-algo/", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [ "round564.html", "round564-sources.json" ], "qualification": "No concerns the scope of attachment recovery, not the existence of mobility or C01 same-NodeID reachability, which remains Yes. This is not a claim that every node receives every packet or keeps a complete location directory. Hop limits, duplicate suppression and radio topology limit each flood, but do not select recipients by the changed region. A small neighborhood may recover locally by circumstance. No MQTT, regional directory or additional scoped-routing mechanism is selected; no airtime or scale experiment ran." }, { "id": "G02-GN", "feature": "G02", "stack": "GN", "status": "Y", "reason": "After a destination changes its UDP attachment while retaining its peer identity, supplied usable contacts reattach it to the mesh. CADET publishes its current HELLO under the peer-derived DHT key with route recording; interested peers search that key and use returned GET/PUT paths as connection candidates. R5N forwards operations through selected neighbors and replicas rather than requiring an updated location entry at every peer. Remote discovery and path state change without a network-wide per-destination update requirement.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "GNUnet 0.20.0 CADET DHT publication and R5N path discovery", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/dht/dht.html", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html", "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round558.html", "round558-sources.json" ], "qualification": "Use the existing C01 witness with admitted contacts, connected neighbors and already-routed private-IP access. DEMULTIPLEX_EVERYWHERE permits caching along traversed paths; it does not mean a broadcast to every peer. Repeated publications, searches and changing replica placement can reach additional participants. Discovery is probabilistic and may fail or be delayed; stale paths must be replaced. No fixed recipient count, global-capacity bound, automatic arbitrary-address discovery or seamless channel migration is inferred. The selected 0.20.x composition remains documentary, not an integrated runtime result." }, { "id": "G02-ND", "feature": "G02", "stack": "ND", "status": "Y", "reason": "The selected NFD stack supports operator-configured name-prefix routes over its Ethernet faces. When a producer changes attachment within a prepared region, the ingress and affected regional forwarders can replace the prefix's next-hop face while outside forwarders retain a covering route toward that region. Consumers keep the same content name and validation key. The producer route used for incoming Interests changes without distributing that individual attachment update to all forwarders.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "NFD 24.07 native RIB route management and bounded regional forwarding", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-route.html", "https://raw.githubusercontent.com/named-data/NFD/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/docs/manpages/nfdc-route.rst" ], "editorial_references": [ "round568.html", "round568-sources.json" ], "qualification": "Provision both Ethernet attachments and authorize route management and producer registration. Remove obsolete next hops, control inherited covering routes with the appropriate capture/inheritance flags, wait for RIB-to-FIB completion, and allow stale PIT state to expire before retrying uncached content. This uses native local FIB configuration; it does not infer scoped recovery from the separate G01 root-prefix flooding witness. No NLSR, global directory, IP underlay, automatic producer discovery or arbitrary inter-region mobility is added. No runtime experiment." }, { "id": "G02-AX", "feature": "G02", "stack": "AX", "status": "N", "reason": "The selected NET/ROM recovery witness learns changed next hops for the same destination callsign through NODES advertisements and route aging. netromd's transmitting path includes eligible individual destinations from the routing table; receiving neighbors can learn and subsequently advertise those routes themselves. Dissemination is not restricted to the changed attachment region or peers with an active communication relationship. The selected composition supplies no regional locator directory or aggregate destination route that replaces this individual-route propagation.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Linux NET/ROM and ax25-tools NODES route dissemination", "sources": [ "https://manpages.debian.org/testing/ax25-tools/netromd.8.en.html", "https://deb.debian.org/debian/pool/main/a/ax25-tools/ax25-tools_0.0.10-rc5+git20230513+d3e6d4f.orig.tar.gz", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c" ], "editorial_references": [ "round566.html", "round566-sources.json" ], "qualification": "Quality thresholds, obsolescence counters, port configuration and own-node-only broadcasts can suppress advertisements; this does not by itself establish scoped recovery with remote reachability preserved. No means the selected announcement-based mechanism lacks the required scope, not that every node receives every update. C01 same-callsign recovery remains Yes. No additional hierarchical addressing, manually maintained remote mobility mapping or new routing extension is credited. This is source/documentation review, not a measured traffic or scale-failure result." }, { "id": "G02-BA", "feature": "G02", "stack": "BA", "status": "N", "reason": "When a client changes serving mesh node, batman-adv sends a targeted roaming advertisement to its previous node, but also commits the client translation-table change for dissemination in originator messages. BATMAN_IV appends the translation-table container to primary-interface OGMs and forwards eligible received OGMs across the mesh. Other mesh nodes apply changes to their global client tables or request missing table information. Update recipients are therefore not restricted to the old/new attachment region and active communication partners.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Linux 6.12 batman-adv roaming, translation tables and BATMAN_IV OGMs", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/translation-table.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_iv_ogm.c" ], "editorial_references": [ "round557.html", "round557-sources.json" ], "qualification": "This verdict concerns the selected Linux 6.12 BATMAN_IV native Ethernet mesh. Targeted roaming improves immediate forwarding but does not replace mesh-wide table reconciliation. Delta encoding, batching, TTL, duplicate suppression and table requests affect delivery and overhead; No does not mean every frame reaches every node or that a full table is broadcast per move. The C01 same-MAC recovery witness remains Yes. No hierarchical mobility extension, alternative routing algorithm, traffic measurement or scale-failure claim is added." }, { "id": "G02-BL", "feature": "G02", "stack": "BL", "status": "Y", "reason": "An authorized destination node can reattach within a provisioned ULA region and originate its unchanged local prefix through the replacement adjacency. Regional Babel routers, including the ingress used by outside senders, update their selected path. Native prefix/interface filters suppress that specific route on outward interfaces while a separately provisioned covering aggregate remains advertised. External traffic therefore follows a changed regional route without requiring every router to learn the destination's individual attachment.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 8966 route updates and babeld 1.13 prefix/interface export filters", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-C", "https://www.rfc-editor.org/rfc/rfc8966.html#section-3.7", "https://github.com/jech/babeld/blob/babeld-1.13/babeld.man" ], "editorial_references": [ "round562.html", "round562-sources.json" ], "qualification": "Prepare both attachments, permit the origin and prefix inside the region, retain usable return routes and maintain the covering aggregate. Use babeld's outbound filters and explicit redistribution, not assumed automatic aggregation. The exact G01 fixed-tree configuration is not claimed to admit arbitrary moves. Ordinary unfiltered meshes and moves outside the prepared region may propagate changes more widely. Reconvergence, stale routes and withdrawal holds remain relevant. This requires routing authority; F23 remains unchanged. No daemon or mobility experiment ran." }, { "id": "G02-RI", "feature": "G02", "stack": "RI", "status": "Y", "reason": "A leaf retains its configured IPv6 address while changing its parent within the same RPL domain. In non-storing mode, its DAO reports the revised target/parent relationship to the root, which reconstructs the downward source route. The affected neighbors, forwarding path and root handle the update; unrelated nodes need not receive an individual location announcement. A sender elsewhere in the domain can still reach the same destination through the root, whose delivery state has actually changed.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RPL non-storing DAO updates and 6LoWPAN registration", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.7", "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.4", "https://www.rfc-editor.org/rfc/rfc6775.html#section-5.5" ], "editorial_references": [ "round556.html", "round556-sources.json" ], "qualification": "Use the C01 witness: the same ULA remains valid, an eligible parent and provisioned link keys are available, registration succeeds and updated DAO state reaches the root. Keep the domain and aggregate reachability stable. This local leaf change does not require a global repair; other failures, root-triggered refreshes or version changes can have broader effects. Stale state, partitions and finite lifetimes can prevent delivery. No inter-domain mobility, bounded convergence, root-memory bound or integrated runtime qualification is credited." }, { "id": "G02-HP", "feature": "G02", "stack": "HP", "status": "Y", "reason": "A moving HIP host sends UPDATE/LOCATOR_SET to its communicating peer, which verifies the new address and changes its local association binding. The selected case uses an already routed destination access prefix; moving the host does not require a global announcement of its Host Identity or a change to every transit router.", "method": "Primary documentary review and bounded selected-composition inference; no execution", "source_label": "HIP, ILNP, Babel and SCION specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-3.2.1" ], "editorial_references": [ "round494.html", "round494-sources.json" ], "qualification": "This covers retained associations with reachable peers outside the changed access region. Local address acquisition and attachment state still change. No rendezvous service is selected, so this does not provide cold first-contact discovery after movement or simultaneous mobility. Wider prefix failures may still require infrastructure routing updates; no convergence bound is claimed." }, { "id": "G02-CX", "feature": "G02", "stack": "CX", "status": "Y", "reason": "A producer retains its content-name prefix and signing key while moving between provisioned attachments inside a routing region. The ingress forwarder used by outside consumers replaces the prefix's old next-hop link with the new one; affected internal forwarders are adjusted as needed. Other regions keep a covering name-prefix route toward that ingress. CCNx longest-prefix forwarding and Athena FIB add/delete operations support this configured witness without a network-wide producer-location announcement.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 8569 hierarchical forwarding and pinned Athena FIB route operations", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2.4.4", "https://raw.githubusercontent.com/PARC/Athena/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_FIB.c" ], "editorial_references": [ "round567.html", "round567-sources.json" ], "qualification": "This is the C01 named-content boundary with an actual changed route to the producer, not recovery solely from cached content. Provision usable IPv4/UDP links and administer the affected FIB entries; remove obsolete next hops and allow stale PIT state to expire before retrying. Keep the covering prefix route valid and verify the returned object. No automatic producer discovery, arbitrary inter-region movement or routing-protocol extension is assumed. No uninterrupted delivery, global-capacity or runtime result is credited." }, { "id": "G02-LI", "feature": "G02", "stack": "LI", "status": "Y", "reason": "An infrastructure-managed destination reattachment can preserve its EID while changing the serving ETR/RLOC registration. RFC 9301 updates the responsible Map-Server; remote ITRs obtain mappings on demand and refresh relevant caches through selective SMR or expiry and lookup. These external ITRs change their encapsulation destination, so this is not merely an unchanged external route. The individual binding need not be broadcast to every router or participant.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "RFC 9301 registration, selective SMR and on-demand mapping lookup", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-6.1", "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.1", "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.2", "https://www.rfc-editor.org/rfc/rfc9301.html#section-5.4" ], "editorial_references": [ "round553.html", "round553-sources.json" ], "qualification": "Use the existing C01 witness: authorized ETRs, local delivery at the new attachment, already-routed old/new RLOC prefixes, stable mapping-system authority and finite cache TTLs. Registration, affected-site state and interested ITR caches change. SMR targets recent traffic partners and does not enumerate every cache; stale one-way or inactive caches may require expiry. Mapping-service replication and resolution paths remain part of the affected control scope. Moving underlay aggregates or mapping authority can require wider updates. This is an administratively managed capability, not autonomous endpoint mobility, instantaneous recovery or a global-capacity claim. No LISP-MN, LISP-SEC or Pub/Sub extension is added." }, { "id": "G02-IL", "feature": "G02", "stack": "IL", "status": "Y", "reason": "ILNP changes a mobile destination Locator while retaining its Identifier. RFC 6740 sections 5.1 and 6 send Locator Updates to active correspondents and update the relevant DNS records for future incoming sessions. Per-host changes do not require disseminating the new Locator to every router or every network participant.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "Pinned architecture/lifecycle source and ILNP experimental RFCs", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-6", "https://www.rfc-editor.org/rfc/rfc6743.html" ], "editorial_references": [ "round489.html", "round489-sources.json" ], "qualification": "Use the selected overlapping authorized attachments and stable reachable correspondent. The new access prefix is already routed; local attachment state changes, correspondents receive updates, and authoritative DNS plus interested caches handle rendezvous. DNS update/cache delay and wider failures of routing aggregates remain; no zero-interruption, immediate cold discovery or constant global update-cost guarantee. This evaluates a moving destination, not merely an initiating client." }, { "id": "G02-TS", "feature": "G02", "stack": "TS", "status": "Y", "reason": "A changed endpoint locator is reported to the coordinator and distributed in peer-map updates to relevant authorized peers. It need not be announced to every Tailscale participant or as an individual endpoint route in the global Internet.", "method": "Primary documentation and pinned source; explicit architectural inference", "source_label": "Tailscale addressing, control plane, magicsock and tailcfg", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/concepts/tailscale-ip-addresses", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/wgengine/magicsock/endpoint.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/tailcfg/tailcfg.go", "https://tailscale.com/blog/sqlite-wal-reset-bug" ], "editorial_references": [ "round591.html", "round591-sources.json" ], "qualification": "Source witness: MapRequest endpoint reporting and MapResponse PeerChange.Endpoints. Scope includes the tailnet control service, relevant peer maps and relay state. Authorized peer sets can be large; this does not establish a small worst-case update fanout or global capacity." }, { "id": "G02-RA", "feature": "G02", "stack": "RA", "status": "Y", "reason": "RINA limits mobility updates through nested DIF scopes. Attachment and address changes update routing and directory mappings within the affected DIF; higher scopes see only moves crossing their lower-DIF boundaries. The selected two-provider IRATI mobility mode explicitly hides within-provider handovers from the Internet DIF while maintaining bidirectional application flows.", "method": "Architecture, configuration and documented mobility-mode inspection; no new runtime test", "source_label": "ETSI RINA architecture report and IRATI configuration/mobility documentation", "sources": [ "https://www.etsi.org/deliver/etsi_gr/NGP/001_099/009/01.01.01_60/gr_ngp009v010101p.pdf", "https://github.com/IRATI/stack/wiki/Tutorial-10:-DMM-two-providers-ARCFIRE-2018", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcm/addons/mobility-manager.cc" ], "editorial_references": [ "round663.html" ], "qualification": "Yes for the documented scoped-update mechanism, including destination reachability. It is not based merely on an initiating client reconnecting: lower-layer routes and mappings change while upper communication remains reachable. Boundary crossings can affect higher DIFs; a single flat global DIF would not provide this benefit. Convergence time and global workload capacity remain unqualified. See ETSI section 7.4 and Tutorial 10." }, { "id": "G03-PN", "feature": "G03", "stack": "PN", "status": "Y", "reason": "PRP architecture sections 7.1/7.2 describe installed local forwarding entries and next-hop bindings. Section 8.4 describes relationship-scoped Bloom discovery hints followed by exact lookup and destination proof. These mechanisms do not require every transit participant to replicate a complete catalog of all final identities.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "Pinned architecture/lifecycle source and ILNP experimental RFCs", "sources": [], "editorial_references": [ "round489-sources.json", "round489.html", "round489-sources.json" ], "qualification": "Scoped identity records, local relationships and partial discovery state are credited; neither zero state nor zero query cost is claimed. Bloom positives alone are not authority or exact identity proof. This is a per-node catalog criterion, not a bound on distributed discovery work, update propagation or global capacity. Current architectural source, no new runtime qualification." }, { "id": "G03-PI", "feature": "G03", "stack": "PI", "status": "Y", "reason": "PRP architecture sections 7.1/7.2 describe installed local forwarding entries and next-hop bindings. Section 8.4 describes relationship-scoped Bloom discovery hints followed by exact lookup and destination proof. These mechanisms do not require every transit participant to replicate a complete catalog of all final identities.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "Pinned architecture/lifecycle source and ILNP experimental RFCs", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3" ], "editorial_references": [ "round489-sources.json", "round489.html", "round489-sources.json" ], "qualification": "Scoped identity records, local relationships and partial discovery state are credited; neither zero state nor zero query cost is claimed. Bloom positives alone are not authority or exact identity proof. This is a per-node catalog criterion, not a bound on distributed discovery work, update propagation or global capacity. The IPv4 underlay can use prefix/default routes and local neighbor state rather than a complete host catalog; global BGP dependencies remain assessed in G01. Current architectural source, no new runtime qualification." }, { "id": "G03-IP", "feature": "G03", "stack": "IP", "status": "Y", "reason": "IP forwarding can use prefix routes and a default next hop instead of a complete catalog of every final host address. Neighbor resolution concerns the attached next hop, and the selected profile already supplies numeric destinations. Thus neither discovering the local forwarding adjacency nor forwarding a remote packet requires each transit node to replicate a global hosts catalog.", "method": "Primary documentary assessment under revised criterion; no runtime experiment", "source_label": "Pinned PRP architecture worktree and IP RFCs", "sources": [ "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3", "https://www.rfc-editor.org/rfc/rfc1812.html#section-3.3.2" ], "editorial_references": [ "round488.html", "round488-sources.json" ], "qualification": "This does not supply discovery of unknown application names. Global BGP reachability tables and provider dependency remain separate G01/G05 questions; a prefix routing table is not a complete per-host identity catalog. The result credits the revised per-node requirement, not zero state, bounded cache-miss cost or global capacity." }, { "id": "G03-BP", "feature": "G03", "stack": "BP", "status": "Y", "reason": "For a supplied destination EID, the selected aggregate-gateway configuration can forward by destination ranges rather than enumerating every final endpoint. RFC 9171 section 5.4 permits forwarding through another node; SABR Annex C.1.2 documents range-to-gateway rules and route calculation to the selected gateway. Local contact/neighbor information and aggregate exits therefore suffice at a forwarding node without a complete global identity catalog.", "method": "Primary documentary reassessment of configured aggregate gateway witness; no execution", "source_label": "RFC 9171 section 5.4 and SABR Annex C.1.2", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round497.html", "round497-sources.json" ], "qualification": "This is a configured known-EID capability, not arbitrary-name discovery or an automatic directory. SABR Annex C is informative implementation guidance, not a mandatory feature of every BP implementation. Gateways still need suitable onward routes; contact plans, boundary configuration, endpoint-key provisioning and resource costs remain. No G01/G05 verdict or execution result follows. The selected BP/TCPCL/IP composition retains its aggregate-exit witness; the IP underlay uses prefix routing." }, { "id": "G03-CG", "feature": "G03", "stack": "CG", "status": "Y", "reason": "For a supplied destination EID, the selected aggregate-gateway configuration can forward by destination ranges rather than enumerating every final endpoint. RFC 9171 section 5.4 permits forwarding through another node; SABR Annex C.1.2 documents range-to-gateway rules and route calculation to the selected gateway. Local contact/neighbor information and aggregate exits therefore suffice at a forwarding node without a complete global identity catalog.", "method": "Primary documentary reassessment of configured aggregate gateway witness; no execution", "source_label": "RFC 9171 section 5.4 and SABR Annex C.1.2", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round497.html", "round497-sources.json" ], "qualification": "This is a configured known-EID capability, not arbitrary-name discovery or an automatic directory. SABR Annex C is informative implementation guidance, not a mandatory feature of every BP implementation. Gateways still need suitable onward routes; contact plans, boundary configuration, endpoint-key provisioning and resource costs remain. No G01/G05 verdict or execution result follows. This reuses the documented aggregate-gateway option already considered for the selected SABR composition; complete BPv7/SABR metadata and convergence-layer integration remain unqualified. The TCPCL/IP underlay retains its routing dependencies." }, { "id": "G03-LT", "feature": "G03", "stack": "LT", "status": "Y", "reason": "For a supplied destination EID, the selected aggregate-gateway configuration can forward by destination ranges rather than enumerating every final endpoint. RFC 9171 section 5.4 permits forwarding through another node; SABR Annex C.1.2 documents range-to-gateway rules and route calculation to the selected gateway. Local contact/neighbor information and aggregate exits therefore suffice at a forwarding node without a complete global identity catalog.", "method": "Primary documentary reassessment of configured aggregate gateway witness; no execution", "source_label": "RFC 9171 section 5.4 and SABR Annex C.1.2", "sources": [ "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc9171.html#section-5.4" ], "editorial_references": [ "round497.html", "round497-sources.json" ], "qualification": "This is a configured known-EID capability, not arbitrary-name discovery or an automatic directory. SABR Annex C is informative implementation guidance, not a mandatory feature of every BP implementation. Gateways still need suitable onward routes; contact plans, boundary configuration, endpoint-key provisioning and resource costs remain. No G01/G05 verdict or execution result follows. This reuses the documented aggregate-gateway option already considered for the selected SABR composition; complete BPv7/SABR metadata and convergence-layer integration remain unqualified. LTP/Encapsulation/AOS uses provisioned adjacent peer and channel mappings; no IP underlay is added." }, { "id": "G03-LP", "feature": "G03", "stack": "LP", "status": "Y", "reason": "The selected direct QUIC composition starts from known numeric peer addresses. Connection state is specific to contacted peers; underlay transit can forward through prefix/default routes and local neighbor resolution without a complete per-endpoint catalog. The selected libp2p Peer IDs and peer contact records do not require every transit node to replicate all Peer IDs. ", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "RFC routing/discovery mechanisms and pinned Meshtastic header", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-7", "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3" ], "editorial_references": [ "round491.html", "round491-sources.json" ], "qualification": "This covers the declared known-peer composition and actual forwarding state, not an unselected arbitrary-peer discovery service. No DHT or rendezvous service is silently introduced. Upstream BGP prefix state, lookup cost and global capacity remain separate G01/G05 questions; the same known-numeric-destination boundary is used for standalone IP." }, { "id": "G03-TO", "feature": "G03", "stack": "TO", "status": "Y", "reason": "For a known onion-service identity, a Tor client requests the needed descriptor from an appropriate HSDir, then uses introduction and rendezvous circuits. Relays forward through circuit state; they need not catalog every final onion-service or client identity. Service descriptors are distributed among HSDirs rather than all downloaded by every client.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Selected discovery and pathfinder mechanisms", "sources": [ "https://spec.torproject.org/rend-spec/protocol-overview.html" ], "editorial_references": [ "round496.html", "round496-sources.json" ], "qualification": "The selected client-authorization material and public relay-directory infrastructure remain necessary. Relay consensus distribution is not removed: this verdict concerns complete final-participant identity catalogs. Descriptor availability, circuit construction, directory trust and resource costs remain separate; no arbitrary-name discovery or global-capacity finding is implied." }, { "id": "G03-I2", "feature": "G03", "stack": "I2", "status": "Y", "reason": "I2P distributes RouterInfo and destination LeaseSet records through floodfill peers. Iterative lookups operate with partial knowledge of those peers. Tunnel participants forward using established tunnel state rather than requiring a complete catalog of all final destinations at each hop.", "method": "Primary documentation and selected firmware review; no runtime experiment", "source_label": "Official discovery documentation and pinned forwarding code", "sources": [ "https://i2p.net/en/docs/overview/network-database/" ], "editorial_references": [ "round495.html", "round495-sources.json" ], "qualification": "The selected fresh bootstrap contacts and known destination keys remain prerequisites. Floodfill replication, local caches, tunnel state and IP underlay routes still consume resources. Lookup timeouts, stale records and unavailable peers can prevent discovery; this does not establish G05 or guaranteed delivery." }, { "id": "G03-YG", "feature": "G03", "stack": "YG", "status": "Y", "reason": "The selected Ironwood pathfinder sends a lookup for the requested key through Bloom-guided tree multicast, accepts a signed path notification, and caches the resulting path. Forwarding selects among local peers using tree-path distance. Aggregate reachability information, local adjacencies and demand-driven path caches replace an obligatory enumeration of every final public key at every node.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Selected discovery and pathfinder mechanisms", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go" ], "editorial_references": [ "round498.html", "round498-sources.json" ], "qualification": "The numeric Yggdrasil destination and connected peer topology are supplied. Bloom false positives, query branching, cached paths and churn can still impose substantial costs or cause lookup failure. This is the pinned Ironwood composition, not a claim about every historical Yggdrasil design, arbitrary-name search or global scale." }, { "id": "G03-CJ", "feature": "G03", "stack": "CJ", "status": "Y", "reason": "In the selected cjdns route-server composition, SubnodePathfinder sends a getRoute query containing source and target to its configured server, then passes the returned route to the forwarding core. Ordinary clients and transit switches do not require their own complete copies of the server graph or all final participant identities.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Selected discovery and pathfinder mechanisms", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/subnode/SubnodePathfinder.c#L276" ], "editorial_references": [ "round496.html", "round496-sources.json" ], "qualification": "The numeric target, reachable configured server and local peer connectivity remain prerequisites. Servers may hold broad or complete graphs; G03 does not prohibit concentration at a particular role. This is the selected route-server design, not a legacy-DHT claim, and does not establish partitioned server storage, server independence, bounded lookup cost or global scale." }, { "id": "G03-MQ", "feature": "G03", "stack": "MQ", "status": "Y", "reason": "The selected direct QUIC composition starts from known numeric peer addresses. Connection state is specific to contacted peers; underlay transit can forward through prefix/default routes and local neighbor resolution without a complete per-endpoint catalog. ", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "RFC routing/discovery mechanisms and pinned Meshtastic header", "sources": [ "https://www.rfc-editor.org/rfc/rfc9000.html#section-7", "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3" ], "editorial_references": [ "round491.html", "round491-sources.json" ], "qualification": "This covers the declared known-peer composition and actual forwarding state, not an unselected arbitrary-peer discovery service. No DHT or rendezvous service is silently introduced. Upstream BGP prefix state, lookup cost and global capacity remain separate G01/G05 questions; the same known-numeric-destination boundary is used for standalone IP." }, { "id": "G03-SC", "feature": "G03", "stack": "SC", "status": "Y", "reason": "SCION discovers and registers AS-level path segments; an endpoint obtains segments and combines a forwarding path carried in packet headers. Inter-domain forwarding is independent of the endpoint-local address. Neither path resolution nor transit forwarding requires every node to catalog every final endpoint identity.", "method": "Primary documentary reassessment; no runtime test", "source_label": "Selected routing and HIP specifications", "sources": [ "https://docs.scion.org/en/latest/overview.html#routing", "https://docs.scion.org/en/latest/overview.html#isd-and-as-numbering" ], "editorial_references": [ "round493.html", "round493-sources.json" ], "qualification": "The selected numeric ISD-AS and local destination address must be known. Path services, AS-level state and intra-AS delivery remain necessary. This result does not establish unrestricted endpoint discovery, independence from trust roots or global resource bounds." }, { "id": "G03-RT", "feature": "G03", "stack": "RT", "status": "Y", "reason": "With transport enabled and the selected recursive_prs setting, Reticulum 1.5.5 can propagate a path request for an unknown destination through other interfaces. Responses and announces populate learned path state. A transport node can therefore discover a requested route without first holding a complete catalog of all destination identities.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Selected discovery and pathfinder mechanisms", "sources": [ "https://github.com/markqvist/Reticulum/blob/1.5.5/RNS/Transport.py" ], "editorial_references": [ "round496.html", "round496-sources.json" ], "qualification": "The destination hash and authorized serial connectivity are supplied. Request tags, timeouts and ingress/egress limits constrain discovery; a request may fail. Learned paths and identity data still occupy memory. This establishes the absence of a mandatory complete catalog at every node, not bounded discovery work, guaranteed reachability or global capacity. G05 is unchanged." }, { "id": "G03-NS", "feature": "G03", "stack": "NS", "status": "Y", "reason": "NIP-01 clients publish events and subscribe with filters to selected relays. A relay matches requests against its own event set; neither every client nor every relay must replicate a complete global author or event catalog. The selected IP underlay likewise does not require every transit router to catalog all Nostr authors.", "method": "Primary documentation and selected firmware review; no runtime experiment", "source_label": "Official discovery documentation and pinned forwarding code", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round495.html", "round495-sources.json" ], "qualification": "Discovery here means retrieving matching events from configured relays. NIP-01 supplies neither global relay discovery nor complete search across all relays. The selected hostname resolution and IP routing dependencies remain. Availability depends on publication to reachable queried relays; this is not peer-to-peer packet routing or proof of global scale." }, { "id": "G03-MT", "feature": "G03", "stack": "MT", "status": "Y", "reason": "In the pinned Meshtastic firmware, a missing usable next-hop entry permits fallback to managed flooding. Intermediate CLIENT/ALL nodes can forward within the hop budget without a complete global NodeDB. Known destination and endpoint-key provisioning do not require provisioning every participant at each transit node.", "method": "Primary documentation and selected firmware review; no runtime experiment", "source_label": "Official discovery documentation and pinned forwarding code", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp" ], "editorial_references": [ "round495.html", "round495-sources.json" ], "qualification": "This uses the selected ordinary CLIENT/ALL forwarding case, not the separate F16 KNOWN_ONLY administrative witness. The destination identifier and trusted endpoint key are supplied. Hop limits, duplicate suppression, radio loss and congestion constrain reachability; flooding does not establish global capacity or arbitrary name discovery. No radio experiment was run." }, { "id": "G03-GN", "feature": "G03", "stack": "GN", "status": "Y", "reason": "The selected R5N DHT distributes replicated records and supports lookups through an overlay that need not be a full mesh. CADET obtains paths to known peer identities and forwards through intermediate peers using connection state. Every participant need not store a complete inventory of final peers.", "method": "Primary documentation and selected firmware review; no runtime experiment", "source_label": "Official discovery documentation and pinned forwarding code", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/dht/dht.html", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [ "round495.html", "round495-sources.json" ], "qualification": "The v0.20.x documentary baseline and supplied bootstrap contacts are retained. DHT lookup is probabilistic and can fail or return late; a discovered path must still be usable. Partial neighbor, record and connection state is allowed by G03. This gives no global-capacity, bounded-latency or arbitrary human-name-search result." }, { "id": "G03-ND", "feature": "G03", "stack": "ND", "status": "Y", "reason": "NFD routes Interests by name prefix to next-hop faces. The selected tree/root-prefix configuration uses local adjacencies and local producer registrations, rather than a global inventory of producers, consumers or every content object. Pending Interests and cached Data are scoped to traffic, not a mandatory complete identity catalog.", "method": "Primary documentary reassessment; no runtime or energy test", "source_label": "Selected name-routing and transport/control specifications", "sources": [ "https://docs.named-data.net/NFD/24.07/manpages/nfdc-route.html" ], "editorial_references": [ "round492.html", "round492-sources.json" ], "qualification": "Known content/key names are supplied in this composition. This is route-based retrieval, not discovery of unknown names or semantic search. Root-prefix flooding can be expensive; no G05 capacity or bounded lookup-work result follows. The selected Ethernet faces do not add a global IP directory." }, { "id": "G03-AX", "feature": "G03", "stack": "AX", "status": "N", "reason": "The selected classic NET/ROM routing system learns individual destination-node callsigns through announcements. Linux v6.12 nr_route_frame looks up the exact destination and refuses forwarding when no node entry exists. To support arbitrary destinations in its routing domain, a transit node needs the corresponding per-destination catalog; no aggregate/default-route or recursive miss-resolution service is selected.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Selected discovery and pathfinder mechanisms", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/nr_route.c", "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [ "round498.html", "round498-sources.json" ], "qualification": "This concerns native NET/ROM destination-node identities, not civil identities or a list of every application user. Smaller or incomplete tables can forward to their known subset; they do not supply discovery of an omitted destination. Neighbor tables and up to three routes per known destination do not remove this dependency. No claim that all tables are identical during convergence is made." }, { "id": "G03-BA", "feature": "G03", "stack": "BA", "status": "N", "reason": "In the selected BATMAN_IV mesh, originator advertisements establish individual mesh-destination reachability and translation-table updates distribute client-MAC mappings. Native unicast uses these exact destination entries: a missing translation or usable originator route does not trigger an aggregate/default route or a distributed identity lookup that replaces the domain catalog.", "method": "Primary specification and pinned code review; no runtime experiment", "source_label": "Selected discovery and pathfinder mechanisms", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_iv_ogm.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/translation-table.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/send.c" ], "editorial_references": [ "round498.html", "round498-sources.json" ], "qualification": "Credit is assessed for arbitrary native unicast destinations across the selected mesh, not only a known subset or broadcast traffic. Attached Ethernet clients need not run this catalog, but the routing nodes distribute destination-specific state. Translation-table repair synchronizes that state rather than replacing it with catalog-free discovery. No identical-table, instantaneous-convergence or all-version claim is made." }, { "id": "G03-BL", "feature": "G03", "stack": "BL", "status": "Y", "reason": "Babel advertises reachable prefixes rather than requiring an inventory of all endpoint identities. The selected hierarchical IPv6 configuration forwards using aggregate routes, local leaf routes and neighbor state; supplied numeric destinations need no global host-name catalog at each router.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "RFC routing/discovery mechanisms and pinned Meshtastic header", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html", "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3" ], "editorial_references": [ "round491.html", "round491-sources.json" ], "qualification": "This credits the explicit provisioned hierarchy and route filters already selected, not automatic aggregation for arbitrary topologies. Prefix reachability state remains, and generic deployments can carry many routes. No stronger G01 or quantitative G05 result is inferred." }, { "id": "G03-RI", "feature": "G03", "stack": "RI", "status": "Y", "reason": "In the selected RPL non-storing mode, ordinary nodes use DODAG parents/default routes for upward forwarding; the root constructs downward source routes from DAO information. Every forwarding node need not store a complete catalog of final participant identities.", "method": "Primary documentary reassessment; no runtime test", "source_label": "Selected routing and HIP specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-3.3", "https://www.rfc-editor.org/rfc/rfc6550.html#section-9.7" ], "editorial_references": [ "round493.html", "round493-sources.json" ], "qualification": "The root still accumulates topology and destination state. G03 permits this concentration; it does not establish G01 or global capacity. Numeric destination addresses are supplied, and this result does not add application-level discovery or arbitrary name lookup." }, { "id": "G03-HP", "feature": "G03", "stack": "HP", "status": "Y", "reason": "The selected HIP composition starts with a known peer HIT and numeric locator. Hosts maintain bindings and security associations for communicating peers, while the IP underlay forwards using prefixes, default routes and local neighbors. No complete catalog of all Host Identities is required at every transit node.", "method": "Primary documentary reassessment; no runtime test", "source_label": "Selected routing and HIP specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8046.html#section-3.1", "https://www.rfc-editor.org/rfc/rfc7402.html#section-3.2", "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3" ], "editorial_references": [ "round493.html", "round493-sources.json" ], "qualification": "Known peer references are a declared composition prerequisite, as for the numeric-IP baseline. This does not provide semantic discovery of unknown peers, remove global IP routing dependencies or prove global scale. DNS and rendezvous services are not selected." }, { "id": "G03-CX", "feature": "G03", "stack": "CX", "status": "Y", "reason": "CCNx forwards Interests using hierarchical longest-prefix matching, and RFC 8569 explicitly permits a simple default FIB at an endpoint. The selected name-prefix routes and adjacent forwarder contacts do not require a complete inventory of all producers, consumers or Content Objects at every forwarding node.", "method": "Primary documentary reassessment; no runtime or energy test", "source_label": "Selected name-routing and transport/control specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-2", "https://www.rfc-editor.org/rfc/rfc1812.html#section-5.2.4.3" ], "editorial_references": [ "round492.html", "round492-sources.json" ], "qualification": "Supplied content names and configured routes remain prerequisites. PIT and content-store state may grow with traffic; global name-routing costs are not bounded by this result. The IP/UDP underlay retains prefix/neighbor forwarding rather than a per-host catalog; its global routing dependencies remain separate." }, { "id": "G03-LI", "feature": "G03", "stack": "LI", "status": "Y", "reason": "LISP ITRs resolve EID-to-RLOC mappings through Map-Resolvers and retain on-demand Map-Caches. ETRs register their EID prefixes; ordinary underlay transit forwards to RLOCs. This separates discovery and forwarding from replication of every final EID at every node.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "RFC routing/discovery mechanisms and pinned Meshtastic header", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.1", "https://www.rfc-editor.org/rfc/rfc9300.html#section-6" ], "editorial_references": [ "round491.html", "round491-sources.json" ], "qualification": "The mapping infrastructure still maintains authoritative state, and deployment choices can replicate it. The criterion permits scoped services and does not require absence of all large tables anywhere. This result does not settle the complete-underlay G01 criterion or the capacity of the mapping database." }, { "id": "G03-IL", "feature": "G03", "stack": "IL", "status": "Y", "reason": "ILNP resolves the relevant NID/L64 DNS records and retains correspondent bindings in its ILCC. Transit forwards on Locator prefixes rather than requiring a complete catalog of every Node Identifier. Discovery queries and forwarding therefore do not force all nodes to replicate global endpoint identities.", "method": "Primary documentary reassessment; no runtime experiment", "source_label": "RFC routing/discovery mechanisms and pinned Meshtastic header", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6742.html" ], "editorial_references": [ "round491.html", "round491-sources.json" ], "qualification": "Authoritative DNS, caches and correspondent state remain real dependencies. Existing IPv6-style prefix routing is retained. Neither lookup latency nor absence of global reachability state elsewhere is inferred; no arbitrary scaling or runtime qualification follows." }, { "id": "G03-TS", "feature": "G03", "stack": "TS", "status": "Y", "reason": "Clients receive information for permitted peers, and DERP relays maintain regional connected-client reachability. Every forwarding node need not hold the complete identity catalog of the whole network.", "method": "Official documentation and pinned source inspection; no runtime test", "source_label": "Tailscale control plane and DERP source 566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225", "sources": [ "https://tailscale.com/docs/concepts/control-data-planes", "https://tailscale.com/docs/concepts/control-data-planes", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/README.md", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derp.go", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/derp/derpserver/derpserver.go" ], "editorial_references": [ "round586.html", "round586-sources.json" ], "qualification": "The coordination service still holds the tailnet registry. This criterion permits centralized or partitioned discovery state; G01 and G05 separately assess complete reachability state and scale." }, { "id": "G03-RA", "feature": "G03", "stack": "RA", "status": "Y", "reason": "Recursive DIF composition scopes directory and forwarding state. IRATI replicates its directory of registered application names within a DIF, while a lower DIF serves upper IPC processes as its applications. Lower transit participants therefore need not hold the final-application catalog of every upper DIF. Local directory replication does not impose a complete final-identity catalog at every network node.", "method": "Primary architectural evidence: recursive IPC scopes and per-DIF directory state", "source_label": "Boston University RINA scope model and IRATI Namespace Manager", "sources": [ "https://csr.bu.edu/rina/about.html", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round656.html" ], "qualification": "Architectural Yes for scoped recursive composition, not for a flat universal DIF. A DIF member can still carry the full directory of applications registered with that DIF. This does not resolve G01 or G05: the size and placement of upper directories, discovery across scopes and quantitative global capacity remain separate questions. No execution or memory measurement." }, { "id": "G04-PN", "feature": "G04", "stack": "PN", "status": "Y", "reason": "Recursive aggregation assigns routing responsibility to local contexts that can delegate to further independently operated contexts; no globally privileged aggregator or mandatory global directory coordinator is required. Discovery indexes are scoped to relationships. This supports distributed work placement, not a bound on hot rendezvous nodes or lookup cost. ", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [], "editorial_references": [ "index.html#round041" ], "qualification": "Bind the complete forwarding/discovery composition to executable code; distribute participants across aggregators and measure index fanout, skew, failover and admission convergence. ROUTE-001 and global-scale G05 remain unqualified; local hot spots are possible." }, { "id": "G04-PI", "feature": "G04", "stack": "PI", "status": "Y", "reason": "Recursive aggregation assigns routing responsibility to local contexts that can delegate to further independently operated contexts; no globally privileged aggregator or mandatory global directory coordinator is required. Discovery indexes are scoped to relationships. This supports distributed work placement, not a bound on hot rendezvous nodes or lookup cost. The selected independent private-IP underlay retains its routing costs.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [], "editorial_references": [ "index.html#round041" ], "qualification": "Bind the complete forwarding/discovery composition to executable code; distribute participants across aggregators and measure index fanout, skew, failover and admission convergence. ROUTE-001 and global-scale G05 remain unqualified; local hot spots are possible." }, { "id": "G04-IP", "feature": "G04", "stack": "IP", "status": "Y", "reason": "BGP control is distributed among ASes and speakers; additional regions can use additional speakers rather than one mandatory global coordinator. Multiple route-reflector clusters can distribute client work, with redundant reflectors. PIM-SM group-to-RP mapping allows separate groups to use different RPs. This is distribution of work, not removal of replicated routing tables or unlimited scaling of one group.", "method": "Documentary analysis; no protocol execution", "source_label": "Primary specification / explicit selected policy", "sources": [ "https://www.rfc-editor.org/rfc/rfc4456.html#section-7", "https://www.rfc-editor.org/rfc/rfc4271.html", "https://www.rfc-editor.org/rfc/rfc7761.html#section-4.7.1" ], "editorial_references": [], "qualification": "Specify AS/cluster/group placement and measure per-speaker state, update work and convergence. A full table can remain replicated; G01 stays No and G05 stays pending." }, { "id": "G04-BP", "feature": "G04", "stack": "BP", "status": "Y", "reason": "Selected static range-to-gateway exits permit forwarding responsibility to be divided among additional gateways. No single global contact-plan processor is mandatory in this profile. This is operator-configured partitioning, not automatic load balancing.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/integration/site-docs/docs/deployment-guide.md" ], "editorial_references": [], "qualification": "Measure gateway partitions, aggregate exits, queue storage and replication overhead. Test hot destinations and common links; a star topology can still bottleneck. No execution performed." }, { "id": "G04-CG", "feature": "G04", "stack": "CG", "status": "Y", "reason": "A concrete plausible configuration uses independently provisioned regional contact plans and multiple reachable gateways. Pinned ION documentation limits CGR to destinations in a locally shared region and provides destination-range exits for other regions. Each region computes its own routes; operators provision only their local plan and agreed boundary contacts, while exits select reachable neighboring gateways. Adding regions and gateways can therefore distribute routing and plan-management work without requiring one fixed-capacity global coordinator. This is a constructive configuration inference, not a conclusion drawn merely from the word decentralized.", "method": "Documentary plausibility of an explicit partitioned configuration; no scale experiment", "source_label": "ION regional routing and exit configuration; SABR management scope", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/ipnrc.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/bprc.pod", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round196-sources.json", "round306-sources.json" ], "qualification": "For the selected IPv4/TCP/TLS underlay, use multiple provisioned peer paths and locally maintained participant trust; this adds no obligatory single online coordinator. Global Internet dependencies remain separately accounted for. Conditions: coherent destination-range ownership, loop-free exits, reachable gateways, compatible bilateral contact schedules and local key/clock administration. Recover a failed boundary by local replanning or a preprovisioned alternative; no automatic convergence time or universal failure tolerance is promised. No new distributed planner is claimed. A chosen central mission planner can still be a bottleneck. Complete BPv7/SABR and convergence-layer integration remains unqualified. This does not close G01/G05, bound table size, or establish performance." }, { "id": "G04-LT", "feature": "G04", "stack": "LT", "status": "Y", "reason": "A concrete plausible configuration uses independently provisioned regional contact plans and multiple reachable gateways. Pinned ION documentation limits CGR to destinations in a locally shared region and provides destination-range exits for other regions. Each region computes its own routes; operators provision only their local plan and agreed boundary contacts, while exits select reachable neighboring gateways. Adding regions and gateways can therefore distribute routing and plan-management work without requiring one fixed-capacity global coordinator. This is a constructive configuration inference, not a conclusion drawn merely from the word decentralized.", "method": "Documentary plausibility of an explicit partitioned configuration; no scale experiment", "source_label": "ION regional routing and exit configuration; SABR management scope", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/ipnrc.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/bprc.pod", "https://ccsds.org/Pubs/734x3b1.pdf" ], "editorial_references": [ "round196-sources.json", "round306-sources.json" ], "qualification": "For the selected non-IP LTP/Encapsulation/AOS underlay, each region owns its engine/channel and contact configuration; boundary operators agree their adjacent contacts and return opportunities. No IP-based discovery or central plan server is introduced. Conditions: coherent destination-range ownership, loop-free exits, reachable gateways, compatible bilateral contact schedules and local key/clock administration. Recover a failed boundary by local replanning or a preprovisioned alternative; no automatic convergence time or universal failure tolerance is promised. No new distributed planner is claimed. A chosen central mission planner can still be a bottleneck. Complete BPv7/SABR and convergence-layer integration remains unqualified. This does not close G01/G05, bound table size, or establish performance." }, { "id": "G04-LP", "feature": "G04", "stack": "LP", "status": "Y", "reason": "Known-peer direct connections place state at participating endpoints. Additional peers and routed subnets can distribute independent connection populations without a common libp2p coordinator. No DHT or pubsub scaling is credited to this minimal profile.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://raw.githubusercontent.com/libp2p/specs/master/connections/README.md" ], "editorial_references": [], "qualification": "Measure aggregate capacity across independent peer populations and shared IP bottlenecks. Operator provisioning is assumed; no automatic workload partitioning or global-capacity proof." }, { "id": "G04-TO", "feature": "G04", "stack": "TO", "status": "N", "reason": "In the selected public Tor directory architecture, authorities each compute the same global relay consensus. Extra caches distribute downloads and extra relays distribute traffic, but do not partition this obligatory consensus-generation work. The complete stack therefore retains a common coordination workload under the row's scale-out criterion. This identifies an architectural dependency, not a measured capacity ceiling or a single physical server.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://spec.torproject.org/dir-spec/consensus-formats.html" ], "editorial_references": [], "qualification": "" }, { "id": "G04-I2", "feature": "G04", "stack": "I2", "status": "Y", "reason": "NetDb stores records on key-selected floodfill subsets, and additional routers can join that role. This supplies a mechanism to distribute discovery work instead of one compulsory fixed coordinator. Uneven keys, replication and routing costs remain.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://i2p.net/en/docs/overview/network-database/" ], "editorial_references": [], "qualification": "Measure floodfill storage/query distribution, replication, opt-in behavior, churn and adversarial key concentration. Architectural credit does not establish linear scaling or G05." }, { "id": "G04-YG", "feature": "G04", "stack": "YG", "status": "Y", "reason": "Forwarding and subtree-filtered lookup are performed by distributed peers, without one mandatory processor for all payloads or lookups. This credits work placement, not a bound on lookup flooding or filter saturation.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/README.md" ], "editorial_references": [], "qualification": "Measure Bloom-filter false positives, lookup fanout, tree hotspots and per-node costs under skew and churn. No global-scale result." }, { "id": "G04-CJ", "feature": "G04", "stack": "CJ", "status": "Y", "reason": "In the explicitly selected replicated route-server design, client populations can select different supernodes. Each server answers route queries using its own graph and cache; configured peers exchange announcements asynchronously without a mandatory central query processor or global agreement step for each route. This distributes query computation, not necessarily graph storage or update work. Credit is architectural; growing replicated state, interoperability and global capacity remain unqualified.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [], "editorial_references": [ "index.html#round046" ], "qualification": "Bind the pinned Rust route-server design to cjdns f5902acab6dd2f1a68bf6e4c89e352ed71f93698; verify full announcement/signature/state-hash and query/reply compatibility, not just matching message names. Configure multiple independent servers and peer synchronization, distribute clients, measure per-server query work, replicated graph/update costs, stale answers and failure recovery. No deployment, linear scaling or billions-of-devices capacity is established." }, { "id": "G04-MQ", "feature": "G04", "stack": "MQ", "status": "Y", "reason": "The known-peer deployment can partition connection populations across additional endpoints and routed subnets; QUIC has no mandatory global connection coordinator. This architectural decomposition does not make one connection or one server scale without limit.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://datatracker.ietf.org/doc/html/rfc9000#section-5" ], "editorial_references": [], "qualification": "Measure partitioned endpoint populations, per-connection path state and shared bottlenecks. Endpoint selection is provisioned, not a discovery service supplied by QUIC." }, { "id": "G04-SC", "feature": "G04", "stack": "SC", "status": "Y", "reason": "SCION partitions routing into AS/ISD scopes with multiple core ASes and path infrastructure. Additional scopes and service instances can distribute control work without one compulsory global server. TRC governance remains an authority dependency under S01.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://docs.scion.org/en/latest/overview.html" ], "editorial_references": [], "qualification": "Measure path registration/lookup and inter-ISD core work as infrastructure grows; include trust updates and skew. Multiple roles alone are not a quantitative capacity result." }, { "id": "G04-RT", "feature": "G04", "stack": "RT", "status": "Y", "reason": "Multiple configured transport nodes can serve different network regions, forwarding packets and servicing path requests without a mandatory single central directory or transport processor. This is distributed placement, not guaranteed linear scaling; unnecessary transport nodes can increase announcement load.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://reticulum.network/manual/networks.html" ], "editorial_references": [], "qualification": "Measure announcement propagation, path-table size, regional hotspots and lookup load with multiple transport nodes. Global capacity and billions of devices remain unqualified." }, { "id": "G04-NS", "feature": "G04", "stack": "NS", "status": "Y", "reason": "Additional independently selected relays can distribute event storage and subscription work across populations, without an obligatory common coordinator. Universal replication and automatic relay discovery are not assumed; popular authors may still create hotspots.", "method": "Documentary analysis", "source_label": "Primary specification / explicit profile inference", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nostr/master/README.md" ], "editorial_references": [], "qualification": "Measure work distribution under an explicit author/reader-to-relay assignment, replication factor and skew. No linear speedup or billion-device capacity is established." }, { "id": "G04-MT", "feature": "G04", "stack": "MT", "status": "Y", "reason": "The selected forwarding work is performed by participating radio nodes; no mandatory central broker or fixed-capacity coordinator allocates all routes. Adding relays distributes forwarding work, although shared airtime can become a bottleneck. The claim is architectural, not linear throughput scaling.", "method": "Documentary and code analysis; no execution", "source_label": "Meshtastic official documentation / pinned firmware 8e6a88d", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp" ], "editorial_references": [], "qualification": "Model shared-airtime and contention limits; adding radios need not add capacity in a single collision domain." }, { "id": "G04-GN", "feature": "G04", "stack": "GN", "status": "Y", "reason": "R5N distributes lookup forwarding and replicated storage among peers. CADET endpoints and local transport services are per-peer, not one obligatory fixed-capacity coordinator. The private underlay introduces no mandatory central service; global reachability and calibrated capacity remain separate questions.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "GNUnet v0.20.x R5N discovery and routing", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/dht/dht.html" ], "editorial_references": [], "qualification": "Distribute peers and records across hosts; inventory per-peer and underlay bottlenecks and failure recovery. No scaling benchmark performed." }, { "id": "G04-ND", "feature": "G04", "stack": "ND", "status": "Y", "reason": "In the selected known-name, static-prefix Ethernet deployment, each forwarder owns its FIB, PIT, cache and strategy state. Prefix next hops can partition traffic among additional forwarders and producer locations; no central resolver or obligatory single controller participates in each retrieval. Operators still provision routes and local trust. A single producer or shared link can remain a bottleneck; global routing inventory and quantitative capacity are not established by this decision.", "method": "Architecture and pinned forwarding analysis; no execution", "source_label": "NFD 24.07 modules and prefix route management", "sources": [ "https://docs.named-data.net/NFD/24.07/overview.html", "https://docs.named-data.net/NFD/24.07/manpages/nfdc-route.html", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [], "qualification": "Provision disjoint prefix branches and multiple producers/forwarders with local routes and trust. Inspect per-node state and load, remove one branch, and check recovery and shared bottlenecks. No performance or global-scale experiment has been executed." }, { "id": "G04-AX", "feature": "G04", "stack": "AX", "status": "Y", "reason": "Each NET/ROM node maintains local routes and exchanges updates with neighbors. Additional branches and crosslinks can carry separate circuits and distribute forwarding, without a mandatory central directory or coordinator. Destination-table growth, shared radio airtime and bottleneck links still constrain this architecture. Global-table and quantitative-scale results are unchanged.", "method": "Primary protocol and pinned source analysis; no execution", "source_label": "NET/ROM routing, crosslinks and neighbor updates, pp. 4–9", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [], "qualification": "Build two independent traffic branches with multiple crosslinks; inventory local tables, shared airtime and forwarded load. Demonstrate no obligatory common controller. Do not infer linear scaling or ten-billion-node capacity." }, { "id": "G04-BA", "feature": "G04", "stack": "BA", "status": "Y", "reason": "Originator advertisements and neighbor selection run at each mesh node; client translation originates at its attachment, and TT requests can be answered by the responsible originator or a peer with suitable state. Native intra-mesh traffic does not require one central directory, controller or gateway. Added nodes/links can distribute forwarding across independent branches and client attachment work across originators. This satisfies the absence of an obligatory fixed coordination point, not arbitrary horizontal scalability: replicated originator/TT state and broadcast overhead remain, and explain the separate G01/G03 No results.", "method": "Pinned primary-source inspection and bounded configuration/topology inference; no execution", "source_label": "Linux v6.12 source; NET/ROM 1.3 manual where indicated", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_iv_ogm.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/bat_v_ogm.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/translation-table.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/routing.c" ], "editorial_references": [], "qualification": "Operate independent communicating pairs on separate mesh branches with gateway mode off; remove an unrelated originator and verify surviving branches and distributed TT response roles. Measure replication/control costs separately; no linear scaling or global capacity claim." }, { "id": "G04-BL", "feature": "G04", "stack": "BL", "status": "Y", "reason": "Each Babel speaker computes routes from neighbor advertisements; multiple routers may originate a prefix or default. Additional routers can distribute forwarding/control work without a single mandatory coordinator. Periodic-update and per-router state costs remain, and no ten-billion-node capacity is inferred.", "method": "Primary specifications and pinned-code analysis; no execution", "source_label": "Babel routing protocol, RFC 8966", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "Add routers and multiple prefix origins; inventory distributed work, update traffic and transient loops. No quantitative scale qualification." }, { "id": "G04-RI", "feature": "G04", "stack": "RI", "status": "Y", "reason": "RFC 6550 section 3.1.3 permits multiple independent DODAG roots. Separate non-storing DODAGs can partition downward route state among participant-operated roots, with ordinary IPv6 reachability between their domains. Pairwise endpoint DTLS has no mandatory central key server.", "method": "Documentary and source review; no new runtime execution", "source_label": "Primary specifications, retained implementation sources and deployment documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html#section-3.1.3" ], "editorial_references": [ "round270-sources.json" ], "qualification": "Credit multiple independent domains, not replication of one virtual root: virtual-root synchronization is not supplied by this RFC. Each non-storing root still holds its domain topology. Inter-domain routes and pairwise keys need provisioning; G01/G05 and quantitative capacity remain separate." }, { "id": "G04-HP", "feature": "G04", "stack": "HP", "status": "Y", "reason": "The selected HIP base exchange and authenticated locator updates operate between endpoint pairs. Known locators and pinned HIs eliminate a mandatory discovery or rendezvous coordinator in this composition. Additional IP routers and independent endpoint pairs can distribute forwarding and association work.", "method": "Documentary complete-profile analysis; no execution", "source_label": "Selected HIP and CCNx primary specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html#section-1.2" ], "editorial_references": [ "round269-sources.json" ], "qualification": "This architectural witness does not remove per-peer endpoint state, IP routing tables or finite router capacity. No public-name discovery, simultaneous mobility, throughput measurement or G05 global-scale conclusion is credited." }, { "id": "G04-CX", "feature": "G04", "stack": "CX", "status": "Y", "reason": "The selected locally provisioned CCNx network distributes name-prefix forwarding among forwarders, pending requests along their paths and optional caches among nodes. Separate prefixes and producers can be served by additional infrastructure without consulting a mandatory single coordinator. Numeric IPv4 adjacencies and local FIB configuration add no obligatory global coordination service.", "method": "Documentary complete-profile analysis; no execution", "source_label": "Selected HIP and CCNx primary specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html#section-1.2" ], "editorial_references": [ "round269-sources.json" ], "qualification": "This is distribution across prefixes and requests, not unlimited scaling of one hot object or automatic route provisioning. RFC 8569 describes a core forwarder knowing global routes; this Yes does not resolve G01 or G05 and does not bound FIB/PIT memory." }, { "id": "G04-LI", "feature": "G04", "stack": "LI", "status": "Y", "reason": "Mapping work can be divided by authoritative EID prefixes among Map-Servers, while multiple Map-Resolvers serve ITRs, including anycast operation. xTR forwarding and underlying IP routing are distributed. The architecture does not require one fixed-capacity global coordinator.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.1", "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.2", "https://www.rfc-editor.org/rfc/rfc9301.html#section-8.4.1", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "Capability to add prefix shards, resolvers and routers, not unlimited capacity of one hot prefix. Specify mapping-system interconnection, replication/key placement, failover and load before a deployment claim. No optional mapping-system implementation is silently selected and G05 remains Pending." }, { "id": "G04-IL", "feature": "G04", "stack": "IL", "status": "Y", "reason": "Endpoint communication state is local; Locator forwarding uses distributed IP routing. DNS discovery partitions NID/L64 data by zones and permits redundant authoritative servers and multiple caching resolvers. Additional routing and discovery infrastructure can distribute work without one obligatory fixed-capacity machine.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html#section-4.2", "https://www.rfc-editor.org/rfc/rfc6742.html", "https://www.rfc-editor.org/rfc/rfc1034.html#section-4.2", "https://www.rfc-editor.org/rfc/rfc1034.html#section-4.3.5", "https://www.rfc-editor.org/rfc/rfc4271.html" ], "editorial_references": [], "qualification": "DNS hierarchy is still an administrative dependency. Replication, delegation and caches do not guarantee unlimited update capacity for a single hot zone or fulfill the quantitative global workload. G05 remains Pending; no deployment benchmark performed." }, { "id": "G04-TS", "feature": "G04", "stack": "TS", "status": "N", "reason": "For a single tailnet, the documented managed architecture places its complete control plane on one shard, served by one Go process with an SQLite database. More shards distribute different tailnets; migration moves a tailnet between shards rather than partitioning its coordination work. Thus the selected single-tailnet network retains an obligatory coordinator capacity boundary and does not meet G04.", "method": "Primary deployed-architecture description; scoped bottleneck inference, no load test", "source_label": "Tailscale database architecture, Alex Chan, 2026-08-12", "sources": [ "https://tailscale.com/blog/sqlite-wal-reset-bug" ], "editorial_references": [ "round595.html", "round595-sources.json" ], "qualification": "Scope is one tailnet under the architecture described by Tailscale on 2026-08-12. The overall service does scale horizontally across tailnets. Migration, recovery and larger hosts remain possible; this is not a measured node ceiling, a claim that the whole service has one coordinator, or a G05 global-plausibility verdict. Existing peer traffic can continue during control-plane outages, while new discovery and updates depend on the shard. A redesigned intra-tailnet partitioning mechanism or a separately specified multi-tailnet composition would require reassessment." }, { "id": "G04-RA", "feature": "G04", "stack": "RA", "status": "Y", "reason": "RINA partitions communication into recursively composed DIF scopes. Each scope has cooperating IPC processes with routing and directory functions; IRATI distributes directory updates within each DIF and runs local IPC managers. Adding scopes and their infrastructure can distribute routing/discovery work without an obligatory single global coordinator.", "method": "Primary documentation and external-report scope inspection; no runtime test", "source_label": "RINA architecture, IRATI and external evidence review", "sources": [ "https://github.com/IRATI/stack/wiki/Software-architecture-overview", "https://csr.bu.edu/rina/about.html", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md" ], "editorial_references": [ "round662.html" ], "qualification": "Architectural Yes for scoped distribution, not a global-capacity result. The current directory is fully replicated within each DIF, so enlarging one DIF still increases replication cost. The selected local configuration does not silently acquire the optional dynamic DIF allocator. Administrative provisioning, failure recovery and quantified global workloads remain separate qualifications." }, { "id": "G05-PN", "feature": "G05", "stack": "PN", "status": "Y", "reason": "Yes is an editorial architectural-plausibility inference from complementary mechanisms, not an observed global deployment or a global resource bound. BloomRoute supplies population-sized filters, bounded nonrecursive summaries, requester-directed exploration and learned reuse. The newer production-resolver fixtures use observed full paths rather than free addressed shortcuts. With protected endpoint routes, a fixed 64 KiB persistent cache supports small recurring relationship sets; confirmed reuse costs about one contact, which can traverse multiple links. Universal concentration hints remain usable alongside selective nodes, so precision need not be uniform or a complete precise global catalog mandatory at each router. Together these provide a credible scaling route on regional/provider infrastructure. The inference accepts distributed equipment and variable selectivity within the common contemporary-resource setting; no specially favorable physical topology is substituted. It does not equate topological reachability with affordable search. Native transport is exercised through path/session fixtures, not real HS2.", "method": "Editorial synthesis of proportional and bounded-client evidence", "source_label": "BloomRoute reports pinned at 2b8ced0530e8121ee1890a056efe486361abf065", "sources": [], "editorial_references": [ "round402.html", "round391-evidence.json", "round400-common-scenario.json", "round400.html", "round401-evidence.json", "round402-evidence.json" ], "qualification": "The detailed regional/global workload and resource mapping remains unvalidated. In the 100000-endpoint, eight-relation universal/priority sample, day-ten query success is 96.88% but distinct-relation coverage is only 75%. The intensive bounded learning study also reports substantial failures. Finite budgets censor discovery; neither affordable completion nor failure solely caused by arbitrary limits has been established for every missing target. The positive is not a claim that this resolver policy meets sustained-discovery qualification. Memory and maintenance figures apply to reduced populations and declared concurrency. Static topology, three seeds and modeled packet/setup sizes do not establish global congestion, churn, cryptographic performance or SLA compliance. Track discovery-cost tails, cache behavior and regional update/state concentration as engineering qualifications. Apply this same plausibility standard to other stacks; neither absence of a proved obstruction nor connectivity alone warrants Yes." }, { "id": "G05-PI", "feature": "G05", "stack": "PI", "status": "Y", "reason": "Yes is an editorial architectural-plausibility inference from complementary mechanisms, not an observed global deployment or a global resource bound. BloomRoute supplies population-sized filters, bounded nonrecursive summaries, requester-directed exploration and learned reuse. The newer production-resolver fixtures use observed full paths rather than free addressed shortcuts. With protected endpoint routes, a fixed 64 KiB persistent cache supports small recurring relationship sets; confirmed reuse costs about one contact, which can traverse multiple links. Universal concentration hints remain usable alongside selective nodes, so precision need not be uniform or a complete precise global catalog mandatory at each router. Together these provide a credible scaling route on regional/provider infrastructure. The inference accepts distributed equipment and variable selectivity within the common contemporary-resource setting; no specially favorable physical topology is substituted. It does not equate topological reachability with affordable search. The selected IP substrate and its routing costs remain part of the composition; no integrated global PI benchmark is claimed.", "method": "Editorial synthesis of proportional and bounded-client evidence", "source_label": "BloomRoute reports pinned at 2b8ced0530e8121ee1890a056efe486361abf065", "sources": [], "editorial_references": [ "round402.html", "round391-evidence.json", "round400-common-scenario.json", "round400.html", "round401-evidence.json", "round402-evidence.json" ], "qualification": "The detailed regional/global workload and resource mapping remains unvalidated. In the 100000-endpoint, eight-relation universal/priority sample, day-ten query success is 96.88% but distinct-relation coverage is only 75%. The intensive bounded learning study also reports substantial failures. Finite budgets censor discovery; neither affordable completion nor failure solely caused by arbitrary limits has been established for every missing target. The positive is not a claim that this resolver policy meets sustained-discovery qualification. Memory and maintenance figures apply to reduced populations and declared concurrency. Static topology, three seeds and modeled packet/setup sizes do not establish global congestion, churn, cryptographic performance or SLA compliance. Track discovery-cost tails, cache behavior and regional update/state concentration as engineering qualifications. Apply this same plausibility standard to other stacks; neither absence of a proved obstruction nor connectivity alone warrants Yes." }, { "id": "G05-IP", "feature": "G05", "stack": "IP", "status": "Y", "reason": "IPv6 supplies the namespace while prefix aggregation separates inter-domain routing state from individual endpoint count. The selected BGP/MP-BGP control plane and regional/provider hierarchy provide a credible global construction; CIDR's deployment experience is documented in RFC 4632. This satisfies plausibility using the same evidentiary standard as PRP, without requiring a new ten-billion-device test. The retained plausibility inference uses conventional Internet regional/provider routing, rather than a bespoke substitute physical topology; MQ/HIP add peer-local connection/association state. It is documentary architectural evidence, not a completed paired scenario execution.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "RFC 4632 sections 3–5 and 9; RFC 4291 addressing architecture", "sources": [ "https://www.rfc-editor.org/rfc/rfc4632.html", "https://www.rfc-editor.org/rfc/rfc4291.html" ], "editorial_references": [ "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Credit applies to the selected IPv4/IPv6 composition with IPv6 for address-space growth, not ten billion unique public IPv4 addresses. Deaggregation, multihoming, churn and provisioning affect resources. No simultaneous certification of the historical numeric targets or exact current endpoint count is asserted. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-BP", "feature": "G05", "stack": "BP", "status": "?", "reason": "Further pinned ION source tracing establishes three allocation components for each new destination reached through addNode: an IonNode object, its red-black-tree entry and an initially empty embargo list. IonNode contains the destination number, embargo-list address and routing-object address. This is created before the static-exit lookup described in round417. ion.c supplies destroyIonNode and invokes it when dropVdb destroys the complete nodes tree, after routing objects are cleared. Thus a concrete teardown path exists; the inspected source does not establish bounded live eviction for exit-only destinations.", "method": "Documentary byte accounting and source-role/lifecycle analysis; no runtime or legal clearance", "source_label": "Primary RFCs and pinned implementation sources; reviewed 2026-10-22", "sources": [ "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/library/rfx.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/include/ion.h", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/library/ion.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/library/smrbt.c", "https://raw.githubusercontent.com/nasa-jpl/ION-DTN/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/library/smlist.c" ], "editorial_references": [ "round418.html#G05-BP", "round417.html", "round418-sources.json", "round418-budget.json" ], "qualification": "Still Pending. Inventory allocator, tree, list and lock overhead on the selected ABI rather than equating sizeof(IonNode) with total memory. Search remaining call sites for live reclamation or a supported bounded-routing configuration. Derive the distinct-destination working set per regional gateway from the common workload; 1000 accesses/day/device is not 1000 new destinations and does not force each gateway to see the entire population. Quantify gateway distribution, lookup work, queue and key state. A shutdown cleanup is not online eviction; failure of this ION witness is not an impossibility proof for BPv7. No runtime or whole-repository lifecycle audit performed." }, { "id": "G05-CG", "feature": "G05", "stack": "CG", "status": "N", "reason": "No for the selected private-ipn singleton deployment. RFC 9758 reserves node numbers 1 through 0x3FFF for private use: at most 16383 distinct bundle nodes in one such domain. Private source/destination EIDs cannot cross administrative domains. Reusing that range in disconnected domains does not supply the connected ten-billion-device witness. Additional service numbers distinguish services on a node, not new independently identified nodes.", "method": "Documentary necessary-condition bound; no execution", "source_label": "RFC 9758 sections 3.4.3, 3.5, 5.5, 5.7 and 9.2", "sources": [ "https://www.rfc-editor.org/rfc/rfc9758.html" ], "editorial_references": [ "round409.html", "round409-bound.json" ], "qualification": "This is a selected-profile namespace obstruction, not a claim that BPv7, CGR/SABR or LTP is intrinsically unable to scale globally. Global allocator identifiers, another endpoint naming scheme or a translating gateway composition require an explicit global profile and renewed analysis of routing, discovery, security bindings and resources. They are not silently added here. No performance experiment, hardware failure or global impossibility theorem is asserted. The private deployment remains useful and its other capabilities remain credited. The BP column also selects dtn collective names; its separate G05 question is not decided by this singleton-profile bound." }, { "id": "G05-LT", "feature": "G05", "stack": "LT", "status": "N", "reason": "No for the selected private-ipn singleton deployment. RFC 9758 reserves node numbers 1 through 0x3FFF for private use: at most 16383 distinct bundle nodes in one such domain. Private source/destination EIDs cannot cross administrative domains. Reusing that range in disconnected domains does not supply the connected ten-billion-device witness. Additional service numbers distinguish services on a node, not new independently identified nodes.", "method": "Documentary necessary-condition bound; no execution", "source_label": "RFC 9758 sections 3.4.3, 3.5, 5.5, 5.7 and 9.2", "sources": [ "https://www.rfc-editor.org/rfc/rfc9758.html" ], "editorial_references": [ "round409.html", "round409-bound.json" ], "qualification": "This is a selected-profile namespace obstruction, not a claim that BPv7, CGR/SABR or LTP is intrinsically unable to scale globally. Global allocator identifiers, another endpoint naming scheme or a translating gateway composition require an explicit global profile and renewed analysis of routing, discovery, security bindings and resources. They are not silently added here. No performance experiment, hardware failure or global impossibility theorem is asserted. The private deployment remains useful and its other capabilities remain credited. The BP column also selects dtn collective names; its separate G05 question is not decided by this singleton-profile bound." }, { "id": "G05-LP", "feature": "G05", "stack": "LP", "status": "N", "reason": "No for the selected IPv4/UDP/QUIC/libp2p composition, which explicitly excludes NAT. One connected, conventionally routed IPv4 namespace has at most 2^32 address values, fewer than the reference ten billion devices even before reserved ranges. Peer IDs and UDP ports distinguish peers or services but do not provide routable addresses for additional independently attached devices. Reusing private addresses in disconnected domains does not connect those domains. The selected direct numeric-peer composition contains no translating gateway or relay/addressing layer that removes this obstruction.", "method": "Selected-profile namespace and source-based resource bounds; no runtime experiment", "source_label": "RFC 791 section 3.1; existing LP selected-profile IPv4 and no-NAT binding", "sources": [ "https://www.rfc-editor.org/rfc/rfc791.html", "https://www.rfc-editor.org/rfc/rfc9000.html" ], "editorial_references": [ "round400-common-scenario.json", "round438-sources.json", "round438-bounds.json" ], "qualification": "This is a necessary-condition result for the currently selected global IPv4 profile, not a limitation of libp2p Peer IDs, QUIC or every libp2p deployment. IPv6 is a legitimate alternative but has not been silently substituted. An explicitly adopted IPv6 global witness would reopen this cell and require its routing/state argument, as already done separately for IP and Multipath QUIC. Multiple processes sharing one host address do not turn that host into multiple independently attached devices. No runtime or global performance claim." }, { "id": "G05-TO", "feature": "G05", "stack": "TO", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Owner-approved G05 limits and existing stack-specific evidence", "sources": [], "editorial_references": [ "round171.html", "round160-protocol.json", "round136-scale-plan.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-I2", "feature": "G05", "stack": "I2", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Owner-approved G05 limits and existing stack-specific evidence", "sources": [], "editorial_references": [ "round171.html", "round160-protocol.json", "round136-scale-plan.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-YG", "feature": "G05", "stack": "YG", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Owner-approved G05 limits and existing stack-specific evidence", "sources": [], "editorial_references": [ "round171.html", "round160-protocol.json", "round136-scale-plan.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-CJ", "feature": "G05", "stack": "CJ", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Owner-approved G05 limits and existing stack-specific evidence", "sources": [], "editorial_references": [ "round171.html", "round160-protocol.json", "round136-scale-plan.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-MQ", "feature": "G05", "stack": "MQ", "status": "Y", "reason": "The global witness now explicitly uses IPv6 with conventional BGP/MP-BGP prefix routing. Its 128-bit namespace accommodates the reference population; regional/provider prefix aggregation avoids requiring one global route per device. QUIC connection and validated-path state is held by communicating peers. Known numeric peer locators are already part of this selected composition: delivery does not require network-wide identity search or a mandatory global peer catalog. Bounded peer working sets and a bounded number of paths allow participants and their state to be distributed across ordinary regional networks. Together these provide an architectural plausibility witness under G05, extending the same aggregated IPv6 underlay rationale used for IP. The retained plausibility inference uses conventional Internet regional/provider routing, rather than a bespoke substitute physical topology; MQ/HIP add peer-local connection/association state. It is documentary architectural evidence, not a completed paired scenario execution.", "method": "Architectural plausibility inference for explicitly selected IPv6 composition", "source_label": "IPv6 addressing, multiprotocol BGP and peer-local protocol state", "sources": [ "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round393.html", "round400-common-scenario.json", "round400.html" ], "qualification": "This is an editorial plausibility inference, not a measured 10-billion-device deployment or a guarantee of the historical latency, memory and traffic sizing targets. It assumes aggregatable allocations and distributed demand, not arbitrary global deaggregation or all-to-all simultaneous sessions. Initial locators/trust are supplied as selected; arbitrary identity-to-locator discovery is not added. Historical IPv4 runtime and byte-budget evidence remains IPv4-only; no new IPv6 implementation test is claimed. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-SC", "feature": "G05", "stack": "SC", "status": "Y", "reason": "Editorial plausibility inference: SCION addresses combine ISD, AS and an AS-local host address. Reusing IPv4 host addresses in different ASes does not collide in that namespace. Its control plane discovers and registers selected AS path segments; endpoints combine segments, and packets carry forwarding paths. Regional ISDs separate intra-domain and core discovery. Thus growing the host population within regional ASes does not require one inter-domain route or beacon per host. The selected IPv4/UDP underlay can connect border services while endpoint addresses remain AS-local. A distributed path-service deployment and bounded selected path sets provide a credible scaling route on existing regional interconnections.", "method": "Primary documentary review and conditional architectural sizing", "source_label": "SCION official overview, control-plane architecture and address/path header", "sources": [ "https://docs.scion.org/en/latest/overview.html", "https://docs.scion.org/en/latest/control-plane.html", "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round408.html", "round408-sizing.json", "round400-common-scenario.json" ], "qualification": "Architectural inference, not a measured global deployment or implementation qualification. Use the common physical regional infrastructure and workload; no extra inter-region links or favorable substitute topology are assumed. The sizing examples are explicit planning assumptions, not measured record sizes, cache-hit rates or throughput. Place additional service capacity inside existing regional sites and charge its memory, replication and traffic. Arbitrary deaggregation, all-to-all simultaneous sessions, pathological churn and exhaustive path retention are not the witness. Actual skew, control traffic, certificate/DNS updates, CPU, failures and link provisioning need engineering sizing. The historical latency and memory references are not jointly certified. Existing implementation, independent-evidence and security cells are unchanged." }, { "id": "G05-RT", "feature": "G05", "stack": "RT", "status": "Y", "reason": "Yes is an editorial architectural-plausibility inference under the same complementary-evidence standard used for PRP, not a measured global deployment. Native Reticulum 1.5.5 fixtures establish scoped regional catalogs, recursive lookup stopping at catalog gateways, exact replies and reusable learned core paths. The new shared-catalog fixture passed 24 lookup/delivery cases: two independent origin cores use the same catalog shards without cross-bank request leakage or a complete catalog replica per origin bank. Unknown queries fan out across catalog gateways, not all endpoints; known core paths avoid that fanout. Combined with origin working-set sizing and explicit shard/refresh/load sensitivities, this supplies a credible distributed-state scaling route. Additional service paths or replicas are charged as capacity needs rather than assumed free. A native target-directed regional index is not required when bounded gateway fanout can be provisioned. The selected serial/IFAC composition is retained; no IP backbone, application DHT or Bloom extension is added.", "method": "Editorial synthesis of native shared catalogs and conditional resource sizing", "source_label": "Reticulum 1.5.5 native fixtures and explicit resource model", "sources": [ "https://reticulum.network/manual/interfaces.html", "https://reticulum.network/manual/understanding.html", "https://ftdichip.com/products/ft232hl/" ], "editorial_references": [ "round407.html", "round398-regional-evidence.json", "round398.html", "round161-scope.json", "round162-regions.json", "round163-cached-regions.json", "round164-announces.json", "round400-common-scenario.json", "round400.html", "round403-costs.json", "round404-working-sets.json", "round404.html", "round405-native.json", "probe_reticulum_sharded_regions.py", "round406-provisioning.json", "round407-native.json", "round407-sizing.json", "probe_reticulum_shared_catalogs.py" ], "qualification": "This is an editorial inference, not certification or a claim that the native fixture authors measured global capacity. The analytical example assumes small recurring relationships and 0.2 additional unresolved interests/device/day; 1000 daily accesses are not converted automatically into that miss rate. The intensive workload remains an unresolved sensitivity. The faster UART hardware specification does not establish driver compatibility, long-haul links or end-to-end RNS throughput. Service-path counts are optimistic inverse-budget estimates, not executed hardware inventories. Catalog placement, physical regional embedding, intermediate learned state, expiry, announcements, retries, crypto CPU, congestion and burst demand remain engineering qualifications. A small graph is mechanism evidence only. No full shared-topology simulation, global resource bound or guarantee of discovery latency/coverage is claimed. Keep the earlier adverse and intensive cases; reassess if a concrete common-setting obstruction is established." }, { "id": "G05-NS", "feature": "G05", "stack": "NS", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Owner-approved G05 limits and existing stack-specific evidence", "sources": [], "editorial_references": [ "round171.html", "round160-protocol.json", "round136-scale-plan.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-MT", "feature": "G05", "stack": "MT", "status": "N", "reason": "The retained No follows from the previously inspected selected standalone LoRa mesh's 32-bit NodeNum destination/key-selection namespace: even all 2^32 labels cannot identify 10 billion independently keyed, globally addressable endpoints. Disconnected meshes reusing labels do not satisfy the connected-network target. This necessary-condition obstruction survives the plausibility standard; no global benchmark is required. Added gateways or a collision-disambiguating hierarchy would change the selected profile.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Meshtastic NodeNum, destination fields, authoritative key stores and PKI send path", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/generated/meshtastic/mesh.pb.h", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NodeDB.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/WarmNodeStore.h" ], "editorial_references": [ "round171.html", "round136-sources.json", "round136.html", "round160.html", "round160-protocol.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "No radio/load experiment was executed. This bound is specific to the selected single native routing namespace and ordinary independently keyed endpoints. Reopen if a concrete native hierarchy or collision-disambiguating destination/key-selection mechanism is added to the selected profile. Local disconnected deployments and application-managed key replacement do not establish that mechanism. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-GN", "feature": "G05", "stack": "GN", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Owner-approved G05 limits and existing stack-specific evidence", "sources": [], "editorial_references": [ "round171.html", "round160-protocol.json", "round136-scale-plan.json", "round171-protocol.json", "round171-regions.tsv", "round171-sources.tsv", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-ND", "feature": "G05", "stack": "ND", "status": "?", "reason": "The retained G01 construction uses NFD 24.07 multicast v5 over a tree, with / listing all neighboring faces and only local producer registrations. Its source forwards a new Interest to every eligible next hop. For distinct globally scoped names absent from caches and pending state, with leaf producers, this floods each tree edge once. Thus a leaf interface receives requests originated by all other leaves, even when it is not their destination. At ten billion active leaves and 1000 fresh requests per leaf/day, this is about 115.74 million incoming Interests/second per leaf. Counting only four bytes per Interest already gives 3.70 Gbit/s, before names, other fields, framing or Data. This is a conditional lower bound for that construction and workload, not a measured NFD rate.", "method": "Pinned forwarding semantics and conditional traffic lower bound; no runtime measurement", "source_label": "NFD 24.07 multicast v5; existing G01 witness; common workload arithmetic", "sources": [ "https://docs.named-data.net/NFD/24.07/doxygen/multicast-strategy_8cpp_source.html" ], "editorial_references": [ "round441.html", "round135-sources.json", "round400-common-scenario.json", "round441-bounds.json" ], "qualification": "G05-ND remains Pending: this defeats using the existing flooding witness alone as a capacity argument, not every NDN routing policy. Fresh names and unsatisfied distinct requests specify the no-hit case rather than assigning an arbitrary average cache-hit rate. The common workload includes long-tail/churn sensitivity; the calculation is not a claim that all real traffic always misses caches. A positive witness needs selective prefix routing or another documented strategy on the same regional graph, with forwarding-state, update and placement costs. No new directory, NLSR, IP underlay or physical links are silently introduced. G01 reachability remains Yes. No daemon, global experiment or E04 measurement is claimed." }, { "id": "G05-AX", "feature": "G05", "stack": "AX", "status": "N", "reason": "No for the selected Linux 6.12 classic NET/ROM with active netromd and direct KISS links. nr_node_get compares exact callsigns in a linked list; nr_route_frame drops a nonlocal packet when that exact destination has no route. There is no prefix/default-route fallback in this path. netromd transmits individual eligible node records and installs received records, rather than aggregating regional destinations or performing demand-driven global discovery. Full destination reachability therefore requires a near-global destination catalog at an access forwarder; adding regional forwarders does not partition that access catalog. For ten billion native destination nodes, the selected struct fields alone consume at least 340 GB with 32-bit pointers or 460 GB with 64-bit pointers, before list links, locks, references, alignment and neighbor objects. A complete NODES advertisement contains at least 210 GB of destination records per advertising port before framing. Exact linked-list lookup adds linear search work. These replicated-state/control costs obstruct the common contemporary regional deployment, independently of radio speed.", "method": "Selected-profile namespace and source-based resource bounds; no runtime experiment", "source_label": "Linux v6.12 nr_route.c and netrom.h; ax25-tools 0.0.10-rc5+git20230513+d3e6d4f netromr.c/netromt.c", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/net/netrom/nr_route.c", "https://github.com/torvalds/linux/blob/v6.12/include/net/netrom.h" ], "editorial_references": [ "round438.html", "round426-sources.json", "round400-common-scenario.json", "round438-sources.json", "round438-bounds.json" ], "qualification": "Architectural/source-based plausibility decision, not an allocation, latency or global throughput benchmark. Bounds count independently addressed native NET/ROM destination nodes, not application users behind a shared node. A BBS/proxy or another hierarchical network layer would change this selected end-to-end service. Quality/obsolescence filters can reduce the catalog by removing reachability; they are not aggregation or a lookup service for omitted destinations. No all-to-all simultaneous traffic is assumed: the missing-route path and proactive catalog are independent of the 1000 destinations/day working set. The common physical regional graph is unchanged. The 64-GB reference is not promoted to a universal hardware ceiling; widespread unpartitioned state and repeated advertisements underpin the decision. Local amateur-radio use remains outside this global-capacity finding." }, { "id": "G05-BA", "feature": "G05", "stack": "BA", "status": "N", "reason": "The selected Linux 6.12 native BATMAN_IV mesh lacks a credible global-state partition for the common ten-billion-device setting. Source Ethernet traffic registers/refreshes each attached client in the local translation table; the default inactivity timeout is 600 seconds. A smooth schedule of 1000 accesses per device per day, spaced 86.4 seconds apart with staggered phases, keeps clients active without burst pressure. Remote translation changes are synchronized through OGMs and table requests, independently of local destination demand. The 64-bit field-only lower bound from round431 is 54 bytes per represented remote client: a near-global replica costs approximately 540 GB before padding, originator lists and other state. This state is repeated at mesh forwarders, including access equipment, rather than partitioned by region or the 1000 destinations each client uses. Adding ordinary mesh forwarders does not shard the remote table. The local table-size guard rejects new clients whose table would exceed the supported response size; it is not a global aggregation mechanism. Together these are an architectural/resource obstruction for this selected native deployment on the common contemporary equipment envelope.", "method": "Architecture/state-lifetime trace and conservative memory accounting; no runtime benchmark", "source_label": "Pinned Linux 6.12 source and common population/workload; reviewed 2026-10-22", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/translation-table.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/soft-interface.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/main.h", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/types.h" ], "editorial_references": [ "round432.html", "round432-sources.json", "round432-model.json", "round431-model.json", "round400-common-scenario.json" ], "qualification": "Source-based plausibility verdict, not a measured global benchmark or a claim that batman-adv is unsuitable for local meshes. The evenly spaced schedule is an explicit ordinary-use realization of the shared daily workload, not an observed Internet trace or a new mandatory timing rule. The memory bound applies to concurrently represented remote attached clients; local clients are subtracted. It does not multiply identities owned by daily destinations. Moving devices into mesh-originator roles also requires per-originator reachability state (G01-BA), rather than eliminating global state. Bridge-loop avoidance suppresses duplicate backbone advertisements; it is not a selected inter-region namespace partition. Gateway mode is off and an IP hierarchy, NAT or another inter-mesh routing layer would change the selected stack. The 64-GB figure remains a sizing reference: the finding is widespread replicated state, not failure of a newly imposed simultaneous benchmark threshold. No allocation stress, packet loss, throughput or CPU measurement was run." }, { "id": "G05-BL", "feature": "G05", "stack": "BL", "status": "?", "reason": "The existing G01 witness bounds prefix state using a provisioned binary hierarchy and exact interface/prefix filters. RFC 8966 Appendix C supports filtering; it does not supply a global deployment. The retained 31-router model tests converged forwarding only. Extending a balanced single-root hierarchy has a distinct traffic-concentration cost: with ten billion devices initiating 1000 distinct uniformly distributed remote contacts/day, approximately half of contacts cross the two root subtrees. That is about 57.87 million root-crossing contacts/second before responses or multi-packet transfers. This conditional average is neither an observed load nor a protocol-wide impossibility bound. Small routing tables alone therefore do not complete this global witness.", "method": "Documentary review and conditional cut-load calculation; no global deployment proof", "source_label": "RFC 8966 Appendix C; retained round139 witness; conditional traffic arithmetic", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-C" ], "editorial_references": [ "round440.html", "round139-model-result.json", "round400-common-scenario.json", "round440-bounds.json" ], "qualification": "G05-BL remains Pending. Bind the selected hierarchy to the common regional physical graph and account for root/cut capacity, path stretch, equipment placement and prefix allocation. A parallelized or multi-root construction must explain its forwarding/filter changes and resource costs on existing regional links. The uniform long-tail scenario is a sensitivity case, not an assumed universal workload. No new links, favorable replacement physical tree, or uncharged root cluster may be assumed. No daemon or global throughput benchmark was executed; G01-BL remains Yes." }, { "id": "G05-RI", "feature": "G05", "stack": "RI", "status": "?", "reason": "The common G05 standard is now architectural plausibility, not simultaneous quantitative qualification. The existing record for this composition has not yet been individually reassessed for a sufficient positive scaling argument or a concrete obstruction. Pending denotes that evidence task, not a requirement to deploy or simulate the whole world.", "method": "Architectural plausibility assessment using documented evidence", "source_label": "Primary standards for the declared composition; no new implementation qualification", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc4944.html", "https://www.rfc-editor.org/rfc/rfc6282.html", "https://www.rfc-editor.org/rfc/rfc8200.html", "https://www.rfc-editor.org/rfc/rfc6552.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc6775.html", "https://www.rfc-editor.org/rfc/rfc768.html", "https://www.rfc-editor.org/rfc/rfc9147.html", "https://www.rfc-editor.org/rfc/rfc8446.html" ], "editorial_references": [ "round244.html#iot-rpl", "round391.html", "round400-common-scenario.json", "round400.html" ], "qualification": "Identify the selected stack's scaling mechanism and likely bottlenecks; use available models, proportional experiments or deployment evidence. Explain extrapolation assumptions and contemporary resource requirements. Do not demand global deployment, full-scale simulation or simultaneous measured compliance with all historical sizing targets. Apply this same standard to every column. Preserve this column's selected composition. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-HP", "feature": "G05", "stack": "HP", "status": "Y", "reason": "The global witness now explicitly uses IPv6 with conventional BGP/MP-BGP prefix routing. Its 128-bit namespace accommodates the reference population; regional/provider prefix aggregation avoids requiring one global route per device. HIP associations and ESP security associations are held by communicating hosts. Known numeric peer locators are already part of this selected composition: delivery does not require network-wide identity search or a mandatory global peer catalog. Bounded peer working sets and a bounded number of paths allow participants and their state to be distributed across ordinary regional networks. Together these provide an architectural plausibility witness under G05, extending the same aggregated IPv6 underlay rationale used for IP. The retained plausibility inference uses conventional Internet regional/provider routing, rather than a bespoke substitute physical topology; MQ/HIP add peer-local connection/association state. It is documentary architectural evidence, not a completed paired scenario execution.", "method": "Architectural plausibility inference for explicitly selected IPv6 composition", "source_label": "IPv6 addressing, multiprotocol BGP and peer-local protocol state", "sources": [ "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html", "https://www.rfc-editor.org/rfc/rfc9000.html", "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round393.html", "round400-common-scenario.json", "round400.html" ], "qualification": "This is an editorial plausibility inference, not a measured 10-billion-device deployment or a guarantee of the historical latency, memory and traffic sizing targets. It assumes aggregatable allocations and distributed demand, not arbitrary global deaggregation or all-to-all simultaneous sessions. Initial locators/trust are supplied as selected; arbitrary identity-to-locator discovery is not added. Historical IPv4 runtime and byte-budget evidence remains IPv4-only; no new IPv6 implementation test is claimed. Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending." }, { "id": "G05-CX", "feature": "G05", "stack": "CX", "status": "?", "reason": "RFC 8569 supports hierarchical longest-prefix forwarding and a pending Interest table. This separates two scaling costs: aggregate producer prefix routes and outstanding request state, rather than a mandatory entry for every content name ever accessed. A candidate placement-aligned hierarchy can use the selected static FIB configuration and known names; it does not supply automatic global content discovery. The shared workload implies about 115.74 million originating accesses/second globally when spread evenly over a day. Pending-state accounting is per traversed forwarder: arrival rate multiplied by residence time and bytes/entry. At one million Interests/second, four seconds and an assumed 512 bytes per entry, it is 2.048 GB, excluding other state. Neither this illustrative rate nor the entry-size assumption is an executed implementation measurement. The pinned Athena candidate adds concrete qualifications to the round433 request-state model. athena.c creates the default PIT with capacity 100000. New-key admission checks entryTable size and invokes expired-entry purging only when that capacity has been reached. Thus expiration is not an independently scheduled reclamation event in this PIT source. A matched response removes the matched key from the hash, timeout and link-cleanup indexes. An Interest with a ContentObjectHashRestriction can add a second, nameless entry after the one capacity check. The threshold therefore is not a strict 100000-record allocation bound: with 99999 existing keys, a new named and distinct nameless key can bring the table to 100001. Each entry has six pointers plus separately owned message, key, bit-vector, timestamp and indexing objects. Six pointers are not the total entry memory footprint.", "method": "Source lifecycle/admission trace; analytical boundary cases, no execution", "source_label": "RFC-based round433 model and pinned Athena f89da532 source", "sources": [ "https://www.rfc-editor.org/rfc/rfc8609.html", "https://www.rfc-editor.org/rfc/rfc8569.html", "https://github.com/PARC/Athena/blob/f89da532c8690af88dfb81e708007022833625ca/ccnx/forwarder/athena/athena_PIT.c" ], "editorial_references": [ "round434.html", "round245.html", "round391.html", "round400-common-scenario.json", "round400.html", "round433-model.json", "round433-sources.json", "round434-sources.json", "round434-model.json" ], "qualification": "Keep G05-CX Pending. The rate-times-residence model remains an abstract active-request estimate; this candidate additionally requires index multiplicity, lazy reclamation, admission and heap allocation accounting. The 100001 case is a source-derived boundary calculation, not a reproduced fault, exploit or unbounded-memory claim. Distinct hash keys and spare allocation capacity are assumptions. No claim that this historical Athena revision implements the selected ECDSA profile completely: E03-CX remains independently Pending. No runtime capacity, global placement, cryptographic throughput or legitimate-service-under-attack result is inferred. These implementation details are not mandatory properties of all CCNx forwarders." }, { "id": "G05-LI", "feature": "G05", "stack": "LI", "status": "N", "reason": "No for the selected inner-IPv4 LISP composition. RFC 9300 defines an IPv4 EID as a 32-bit host identifier: at most 2^32 distinct EIDs in a connected address space, below ten billion devices. Multiple RLOCs change reachability to an EID rather than enlarge its namespace. Instance IDs permit overlapping isolated spaces, but section 8 requires source and destination EIDs to belong to the same Instance ID. Merely multiplying isolated instances therefore does not supply the connected common scenario; no inter-instance translating service is selected.", "method": "Selected-profile namespace and source-based resource bounds; no runtime experiment", "source_label": "RFC 9300 sections 3 (EID), 5 (address-family combinations) and 8 (Instance IDs)", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [ "round400-common-scenario.json", "round438-sources.json", "round438-bounds.json" ], "qualification": "The bound is on the selected inner IPv4 profile, not on LISP generally. RFC 9300 explicitly supports IPv6 EIDs, including IPv6-in-IPv4; choosing that global composition would remove this particular bound and require a fresh mapping/routing plausibility assessment. No requirement for one RLOC per endpoint is assumed. Mapping-cache distribution cannot repair insufficient EID namespace by itself. No profile, implementation or security verdict is changed." }, { "id": "G05-IL", "feature": "G05", "stack": "IL", "status": "Y", "reason": "Editorial plausibility inference: ILNPv6 forwards on aggregatable 64-bit Locators using IPv6 routing, while Identifier/Locator communication state belongs to active correspondents. DNS NID/L64 records distribute discovery through existing delegated authorities and caches. The namespace therefore does not require ten billion globally advertised host routes or a complete host directory in every router. Regional provider aggregation, distributed DNS service and finite peer working sets supply a credible route to the common population. This credits the selected TCP composition, without adding multipath transport, authentication or an overlay directory.", "method": "Primary documentary review and conditional architectural sizing", "source_label": "RFC 6740 sections 3.2 and 4.2–4.4; RFC 6741 host state; RFC 6742 NID/L64 and deployment; RFC 6743 updates", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6742.html", "https://www.rfc-editor.org/rfc/rfc6743.html" ], "editorial_references": [ "round408.html", "round408-sizing.json", "round400-common-scenario.json" ], "qualification": "Architectural inference, not a measured global deployment or implementation qualification. Use the common physical regional infrastructure and workload; no extra inter-region links or favorable substitute topology are assumed. The sizing examples are explicit planning assumptions, not measured record sizes, cache-hit rates or throughput. Place additional service capacity inside existing regional sites and charge its memory, replication and traffic. Arbitrary deaggregation, all-to-all simultaneous sessions, pathological churn and exhaustive path retention are not the witness. Actual skew, control traffic, certificate/DNS updates, CPU, failures and link provisioning need engineering sizing. The historical latency and memory references are not jointly certified. Existing implementation, independent-evidence and security cells are unchanged." }, { "id": "G05-TS", "feature": "G05", "stack": "TS", "status": "?", "reason": "G05 admits a connected multi-tailnet composition; one global tailnet is not required. Documented sharing gives access to selected resources through explicit bilateral policy or individual invitations. Connectivity of the sharing graph alone does not establish transitive endpoint reachability. Current declarative-sharing alpha limits (three external tailnets, 500 nodes each) constrain that mechanism, but neither define a permanent architectural ceiling nor exclude link-based sharing. The service-wide million-node observation lacks a per-tailnet hardware/resource curve. Conditional sizing separates daily accesses from newly created relationships; without locality, retention and update-fanout evidence, neither all-accesses-are-control-requests nor an assumed cache-hit rate is justified. A contemporary global placement remains unestablished, so G05 stays Pending.", "method": "Official sharing semantics and reproducible conditional arithmetic; verdict unchanged", "source_label": "Tailscale sharing documentation and service architecture; explicit sensitivity model", "sources": [ "https://tailscale.com/docs/features/declarative-node-sharing", "https://tailscale.com/docs/features/sharing", "https://tailscale.com/blog/hypergrowth-isnt-always-easy" ], "editorial_references": [ "round603.html", "round603-sources.json", "tailscale-scale-sizing.json" ], "qualification": "Model one connected network using either one tailnet or interconnected tailnets, retaining managed coordination, Tailnet Lock and the common regional physical infrastructure. Cover state placement, direct cross-tailnet reachability, popular destinations and update fanout. Do not infer transitive routing from sharing, count tailnets as physical servers, require all possible pairs simultaneously, or assume every daily access creates a new relationship. The sizing artifact is conditional arithmetic, not a runtime result or capacity verdict. IPv6-only operation remains admissible; no denial based on the IPv4 /10 or centralization alone." }, { "id": "G05-RA", "feature": "G05", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Use the same Internet-shaped regional infrastructure, population, access workload and contemporary equipment envelope for every composition. Protocol-specific routing, discovery, caching and placement policies may differ on that infrastructure. Do not substitute a more favorable physical topology, omit regions, silently add links or assume an independently chosen cache-hit rate. Count additional equipment and its placement explicitly under the same resource envelope. An evidenced inability to serve this common setting can justify No; impossibility in every imaginable topology is not required. Missing evidence remains Pending. Documentary or bounded analytical evidence can suffice; no global simulation is required. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "E01-PN", "feature": "E01", "stack": "PN", "status": "N", "reason": "On 2026-10-16 the PRP owner explicitly confirmed that no independent interoperable implementation exists. E01 is therefore No for the selected PRP profile at this date, rather than Pending on an inconclusive public search.", "method": "Owner-confirmed implementation availability", "source_label": "Direct PRP owner declaration, editorial conversation, 2026-10-16", "sources": [], "editorial_references": [ "round358-review.json", "round358-review.json" ], "qualification": "Dated owner declaration about implementation maturity, not a protocol limitation or failed interoperability test. Reassess when an independently developed implementation exchanges traffic in a publicly documented test, crediting only the tested functions. This statement does not decide E05 independent operation and is not an independent audit." }, { "id": "E01-PI", "feature": "E01", "stack": "PI", "status": "N", "reason": "On 2026-10-16 the PRP owner explicitly confirmed that no independent interoperable implementation exists. E01 is therefore No for the selected PRP profile at this date, rather than Pending on an inconclusive public search.", "method": "Owner-confirmed implementation availability", "source_label": "Direct PRP owner declaration, editorial conversation, 2026-10-16", "sources": [], "editorial_references": [ "round358-review.json", "round358-review.json" ], "qualification": "Dated owner declaration about implementation maturity, not a protocol limitation or failed interoperability test. Reassess when an independently developed implementation exchanges traffic in a publicly documented test, crediting only the tested functions. This statement does not decide E05 independent operation and is not an independent audit." }, { "id": "E01-IP", "feature": "E01", "stack": "IP", "status": "Y", "reason": "The public June 2007 Moonv6 report records successful native IPv6 on-link and off-link communication in a multi-vendor network. Figure 3 identifies Linux, Windows Vista/Server 2008 and Mac endpoints; the printing section reports successful transfers to three printer vendors. These are distinct implementation families exchanging IPv6 traffic, rather than two instances of one codebase. Credit the demonstrated base IPv6 interoperability.", "method": "Primary documentary evidence review; no new protocol execution", "source_label": "Evidence checked 2026-10-15; versions and hashes in round234-sources.json", "sources": [ "https://www.iol.unh.edu/sites/default/files/knowledgebase/ipv6/Moonv6June07.pdf" ], "editorial_references": [ "round234-sources.json" ], "qualification": "The application demonstrations use TCP above IPv6; only their necessary underlying IPv6 exchange is credited here, not TCP as part of the selected IP stack. Exact Linux/Mac builds and packet captures are not supplied. This historical report does not certify every current extension, per-packet route rotation, PIM, BGP, privacy policy or the complete selected deployment. The separate SHIM6 experiment is not credited as plain-IP mobility." }, { "id": "E01-BP", "feature": "E01", "stack": "BP", "status": "Y", "reason": "The Hardy public interoperability record reports BPv7 echo exchange with NASA HDTN v2.0.0: the retained results dated 2026-07-07 identify Hardy v0.2.0 and 100/100 returned pings for HDTN. The test documentation describes requests and responses in both initiation directions over TCPCLv4; its implementation overview marks the HDTN test Passing. Hardy supplies a native Rust BPv7 parser/builder and BPA, while the Docker recipe builds unmodified NASA HDTN from its v2.0.0 source tag. These are separately developed BP implementations, not wrappers of one BP engine. Under E01 bounded-function credit, this establishes public reported interoperability for the BPv7 bundle exchange common to this column.", "method": "Documentary interoperability report review; only common BPv7 exchange credited", "source_label": "Public Hardy/HDTN test report, pinned test configuration and separately implemented BPv7 source paths", "sources": [ "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/interop_results.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/README.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/README.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/test_hdtn_ping.sh", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/docker/Dockerfile", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/run_all.sh", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/bpv7/src/lib.rs", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/bpv7/Cargo.toml" ], "editorial_references": [ "round342-sources.json", "round342-review.json" ], "qualification": "Credit is restricted to BPv7 bundle exchange. TLS is explicitly disabled in the HDTN test, and the echo configuration supplies no evidence of BIB-HMAC-SHA2/BCB-AES-GCM policy interoperability. No complete secure DTN composition is qualified. The source snapshot pins the report and current harness, not every byte of the historical run: the report names Hardy v0.2.0 but the retained repository has later changes. No packet captures or full historical logs were inspected, and no test was rerun here. The summary runner tolerates test-script errors and extracts RTT statistics; its 100/100 row alone is not proof that every test phase passed. The separate public Passing statement is attributed to the implementer. No E04 independent performance qualification, security audit, complete-stack implementation qualification or production-operation claim follows." }, { "id": "E01-CG", "feature": "E01", "stack": "CG", "status": "Y", "reason": "The Hardy public interoperability record reports BPv7 echo exchange with NASA HDTN v2.0.0: the retained results dated 2026-07-07 identify Hardy v0.2.0 and 100/100 returned pings for HDTN. The test documentation describes requests and responses in both initiation directions over TCPCLv4; its implementation overview marks the HDTN test Passing. Hardy supplies a native Rust BPv7 parser/builder and BPA, while the Docker recipe builds unmodified NASA HDTN from its v2.0.0 source tag. These are separately developed BP implementations, not wrappers of one BP engine. Under E01 bounded-function credit, this establishes public reported interoperability for the BPv7 bundle exchange common to this column.", "method": "Documentary interoperability report review; only common BPv7 exchange credited", "source_label": "Public Hardy/HDTN test report, pinned test configuration and separately implemented BPv7 source paths", "sources": [ "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/interop_results.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/README.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/README.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/test_hdtn_ping.sh", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/docker/Dockerfile", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/run_all.sh", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/bpv7/src/lib.rs", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/bpv7/Cargo.toml" ], "editorial_references": [ "round342-sources.json", "round342-review.json" ], "qualification": "Credit is restricted to BPv7 bundle exchange. TLS is explicitly disabled in the HDTN test, and the echo configuration supplies no evidence of BIB-HMAC-SHA2/BCB-AES-GCM policy interoperability. No CGR/SABR contact-plan routing, mobility or route-selection interoperability is qualified. The source snapshot pins the report and current harness, not every byte of the historical run: the report names Hardy v0.2.0 but the retained repository has later changes. No packet captures or full historical logs were inspected, and no test was rerun here. The summary runner tolerates test-script errors and extracts RTT statistics; its 100/100 row alone is not proof that every test phase passed. The separate public Passing statement is attributed to the implementer. No E04 independent performance qualification, security audit, complete-stack implementation qualification or production-operation claim follows." }, { "id": "E01-LT", "feature": "E01", "stack": "LT", "status": "Y", "reason": "The Hardy public interoperability record reports BPv7 echo exchange with NASA HDTN v2.0.0: the retained results dated 2026-07-07 identify Hardy v0.2.0 and 100/100 returned pings for HDTN. The test documentation describes requests and responses in both initiation directions over TCPCLv4; its implementation overview marks the HDTN test Passing. Hardy supplies a native Rust BPv7 parser/builder and BPA, while the Docker recipe builds unmodified NASA HDTN from its v2.0.0 source tag. These are separately developed BP implementations, not wrappers of one BP engine. Under E01 bounded-function credit, this establishes public reported interoperability for the BPv7 bundle exchange common to this column.", "method": "Documentary interoperability report review; only common BPv7 exchange credited", "source_label": "Public Hardy/HDTN test report, pinned test configuration and separately implemented BPv7 source paths", "sources": [ "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/interop_results.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/README.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/README.md", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/test_hdtn_ping.sh", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/HDTN/docker/Dockerfile", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/tests/interop/run_all.sh", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/bpv7/src/lib.rs", "https://github.com/ricktaylor/hardy/blob/02563815bd01aed173948b5d4c31fbdcdc67c94c/bpv7/Cargo.toml" ], "editorial_references": [ "round342-sources.json", "round342-review.json" ], "qualification": "Credit is restricted to BPv7 bundle exchange. TLS is explicitly disabled in the HDTN test, and the echo configuration supplies no evidence of BIB-HMAC-SHA2/BCB-AES-GCM policy interoperability. The observed carrier is TCPCLv4, not LTP. Credit only the shared BPv7 bundle layer; no LTP, Encapsulation or AOS exchange is inferred. The source snapshot pins the report and current harness, not every byte of the historical run: the report names Hardy v0.2.0 but the retained repository has later changes. No packet captures or full historical logs were inspected, and no test was rerun here. The summary runner tolerates test-script errors and extracts RTT statistics; its 100/100 row alone is not proof that every test phase passed. The separate public Passing statement is attributed to the implementer. No E04 independent performance qualification, security audit, complete-stack implementation qualification or production-operation claim follows." }, { "id": "E01-LP", "feature": "E01", "stack": "LP", "status": "Y", "reason": "The public quic-v1 interoperability matrix records successful cross-implementation transport tests between go-libp2p v0.43 and rust-libp2p v0.56 in both directions. They use separately developed Go and Rust cores, not wrappers of one engine. The public test-plan describes the traffic exchange.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://libp2p.io/status/transport/quic-v1/", "https://github.com/libp2p/test-plans/blob/master/transport-interop/README.md", "https://libp2p.io/status/" ], "editorial_references": [], "qualification": "Published run dated 2026-02-22. Credit the QUIC-v1 authenticated transport/stream exchange only, not migration, revocation, global scale or every selected policy. Shared ecosystem/standardization is disclosed and does not constitute one implementation." }, { "id": "E01-TO", "feature": "E01", "stack": "TO", "status": "Y", "reason": "The public integration-shadow job 1789054 in pipeline 427048 succeeded on 22 October 2026 at Arti commit c87b1abe87460871a9a94371ccd311ad53400481. Its pinned CI configuration runs tests/shadow/run and does not allow job failure. The matching Shadow configuration starts a C Tor onion service with an authorized_clients file and an Arti client with a persistent keystore. The articlient-onion-auth traffic generator targets that authenticated v3 onion address; the validator requires at least one successful transfer out of ten attempts and exits nonzero otherwise. This joins a recorded executed job to the exact cross-implementation test rather than inferring execution from a release announcement or merged test source. Arti is a separate native Rust implementation, not a wrapper around C Tor; common Tor Project stewardship does not negate implementation independence under E01.", "method": "Executed-job receipt bound to cross-implementation authenticated transfer assertion", "source_label": "Public Tor Project CI job metadata and matching immutable Arti test sources", "sources": [ "https://gitlab.torproject.org/tpo/core/arti/-/jobs/1789054", "https://gitlab.torproject.org/tpo/core/arti/-/pipelines/427048", "https://arti.torproject.org/about/" ], "editorial_references": [ "round634.html", "round634-sources.json" ], "qualification": "Bounded evidence of authenticated onion-service traffic exchange in Shadow, not a reliability, anonymity, security or production-network qualification. The authenticated case requires only 1/10 successful streams because of documented test issues; actual transfer counts were not retrieved. The trace API returned HTTP 401, so execution is supported by public job status plus pinned test/configuration logic, not a claim to have inspected raw run logs. C Tor is installed from the Tor Project Bookworm package repository by this job; its exact package build was not recovered and is not invented. Optional Conflux onion-service behavior is not tested or credited here. Both implementations share project stewardship: this is independently developed code, not an independent third-party evaluation. No local test was executed." }, { "id": "E01-I2", "feature": "E01", "stack": "I2", "status": "Y", "reason": "The public I2P Python README reports successful NTCP2 handshake interoperability against live Java I2P 2.x peers. It identifies bimo.studio as the author and describes a from-scratch Python implementation, not a binding or wrapper of the Java router; it expressly states that Java project code was not copied. This is a public implementer report of exchanged NTCP2 handshake traffic between independent code lineages. Credit this selected router-to-router transport function, consistent with E01 allowing explicitly bounded tested functions.", "method": "Public implementer-report review with explicitly limited function credit; no new interoperability execution", "source_label": "Public implementer README and 0.1.0 changelog dated 2026-03-23; Python NTCP2 source; retained commit 65a1e8dc0791e861d9277a2039e1c2e71345e4bd and hashes", "sources": [ "https://tangled.org/distributed.camp/i2p-python/blob/main/README.md", "https://tangled.org/distributed.camp/i2p-python", "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [ "round335-sources.json" ], "qualification": "Implementer-reported result, not independently repeated here. The retained repository revision identifies the report, not the exact Python build used in the test; the Java peer version is given only as 2.x. No packet capture, exact test date, peer inventory or detailed test log is supplied in the README. Credit only NTCP2 handshake exchange, not end-to-end application delivery, tunnel construction, multiple active outbound tunnels, private bootstrap, all-IPv4 deployment, memory-only history policy, current PQ extensions or the complete selected configuration. No E04 reproducibility, security, performance or six-month operation claim follows. The broad README claim of a complete router is not adopted as a separate implementation qualification." }, { "id": "E01-YG", "feature": "E01", "stack": "YG", "status": "?", "reason": "The public ironwood-rs README at 28b14c3 reports successful end-to-end encrypted traffic exchange between its Rust implementation and the Go reference, naming yggdrasil-go v0.5.13. Inspected Rust routing/session code and Cargo dependencies implement the core in Rust rather than wrapping the Go engine. A separate Yggdrasil-ng README at c9a54f1 also reports interoperability with Go 0.5.x, but is supplementary. This identifies concrete interoperability evidence, but src/core.rs describes itself as a faithful port of the Go network and encrypted packages. Separate executables and a Rust rewrite do not by themselves establish independently developed implementations; code lineage remains to qualify. The v0.5.13 Go manifest pins Ironwood 7017dbc; the retained nine-commit comparison to selected d50055b changes queue handling, dependencies, fuzz tests and optional password authentication. With no group password, the signature preimage stays unchanged and the reviewed session/traffic wire format is retained. This supports applicability of the historical core-function evidence; it is a source-based inference, not a new execution against d50055b.", "method": "Documentary interoperability evidence, restricted to the reported encrypted core traffic function", "source_label": "Public implementer reports, pinned Rust port source and retained Go version comparison", "sources": [ "https://github.com/AlexMelanFromRingo/ironwood-rs/blob/28b14c3f0bdd8614d2a94584de49bf0ec2fd9261/README.md", "https://github.com/AlexMelanFromRingo/ironwood-rs/blob/28b14c3f0bdd8614d2a94584de49bf0ec2fd9261/src/core.rs", "https://github.com/AlexMelanFromRingo/ironwood-rs/blob/28b14c3f0bdd8614d2a94584de49bf0ec2fd9261/tests/two_node.rs", "https://github.com/Revertron/Yggdrasil-ng/blob/c9a54f1587bb133a06072596484c972a336db0d2/README.md", "https://github.com/yggdrasil-network/yggdrasil-go/blob/v0.5.13/go.mod", "https://github.com/Arceliar/ironwood/compare/7017dbc41d8e...d50055b11f5ec5b56ee4e56ba9a75261461821dc" ], "editorial_references": [ "round341-sources.json", "round341-review.json" ], "qualification": "Still Pending: the independence requirement is unresolved. Implementer-reported test, not independently repeated here. The retained Rust commit identifies the report, not the exact tested build; no dated packet capture, complete topology or run log is supplied. The report concerns Ironwood encrypted traffic exchange. TLS 1.3, pinned peer keys, numeric IPv4 deployment, the ordinary IPv6/UDP application path and the complete selected configuration are not established by that report. Rust TLS code and a live-peer test branch are available, but code existence is not proof that those branches were exercised; that live test asserts peering, not payload delivery. Yggdrasil-ng explicitly reports TCP peering. No clean-room provenance, institutional non-affiliation, E04 measurement reproducibility, security audit, performance, production maturity or six-month operation conclusion follows. Shared protocol design and Rust rewrites of a Go design are disclosed; separate runtime implementations alone are insufficient to resolve the independence question." }, { "id": "E01-CJ", "feature": "E01", "stack": "CJ", "status": "?", "reason": "New criterion: evidence for this exact selected profile has not yet been established. Missing evidence is not a negative finding.", "method": "Initial evidence inventory; no new execution", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E01" ], "qualification": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E01-MQ", "feature": "E01", "stack": "MQ", "status": "Y", "reason": "The mp-quic-go public interoperability report states that all 23 tests pass against picoquic commit 01e124ebdf9fc50df307e01e71f2744471ddc470, dated 2026-10-07. The package explicitly targets multipath draft-21 and documents shared draft-20/21 code points. Unlike the earlier draft-06 matrix, the published test source opens and probes explicit path IDs, checks multipath negotiation, transfers a 10 MB response with data on paths 0 and 1, and checks key updates in both client/server role assignments. Credit these common multipath transport functions under E01. The Go implementation is a quic-go-derived fork; its independent counterpart is native C picoquic, not another fork of the same Go engine.", "method": "Bounded documentary interoperability witness; no new execution", "source_label": "Pinned public mp-quic-go/picoquic completed-test report and native test assertions", "sources": [ "https://github.com/qoke/mp-quic-go/blob/084c13ea3834fbe58cedb63db9208951d714f839/interop/multipath/README.md", "https://github.com/qoke/mp-quic-go/blob/084c13ea3834fbe58cedb63db9208951d714f839/interop/multipath/doc.go", "https://github.com/qoke/mp-quic-go/blob/084c13ea3834fbe58cedb63db9208951d714f839/interop/multipath/picoquic_test.go", "https://github.com/qoke/mp-quic-go/blob/084c13ea3834fbe58cedb63db9208951d714f839/interop/multipath/Dockerfile", "https://github.com/qoke/mp-quic-go/blob/084c13ea3834fbe58cedb63db9208951d714f839/README.md" ], "editorial_references": [ "round346-sources.json", "round346-review.json" ], "qualification": "Implementer-reported result, not an editorial rerun or independent certification. The retained report/source snapshot is 084c13ea; the result pins the picoquic commit but does not separately identify the exact mp-quic-go execution commit or publish inspected per-test qlogs. Tests use real UDP on Linux loopback and HTTP/0.9 hq-interop with a test CA, not selected mutual final-key authentication, proactive duplicate scheduling or physical diverse paths. Setup can skip without Linux/Docker; the completed-test claim comes from the explicit Results section, not from mere test presence or a green generic CI job. Same code points are not full semantic equivalence: credit the inspected path-ID negotiation/data functions only. Preserve reported edge failures involving early connection-ID switching, opening a path too early, initial_max_path_id=0, address-discovery callbacks and compatible version negotiation; the passing cases use documented ordering/configuration workarounds. No full-profile, all-lifecycle, security, E04 performance, or global-scale qualification." }, { "id": "E01-SC", "feature": "E01", "stack": "SC", "status": "?", "reason": "New criterion: evidence for this exact selected profile has not yet been established. Missing evidence is not a negative finding. JPAN README at fbc7aabe1accb81385b943508bf6a835e58c2d95 identifies a pure-Java SCION endpoint stack supporting UDP and SCMP (README artifact version 0.8.0). It distinguishes rudimentary simulated-network JUnit tests from recommended testing against the reference SCION network or SCIONLab. This is a concrete second-codebase candidate, not a completed independent interoperability report.", "method": "Primary implementation README and publisher-deposited metadata; no execution or full-paper qualification", "source_label": "Approved criterion and initial research task", "sources": [ "https://github.com/scionproto-contrib/jpan/blob/fbc7aabe1accb81385b943508bf6a835e58c2d95/README.md" ], "editorial_references": [ "round430.html", "round430-sources.json" ], "qualification": "Identify JPAN contributor/team relationships and a dated public exchange with the reference implementation, including both versions, topology and selected functions. Recommended test environments, sample programs and a distinct programming language alone establish neither an executed exchange nor independent teams." }, { "id": "E01-RT", "feature": "E01", "stack": "RT", "status": "?", "reason": "The earlier Leviculum report remains a historical Python 1.3.5 interoperability witness. A newer, separate LXMF-rs public account at commit fbc75b86e15550722923b366398f0a4116182894 reports a completed Python Reticulum 1.5.5 Link download against exact Python commit 7f2b3b9b524c9386316379af1313b43a5e4f7a5d, with received README.mu bytes compared to the reference conversion. Its published test uses TCP loopback. Thus lack of any 1.5.5 exchange is no longer the outstanding question. This evidence establishes a narrower reported exchange, not the complete selected raw serial HDLC and secret-IFAC composition.", "method": "Documentary reconciliation; no new interoperability execution", "source_label": "Pinned LXMF-rs 1.5.5 execution account and transport-specific test sources", "sources": [ "https://github.com/FreeTAKTeam/LXMF-rs/blob/fbc75b86e15550722923b366398f0a4116182894/docs/status/rns-1.5.5-delta.md", "https://codeberg.org/Lew_Palm/leviculum/src/commit/5035bac7d80ae8baf2481d11d6af2acb7cede123/leviculum-std/tests/rnsd_interop/lrproof_hop_undercount_interop_tests.rs", "https://codeberg.org/Lew_Palm/leviculum/src/commit/5035bac7d80ae8baf2481d11d6af2acb7cede123/docs/src/protocol-notes/rns-1-5-x-audit.md", "https://github.com/FreeTAKTeam/LXMF-rs/blob/fbc75b86e15550722923b366398f0a4116182894/crates/apps/rns-tools/tests/rngit_python_interop/rns_1_5_5_markdown_download.rs" ], "editorial_references": [ "round336-sources.json", "round336-method-comparison.json", "reticulum-coverage-followup-20261025.json", "round637.html" ], "qualification": "Pending for the selected composition. Published source separately covers raw HDLC with IFAC, a KISS/IFAC pseudo-terminal roundtrip and Link.identify over TCP. The KISS and identify tests use a generic Python reference helper; their existence is not an execution receipt for the exact selected serial profile. Do not combine these separate tests into one demonstrated 1.5.5 HDLC/IFAC exchange. Obtain a public executed receipt binding the selected transport, IFAC, version and required Link functions, or a justified compatibility mapping for explicitly limited tested functions. The download execution is attributed to the implementer; editorial did not rerun it. This update supersedes the broad missing-1.5.x wording, not the retained Leviculum historical evidence." }, { "id": "E01-NS", "feature": "E01", "stack": "NS", "status": "Y", "reason": "The public nostr-bench report dated 2025-12-16 names a Zig client and distinct Strfry (C++) and nostr-rs-relay (Rust) relay implementations, and reports successful event publication exchanges. The report identifies nostr-bench v0.1.1; its retained tag 3b7848a pins libnostr-z v0.1.5. In that tag, the generator signs kind-1 events and the burst-publishing loop sends EVENT and records success only after parsing an OK response with success=true. This documents actual reported NIP-01 client-to-relay traffic between separately developed client and relay cores. Credit that publication/acknowledgment function only, consistent with E01 bounded-function evidence.", "method": "Documentary report plus test-assertion review; restricted NIP-01 function credit", "source_label": "Published Nostr test report and inspected historical client tag with native Zig event signing and relay ACK handling", "sources": [ "https://github.com/privkeyio/nostr-bench/blob/9121d6d7d57c4879052067325be0df7800d0c45c/reports/BENCHMARK_RESULTS.md", "https://github.com/privkeyio/nostr-bench/blob/3b7848a1dfb931c463db753a740584c194c8e71c/src/benchmark.zig", "https://github.com/privkeyio/nostr-bench/blob/3b7848a1dfb931c463db753a740584c194c8e71c/src/event_generator.zig", "https://github.com/privkeyio/nostr-bench/blob/3b7848a1dfb931c463db753a740584c194c8e71c/src/stats.zig", "https://github.com/privkeyio/nostr-bench/blob/3b7848a1dfb931c463db753a740584c194c8e71c/build.zig.zon", "https://github.com/privkeyio/nostr-bench/blob/3b7848a1dfb931c463db753a740584c194c8e71c/docker-compose.yml", "https://github.com/privkeyio/nostr-bench/blob/3b7848a1dfb931c463db753a740584c194c8e71c/Dockerfile.nostr-rs-relay" ], "editorial_references": [ "round343-sources.json", "round343-review.json" ], "qualification": "Public implementer report, not a new execution or packet capture. The client and relays implement complementary NIP-01 roles; this does not claim relay-to-relay federation or synchronization. Relay builds are not pinned exactly: compose uses Strfry latest and the Rust Dockerfile selects the newest available tag at build time. The retained current report and historical client tag do not reconstruct all historical binaries. The benchmark uses ws:// rather than selected WSS/TLS 1.3, and does not qualify concurrent two-relay delivery, reader signature verification, memory-only operator policy or the complete column. A null receive can escape success/error accounting, and the burst loop does not match the OK event ID; do not interpret its displayed 100% as proof that every requested event was accepted. Query, retrieval and NIP-50 results are not credited. No independent performance, security, full compliance or production-duration conclusion follows." }, { "id": "E01-MT", "feature": "E01", "stack": "MT", "status": "?", "reason": "New criterion: evidence for this exact selected profile has not yet been established. Missing evidence is not a negative finding.", "method": "Initial evidence inventory; no new execution", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E01" ], "qualification": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E01-GN", "feature": "E01", "stack": "GN", "status": "?", "reason": "New criterion: evidence for this exact selected profile has not yet been established. Missing evidence is not a negative finding.", "method": "Initial evidence inventory; no new execution", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E01" ], "qualification": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E01-ND", "feature": "E01", "stack": "ND", "status": "Y", "reason": "A public operator report dated 2021-09-26 describes the NDNts video deployment and explicitly identifies producers connected to local NFD over Unix sockets. It reports collected playback observations from July 1 through August 15, 2021, including successful delivery. This is a reported running application/forwarder exchange, not merely a recipe. NDNts implements Interest/Data encoding in TypeScript rather than wrapping the NFD C++ engine; the retained package documentation identifies NDN packet format v0.3. Credit only the common NDN Interest/Data exchange at the application-to-NFD Unix boundary, under the existing E01 bounded-function rule.", "method": "Historical operational report with bounded application/forwarder function credit; no new execution", "source_label": "Public NDNts deployment observations, native packet/Unix transport source and NIST interoperability procedure", "sources": [ "https://yoursunny.com/t/2021/NDN-video-ndn6/", "https://github.com/yoursunny/NDNts/blob/674df9d57cbe2f77d91f4b9a1d67736ce20e5e46/pkg/packet/README.md", "https://github.com/yoursunny/NDNts/blob/674df9d57cbe2f77d91f4b9a1d67736ce20e5e46/pkg/packet/src/interest.ts", "https://github.com/yoursunny/NDNts/blob/674df9d57cbe2f77d91f4b9a1d67736ce20e5e46/pkg/packet/src/data.ts", "https://github.com/yoursunny/NDNts/blob/674df9d57cbe2f77d91f4b9a1d67736ce20e5e46/pkg/node-transport/src/unix-transport.ts", "https://github.com/usnistgov/ndn-dpdk/blob/f575ccb737f895a7c4adc48f60a5842489bc6572/docs/interop/NFD.md" ], "editorial_references": [ "round344-sources.json", "round344-review.json" ], "qualification": "The report is by the deployment operator and NDNts author, not an independent rerun. Shared NDN community and contributor involvement are disclosed; separate packet-processing codebases are credited, not institutional non-affiliation. Exact 2021 NDNts/NFD builds are absent, and retained current source identifies implementation lineage, not historical runtime bytes. Applicability to the common packet/Unix interface is a documentary inference, not an execution against selected NFD 24.07. The wider experiment used IPv6 underlay, NLSR, WebSockets and HTTP/3; none replaces the selected direct-Ethernet column or receives credit here. No Ethernet interoperability, selected ECDSA P-256 consumer verification, exact trust policy, independent performance, global scale or complete-profile qualification is established. Separate NIST NFD/NDN-DPDK documentation supplies an Ethernet-unicast procedure and an interoperability statement, but no dated run result was found in that inspected procedure." }, { "id": "E01-AX", "feature": "E01", "stack": "AX", "status": "Y", "reason": "Public GitHub Actions run 38866148407 on 2026-10-16 at Packet.NET commit 1c42ee63 reports success for the AX.25/general interoperability step. Its selected non-skippable Connected_IFrame_RoundTrip_Against_Linbpq_Node_Prompt test establishes a connected AX.25 link to the independent LinBPQ implementation, receives a nonempty I-frame banner, transmits a command, requires a nonempty PID 0xF0 response and disconnects. Source and successful step jointly provide a bounded documentary execution witness under E01; this is stronger than the previously retained test recipe alone. Packet.NET sibling language ports are not counted as independent implementations.", "method": "Bounded execution inference from successful CI step and selected non-skippable test; no new execution", "source_label": "Public CI run and job-step results plus pinned native test and container configuration", "sources": [ "https://github.com/packet-net/packet.net/actions/runs/38866148407", "https://github.com/packet-net/packet.net/blob/1c42ee63f3d6adf2f7e83057db9502182e509b86/tests/Packet.Interop.Tests/Linbpq/LinbpqViaNetsimConnectedMode.cs", "https://github.com/packet-net/packet.net/blob/1c42ee63f3d6adf2f7e83057db9502182e509b86/.github/workflows/interop.yml", "https://github.com/packet-net/packet.net/blob/1c42ee63f3d6adf2f7e83057db9502182e509b86/docker/compose.interop.yml", "https://github.com/packet-net/packet.net/blob/1c42ee63f3d6adf2f7e83057db9502182e509b86/docs/about.md", "https://github.com/packet-net/packet.net/blob/1c42ee63f3d6adf2f7e83057db9502182e509b86/tests/Packet.Interop.Tests/Linbpq/NetRomL4CircuitViaAxudp.cs" ], "editorial_references": [ "round345-sources.json", "round345-review.json" ], "qualification": "Credit only common connected-mode AX.25 exchange over KISS-TCP and a simulated AFSK channel, not physical serial/radio or the complete selected AX.25 plus classic NET/ROM composition. CI result is executor-attributed; no local rerun. Individual test logs were unavailable through the anonymous API (403), so the conclusion is explicitly an inference from a successful selected step and its non-skippable test source, not an inspected per-test transcript. The separate NET/ROM step also succeeded, but its L4 AXUDP test can skip on failed reachability; do not infer its individual execution from the green step. No NET/ROM circuit credit here. Compose pins LinBPQ image b01155258c50c0a3f039bc7e3db92e669af505fa95328470980d977d54dd6903, annotated 6.0.25.41; the test comment still mentions 6.0.25.23. Neither annotation is independent runtime-version verification. No RF, INP3, performance, security, global-scale or E04 qualification." }, { "id": "E01-BA", "feature": "E01", "stack": "BA", "status": "?", "reason": "New criterion: evidence for this exact selected profile has not yet been established. Missing evidence is not a negative finding.", "method": "Initial evidence inventory; no new execution", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E01" ], "qualification": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E01-BL", "feature": "E01", "stack": "BL", "status": "Y", "reason": "The IETF 101 public implementation report identifies BIRD as a from-scratch implementation and reports BIRD 1.6/2.0 interoperating with deployed babeld for base IPv6 routing. BIRD 2.0 already parsed mandatory sub-TLVs and discarded unicast Hellos. RFC 8966 Appendix F explicitly preserves a compatible base mode when unicast/unscheduled Hellos and extensions using mandatory sub-TLVs are not sent. This closes the date-only gap for the reported common IPv6 routing behavior; final publication after the test does not erase that evidence. Independent code lineages and a public implementer report satisfy E01 for this bounded function.", "method": "Public implementer-report review and normative compatibility mapping; no new interop test", "source_label": "IETF 101 BIRD implementation report and RFC 8966 compatibility rules", "sources": [ "https://www.ietf.org/proceedings/101/slides/slides-101-babel-babel-in-bird-implementation-status-00.pdf", "https://www.rfc-editor.org/rfc/rfc8966.html#appendix-F" ], "editorial_references": [ "round228-sources.json" ], "qualification": "Credit base IPv6 route exchange only, using the common multicast-Hello mode without incompatible extensions. The slides identify BIRD releases but do not pin an exact babeld commit or supply packet captures. This is implementer-reported interoperability, not an independently repeated test, full RFC conformance, data-plane performance or execution of the study-specific ULA hierarchy and filters. It does not resolve G05/E04/E05 or authentication-extension behavior." }, { "id": "E01-RI", "feature": "E01", "stack": "RI", "status": "Y", "reason": "RIOT release 2026.04-RC1 reports task 08-03, ICMPv6 echo between RIOT and Contiki-NG, as PASSED. The pinned procedure configures separate GNRC and Contiki-NG nodes on IEEE 802.15.4 with matching PAN IDs and link-local IPv6 addresses. Its example transcripts show bidirectional replies. These are distinct networking implementations, not wrappers around the same stack. Credit only the common IPv6/6LoWPAN exchange under E01, consistently with earlier bounded interoperability decisions.", "method": "Bounded documentary interoperability witness; not a full-stack certification", "source_label": "RIOT release per-task report, pinned procedure and public CI metadata", "sources": [ "https://github.com/RIOT-OS/Release-Specs/issues/333#issuecomment-4214861612", "https://github.com/RIOT-OS/Release-Specs/blob/11aea95dcea3d654afc06a6ecdff9fc0e089d866/08-interop/README.md", "https://github.com/RIOT-OS/RIOT/actions/runs/24194236547" ], "editorial_references": [ "round357-sources.json" ], "qualification": "Implementer-reported per-task result; no editorial rerun. The linked overall CI run was cancelled, not globally successful. It identifies RIOT a897b0498f635654f091bf9f33e9696aa773e886, but the retrieved report does not pin the tested Contiki-NG commit. The 2023 example transcript in the procedure is not a fresh 2026 execution log. No claim of tested PSK DTLS, RPL interoperability, application authorization, full-profile conformance, independent performance measurement or operational adoption. Selected security and routing settings remain unchanged." }, { "id": "E01-HP", "feature": "E01", "stack": "HP", "status": "?", "reason": "New approved criterion or composition. No verdict is inherited from another profile or inferred from a sovereignty label. Evidence must cover this exact selected stack.", "method": "Evidence inventory; no new runtime qualification", "source_label": "Approved editorial scope and primary protocol specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc8046.html" ], "editorial_references": [ "round245.html" ], "qualification": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E01-CX", "feature": "E01", "stack": "CX", "status": "?", "reason": "New approved criterion or composition. No verdict is inherited from another profile or inferred from a sovereignty label. Evidence must cover this exact selected stack.", "method": "Evidence inventory; no new runtime qualification", "source_label": "Approved editorial scope and primary protocol specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html", "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round245.html" ], "qualification": "Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test." }, { "id": "E01-LI", "feature": "E01", "stack": "LI", "status": "Y", "reason": "The official IETF 76 report records successful Cisco NX-OS/OpenLISP data-plane interoperability after fixes, and Cisco/LISP-Click IPv4 data-plane interoperability. OpenLISP is a separately developed UC Louvain FreeBSD implementation. Credit is restricted to historical basic IP-over-UDP/LISP packet exchange, common to this column, under the same bounded-function rule already used for E01-IP and E01-BP.", "method": "Primary interoperability report and protocol-lineage review; no execution", "source_label": "Margaret Wasserman, IETF 76 interoperability report (2009), slides 2–5; OpenLISP implementation report", "sources": [ "https://www.ietf.org/proceedings/76/slides/lisp-4/lisp-4_files/slide0017.htm", "https://www.ietf.org/proceedings/76/slides/lisp-4/lisp-4_files/Slide0005.gif", "https://www.ietf.org/proceedings/76/slides/lisp-4/lisp-4_files/slide0015.htm", "https://www.ietf.org/proceedings/76/slides/lisp-4/lisp-4_files/slide0016.htm", "https://inl.info.ucl.ac.be/publications/historical/2008-openlisp-implementation-r.html", "https://www.ietf.org/archive/id/draft-ietf-lisp-05.txt", "https://datatracker.ietf.org/doc/html/draft-ietf-lisp-07", "https://www.rfc-editor.org/rfc/rfc9300.html#section-5", "https://www.rfc-editor.org/rfc/rfc9300.html#section-18" ], "editorial_references": [ "round390-sources.json" ], "qualification": "Historical draft-05 testing, not a new RFC 9300/9301 conformance test. The report identifies NX-OS and FreeBSD 7.x but does not pin exact binary builds or provide packet captures. Only the base encapsulated-data function is credited; no current Map-Register authentication, full control plane, application-UDP workload, LISP-SEC, or complete deployment qualification. Some pairs failed and some successes required fixes; no all-pairs claim. Shared standards participation does not imply shared implementation code. No tests were rerun." }, { "id": "E01-IL", "feature": "E01", "stack": "IL", "status": "?", "reason": "ILNPv6 has been admitted with an explicit composition; this criterion still requires its own evidence assessment.", "method": "Documentary evidence with explicit scope", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "For the declared ILNPv6/TCP profile: Identify implementers, code lineage, versions, selected profile, exchanged functions and a public test report; distinguish an interoperability goal from a completed test. Distinguish ILNP identifiers/locators from ordinary IPv6 address semantics and optional security or multipath extensions." }, { "id": "E01-TS", "feature": "E01", "stack": "TS", "status": "Y", "reason": "A dated first-hand public report by taavi013 (3 May 2019, BoringTun issue 79) explicitly identifies a working tunnel between an iOS BoringTun client and the Linux kernel WireGuard implementation. The subsequent comment identifies and corrects a Swift-to-C string conversion problem in client construction. Cloudflare documents BoringTun as its independently written Rust implementation, distinct from the original kernel implementation. Tailscale documents its selected data plane as a wireguard-go fork. E01 credits the tested common WireGuard tunnel function, using the same bounded component standard applied elsewhere in the matrix; it does not require whole-stack certification.", "method": "Dated public operator test report, independent-code lineage and selected-component mapping", "source_label": "BoringTun issue 79 and follow-up; Cloudflare implementation announcement; Tailscale WireGuard documentation", "sources": [ "https://github.com/cloudflare/boringtun/issues/79", "https://github.com/cloudflare/boringtun/issues/79#issuecomment-489104235", "https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/", "https://tailscale.com/docs/concepts/wireguard" ], "editorial_references": [ "round599.html", "round599-sources.json" ], "qualification": "Historical operator-reported execution, not an editorial rerun or a current Tailscale-to-BoringTun test. The report gives iOS 12.2, Xcode 10.2 and Rust 1.34.0 but omits exact BoringTun and kernel module revisions, packet captures and a complete reproduction recipe. This limits reproducibility and version coverage rather than negating the explicitly identified cross-implementation exchange. No Tailnet Lock, managed coordination, DERP, mobility, performance or complete-product interoperability is credited. The separate 2026 GotaTun audit remains corroborating execution evidence with an unidentified remote implementation; it is not used to invent that peer identity." }, { "id": "E01-RA", "feature": "E01", "stack": "RA", "status": "?", "reason": "The rlite README states that its demonstrator accepts configuration files interchangeable with the IRATI demonstrator. This establishes configuration compatibility, not an observed traffic exchange between the two stacks. The IRINA final report describes interoperability with the Pouzin Society prototype as an objective. Neither item supplies a completed cross-implementation test for the selected profile.", "method": "Distinguish documented demonstration scope from the criterion required evidence", "source_label": "Primary project documentary evidence", "sources": [ "https://github.com/rlite/rlite", "https://geant3plus.archive.geant.net/Documents/IRINA_final_report.pdf" ], "editorial_references": [ "round674.html" ], "qualification": "Obtain a public test report identifying both independent implementations, versions, exchanged traffic and tested profile. Do not count interchangeable configuration files or a project interoperability objective as a completed result." }, { "id": "E02-PN", "feature": "E02", "stack": "PN", "status": "N", "reason": "The project owner explicitly states that no third party has published anything about PRP as of 2026-10-16. This confirms that a published independent security analysis required by E02 is not available.", "method": "Owner-confirmed availability assessment, with separate primary-source IPR policy analysis", "source_label": "Dated project-owner declaration; RFC 8179 section 5.5 for patent-policy distinction", "sources": [], "editorial_references": [ "round355-review.json", "round355-review.json", "round355-sources.json" ], "qualification": "A dated evidence-maturity finding, not a claim of insecurity. Reassess on publication of an independently authored audit or formal analysis covering the selected profile." }, { "id": "E02-PI", "feature": "E02", "stack": "PI", "status": "N", "reason": "The project owner explicitly states that no third party has published anything about PRP as of 2026-10-16. This confirms that a published independent security analysis required by E02 is not available.", "method": "Owner-confirmed availability assessment, with separate primary-source IPR policy analysis", "source_label": "Dated project-owner declaration; RFC 8179 section 5.5 for patent-policy distinction", "sources": [], "editorial_references": [ "round355-review.json", "round355-review.json", "round355-sources.json" ], "qualification": "A dated evidence-maturity finding, not a claim of insecurity. Reassess on publication of an independently authored audit or formal analysis covering the selected profile." }, { "id": "E02-IP", "feature": "E02", "stack": "IP", "status": "Y", "reason": "Fernando Gont published RFC 6274 (2011), based on the UK CPNI security-assessment project, independently examining established IPv4 specifications and implementation practices. It analyzes header processing, fragmentation/reassembly and other native IP mechanisms. This is a published external security assessment of the selected IPv4 datagram service, not merely a cipher review or the original protocol author asserting security.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://www.rfc-editor.org/rfc/rfc6274.html" ], "editorial_references": [], "qualification": "Scope: IPv4 mechanisms in the report, not IPv6, BGP/PIM, every current OS or the entire optional profile. Author affiliation and commissioned CPNI origin are explicit; no clean audit, current vulnerability claim or full-stack certification follows. E02 requires a scoped analysis of security-critical mechanisms, not universal coverage." }, { "id": "E02-BP", "feature": "E02", "stack": "BP", "status": "Y", "reason": "Dowling, Hale, Tian and Wimalasiri (2025) formally analyze BPv7/BPSec default-context integrity/confidentiality with pre-established keys. This directly covers the selected bundle-security mechanism, including intermediate block processing and loss-detection limitations; TCPCL/TLS integration is outside the proof.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://eprints.whiterose.ac.uk/id/eprint/221768/1/1-4-21.pdf", "https://eprint.iacr.org/2025/023" ], "editorial_references": [], "qualification": "Academic authors at KCL, NPS and Sheffield, distinct from the selected implementation teams. Credit is a protocol analysis of BPSec, not a whole-stack audit, key-management proof or certification of this deployment." }, { "id": "E02-CG", "feature": "E02", "stack": "CG", "status": "Y", "reason": "Dowling, Hale, Tian and Wimalasiri (2025) formally analyze BPv7/BPSec default-context integrity/confidentiality with pre-established keys. This directly covers the selected bundle-security mechanism, including intermediate block processing and loss-detection limitations; SABR routing and TCPCL/TLS integration is outside the proof.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://eprints.whiterose.ac.uk/id/eprint/221768/1/1-4-21.pdf", "https://eprint.iacr.org/2025/023" ], "editorial_references": [], "qualification": "Academic authors at KCL, NPS and Sheffield, distinct from the selected implementation teams. Credit is a protocol analysis of BPSec, not a whole-stack audit, key-management proof or certification of this deployment." }, { "id": "E02-LT", "feature": "E02", "stack": "LT", "status": "Y", "reason": "Dowling, Hale, Tian and Wimalasiri (2025) formally analyze BPv7/BPSec default-context integrity/confidentiality with pre-established keys. This directly covers the selected bundle-security mechanism, including intermediate block processing and loss-detection limitations; LTP/Encapsulation/AOS and SABR integration is outside the proof.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://eprints.whiterose.ac.uk/id/eprint/221768/1/1-4-21.pdf", "https://eprint.iacr.org/2025/023" ], "editorial_references": [], "qualification": "Academic authors at KCL, NPS and Sheffield, distinct from the selected implementation teams. Credit is a protocol analysis of BPSec, not a whole-stack audit, key-management proof or certification of this deployment." }, { "id": "E02-LP", "feature": "E02", "stack": "LP", "status": "Y", "reason": "Fischlin, Guenther and Janson, Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3, Journal of Cryptology 37:9 (published 30 January 2024), supplies third-party computational analysis of QUIC RFC 9000/9001 short-header application-data packet protection in section 6. It models sliding-window handling of unreliable delivery and active ciphertext manipulation, proving conditional confidentiality/integrity bounds. This is analysis of a selected protocol mechanism, not merely an AEAD primitive. E02 permits bounded critical-mechanism coverage; it does not require a whole-stack audit.", "method": "Published computational protocol-security analysis; explicit component and independence scope", "source_label": "Fischlin, Guenther and Janson (2024), Journal of Cryptology 37:9; sections 6 and acknowledgements", "sources": [ "https://doi.org/10.1007/s00145-023-09489-9", "https://tuprints.ulb.tu-darmstadt.de/server/api/core/bitstreams/27a6eee0-7abb-4846-8c4b-f0cfa0fa6346/content" ], "editorial_references": [ "round291-sources.json" ], "qualification": "The paper excludes header protection and key updates from its channel constructions, assuming those mechanisms behave as intended. It does not establish libp2p Peer ID certificate binding, ConnectionGater, migration or implementation code. Established traffic-key assumptions remain prerequisites. Non-tight integrity bounds and repeated forgery attempts are discussed; Yes means published analysis exists, not unconditional security. Authors declare TU Darmstadt and IBM Research Europe affiliations (most Guenther work at ETH Zurich), academic DFG/ATHENE support and IETF feedback. They are distinct from the cited RFC author teams; no commissioning by the compared implementation projects is reported in the acknowledgements. This is disclosed academic third-party review, not a separate conflicts-of-interest investigation or certification. No new runtime test or benchmark." }, { "id": "E02-TO", "feature": "E02", "stack": "TO", "status": "Y", "reason": "Radically Open Security published its April-August 2023 code audit of Tor ecosystem components, including Tor core/client parsing. TOR-024 (pem_decode) and TOR-025 (file parsing) supply concrete implementation-security analysis relevant to the selected Tor endpoint, rather than a browser-only or financial audit.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://blog.torproject.org/code-audit-tor-ecosystem-components/The%20Tor%20Project%20Pentest%20Report%202023%201.0", "https://www.torproject.org/about/reports/" ], "editorial_references": [], "qualification": "Commissioned third-party review, not organizational independence from funding. Credit only the audited core changes in 2023; onion-v3 authorization, Conflux and the entire current composition are not certified. Historical findings are not asserted to remain unresolved." }, { "id": "E02-I2", "feature": "E02", "stack": "I2", "status": "Y", "reason": "Wang et al., arXiv:2512.15510v1 (2025), analyze RouterInfo publication, tunnel/service availability and behavioral correlation, including Java/C++ and NTCP2-related behavior. This is third-party analysis of the selected anonymity architecture, beyond a primitive review.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://arxiv.org/pdf/2512.15510", "https://i2p.net/docs/research/wang2025.pdf" ], "editorial_references": [], "qualification": "Authors at Southeast University, Fuyao University and UMass Lowell; public-network experiments, not this private-bootstrap configuration. The result does not establish an attack success rate here or a vulnerability in every current release. It does not decide E04/G05." }, { "id": "E02-YG", "feature": "E02", "stack": "YG", "status": "Y", "reason": "Dowling, Fischlin, Guenther and Stebila, Journal of Cryptology 34:37 (2021), publish a computational analysis of the final TLS 1.3 handshake and its staged key derivation, distinguishing authentication levels and their assumptions. The selected Yggdrasil composition explicitly includes TLS 1.3 peer transport. Pinned tls.go configures Go crypto/tls, and link_tls.go creates TLS dialers/listeners. This is an independent analysis of a security-critical protocol mechanism used in the selected composition, beyond a primitive review. E02 credits existence of bounded mechanism analysis, as already done for E02-MQ; it does not require or imply a whole-stack audit.", "method": "Published mechanism-analysis coverage, explicitly separated from implementation assurance", "source_label": "Dowling et al. (2021) TLS 1.3 analysis and pinned Yggdrasil transport source", "sources": [ "https://doi.org/10.1007/s00145-021-09384-1", "https://d-nb.info/1255501162/34", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/tls.go", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/link_tls.go" ], "editorial_references": [ "round292-sources.json", "round300-sources.json" ], "qualification": "Credit the TLS 1.3 handshake component only. The pinned configuration skips normal certificate-chain verification, has permissive verification callbacks and does not request client certificates. Consequently this source does not establish Yggdrasil peer authentication or satisfaction of the proof assumptions by its trust/pinning integration. Ironwood routing, native end-to-end encryption, metadata authentication, TLS padding, composition and Go implementation are not audited by this paper. The dialer also allows TLS 1.2; the finding concerns the selected TLS 1.3 case, not every connection the implementation permits. Academic authors/affiliations and funding are documented in round292; no additional conflicts audit. No security guarantee, runtime test, benchmark or new source-code audit is inferred." }, { "id": "E02-CJ", "feature": "E02", "stack": "CJ", "status": "?", "reason": "New criterion: evidence for this exact selected profile has not yet been established. Missing evidence is not a negative finding.", "method": "Initial evidence inventory; no new execution", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E02" ], "qualification": "Find the actual report and authorship; distinguish implementation audit, protocol analysis and formal verification. Confirm coverage of the selected composition rather than only an underlying primitive." }, { "id": "E02-MQ", "feature": "E02", "stack": "MQ", "status": "Y", "reason": "Dowling, Fischlin, Guenther and Stebila (Journal of Cryptology 34:37, 2021) give a computational multi-stage analysis of the final TLS 1.3 handshake, including certificate-authenticated ephemeral Diffie-Hellman and mutual authentication. This is protocol key-establishment analysis, not just a primitive review. RFC 9001 sections 3 and 4.4 identify this handshake and client authentication as selected QUIC mechanisms. Multipath draft-21 section 2 negotiates support during that handshake and applies its changed AEAD construction after completion. E02 therefore has a scoped witness for the selected TLS handshake component.", "method": "Published computational analysis with explicit selected-component mapping", "source_label": "Dowling et al. (2021), TLS 1.3 full-handshake analysis; RFC 9001 sections 3/4.4; multipath draft-21 section 2", "sources": [ "https://doi.org/10.1007/s00145-021-09384-1", "https://d-nb.info/1255501162/34", "https://www.rfc-editor.org/rfc/rfc9001.html", "https://www.ietf.org/archive/id/draft-ietf-quic-multipath-21.html" ], "editorial_references": [ "round292-sources.json" ], "qualification": "The proof assumes its stated signature, hash, key-derivation and Diffie-Hellman security conditions. It does not prove the QUIC/TLS composition, transport-parameter binding, multipath nonce construction, path validation, migration, scheduling, local certificate allowlist or implementation. No claim that the base QUIC record proof automatically covers multipath. Authors list ETH Zurich, TU Darmstadt and University of Waterloo; acknowledgements disclose public academic funding, not commissioning by the compared implementation. They are separate from the selected RFC/draft author teams; no additional conflicts audit is claimed. No runtime execution or whole-stack certification." }, { "id": "E02-SC", "feature": "E02", "stack": "SC", "status": "?", "reason": "Protocols to Code (Pereira et al., arXiv:2405.06074v1, 2024; later CCS 2025 publication) supplies concrete SCION forwarding verification using Isabelle/HOL and Go-code verification. Its scope includes path authorization and implementation safety. The authors describe the router implementation team as independent of the verification effort. However, the author list also includes SCION architect Adrian Perrig; separate implementation and verification teams do not alone establish the third-party independence required by E02.", "method": "Formal-study scope and independence review; no proof execution", "source_label": "Pereira et al., Protocols to Code, arXiv:2405.06074v1; authors, abstract and verification approach", "sources": [ "https://arxiv.org/abs/2405.06074v1", "https://doi.org/10.1145/3719027.3765104" ], "editorial_references": [ "round293-sources.json" ], "qualification": "Identify review governance, author roles and relevant conflicts before classifying this collaboration as independent third-party analysis; shared affiliation alone is not an automatic exclusion. Alternatively locate a qualifying external audit or formal analysis. Preserve the substantive verification evidence rather than treating Pending as absence of security work. The inspected retained artifact is the 2024 v1 preprint; later publication is a separate version. No proof rerun, complete control-plane coverage or current deployed-build certification." }, { "id": "E02-RT", "feature": "E02", "stack": "RT", "status": "N", "reason": "The official project cryptography page, retrieved on 20 October 2026, explicitly states that Reticulum has not been externally security audited. The public audit discussion describes organizing a review and its proposed scope, rather than publishing a completed report. No qualifying independent formal analysis of this networking stack was located in the bounded review. The dated evidence inventory is therefore No on the basis of the project's declared audit status, rather than search silence alone. A security paper about a different blockchain protocol named Reticulum does not qualify.", "method": "Dated project-declared audit status with bounded independent-analysis search", "source_label": "Official Reticulum cryptography page and public audit-planning discussion", "sources": [ "https://reticulum.network/crypto.html", "https://github.com/markqvist/Reticulum/discussions/628" ], "editorial_references": [ "round399-sources.json", "round399.html" ], "qualification": "A dated evidence-maturity assessment, not a finding of insecurity. The official page does not give a publication date or explicitly enumerate every possible formal analysis; an unlocated report could supersede this inventory. Reassess when a published independent audit or formal analysis covering security-critical mechanisms of the selected profile is supplied. Unpublished work and primitive-level reviews are not established by this finding." }, { "id": "E02-NS", "feature": "E02", "stack": "NS", "status": "Y", "reason": "Kimura, Ito, Minematsu, Shiraki and Isobe (EuroS&P 2025) analyze Nostr specifications and implementations. Their event-signature verification and event-ID/cache findings concern NIP-01 authenticity in the selected basic profile. Encrypted-DM and remote-signer findings are not credited to this column.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://crypto-sec-n.github.io/", "https://github.com/crypto-sec-n/Artifacts" ], "editorial_references": [], "qualification": "Independent researchers at NICT, NEC and universities; examined clients and historical versions are listed in the disclosure. This is not an audit of the pinned nostr-rs-relay build, nor a claim that current clients retain the reported defects." }, { "id": "E02-MT", "feature": "E02", "stack": "MT", "status": "?", "reason": "Kantilasa, Agussalim and Junaidi published a replay/tamper study (bit-Tech, DOI 10.32877/bt.v9i1.3847, 10 August 2026). The deposited abstract explicitly studies Meshtastic 2.6.11 shared-key channel messages and proposes a counter/HMAC modification. That is a different security mode from the selected 2.8.1 strict-signature PKI direct-message profile. Separately, official advisory GHSA-377p-prwp-4hwf documents direct-message fallback to legacy channel encryption and reports a fix in 2.7.15. It credits reporters and remediation developers, but does not establish an independent audit of the current selected composition.", "method": "External evidence scope triage, not full-paper audit or local experiment", "source_label": "Publisher-deposited Crossref abstract and official Meshtastic advisory; full paper unavailable (HTTP 403)", "sources": [ "https://doi.org/10.32877/bt.v9i1.3847", "https://github.com/meshtastic/firmware/security/advisories/GHSA-377p-prwp-4hwf", "https://api.crossref.org/works/10.32877/bt.v9i1.3847" ], "editorial_references": [ "round331-sources.json" ], "qualification": "Do not transfer shared-key-channel attack results to PKI direct messages, or classify the pinned later version as vulnerable from an older-version advisory. Full article and publisher page returned HTTP 403; only publisher-deposited metadata/abstract were recovered, so detailed methods, independence/conflict declarations and applicability could not be assessed. Obtain a third-party analysis mapped to the selected PKI/signature mechanisms before changing E02. Absence of a qualifying report in this search is not proof that none exists." }, { "id": "E02-GN", "feature": "E02", "stack": "GN", "status": "?", "reason": "The official GNUnet 0.20.0 release now establishes a concrete security-critical path: core run() reads PEER/PRIVATE_KEY with GNUNET_CRYPTO_eddsa_key_from_file() and passes that key to GSC_KX_init(). The helper resides in crypto_ecc_setup.c. Code Blau section 4.2 independently reviewed the historical GNUNET_CRYPTO_eddsa_key_create_from_file API in its commissioned 2020 Taler audit. This connects the reviewed subject, persistent private-key handling, to CORE rather than merely assuming generic library overlap.", "method": "Version-specific call-path mapping; historical and selected implementations distinguished", "source_label": "Code Blau 2020 audit section 4.2 and official GNUnet 0.20.0 CORE/private-key source", "sources": [ "https://www.taler.net/papers/codeblau-report-2020-q2.pdf", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz" ], "editorial_references": [ "round365-sources.json" ], "qualification": "The 2020 report names a different API and implementation. It describes deleting invalid key files and using access(); the selected 0.20 helper instead documents an error for invalid contents and implements read/create/retry logic. A successor with the same security purpose is not proof that the selected implementation was independently audited. Keep Pending until a documented version/patch mapping establishes applicable review coverage, or a directly applicable third-party analysis is found. The report marks issue 6149 resolved; no current vulnerability, full CORE/CADET/R5N audit, runtime test or clean security certification is claimed." }, { "id": "E02-ND", "feature": "E02", "stack": "ND", "status": "Y", "reason": "Yue, Peng and Feng, IET Information Security 17(3), 360-376 (2023; first published 28 November 2022), analyze collusive Interest-flooding against pending-Interest state and evaluate attack/detection behavior using ndnSIM 2.5. Their affiliations are Civil Aviation University of China and University of Chinese Academy of Sciences; they declare no conflict of interest. This supplies a published external experimental security assessment of a native forwarding mechanism. NFD 24.07 still inserts PIT entries, tracks incoming/outgoing records and expires or finalizes them; this maps the assessed state boundary to the selected profile.", "method": "Bounded published experimental security assessment; source-level applicability check", "source_label": "External IET security study and NFD 24.07 forwarding source", "sources": [ "https://doi.org/10.1049/ise2.12100", "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/daemon/fw/forwarder.cpp" ], "editorial_references": [ "round312-sources.json" ], "qualification": "Credit bounded mechanism analysis, consistent with E02-BA/BL, not a formal proof or complete NFD 24.07 audit. Independence is assessed from disclosed authorship, affiliations and conflicts, not a private relationship investigation. The study proposes its own MF-RF detector: that defense is not part of the selected profile. Colluding consumers/producers and reachable Interests are attack assumptions. No attack success rate, capacity limit, signature failure or detector performance is transferred to the selected Ethernet/multicast-v5 deployment. Its P-256 consumer validation is not assessed. No new simulation ran; E04 and F15 remain unchanged." }, { "id": "E02-AX", "feature": "E02", "stack": "AX", "status": "Y", "reason": "Stanislav Fort (Aisle Research) published a security-focused source review of Linux NET/ROM connection-frame parsing in August–September 2025. The final v4 report identifies missing length validation for the transport header, connection acknowledgements and connection requests, and explains remote malformed-frame exposure. It includes a corrective diff and Eric Dumazet's review attribution. The selected Linux v6.12 af_netrom.c contains the same nr_rx_frame accesses and connection branches. This is published external implementation analysis of a security-critical mechanism in the selected AX.25/NET/ROM composition, sufficient for the scoped E02 criterion.", "method": "Published third-party security source review mapped to the selected implementation; no execution", "source_label": "Stanislav Fort, NET/ROM nr_rx_frame security review v4, 6 September 2025; public maintainer correspondence; selected Linux v6.12 source", "sources": [ "https://lists.openwall.net/netdev/2025/09/06/26", "https://lists.openwall.net/netdev/2025/09/06/16", "https://lists.openwall.net/netdev/2025/09/02/150", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round443-sources.json", "round443.html" ], "qualification": "Scope is the Linux receive/parser and circuit-establishment path, not a whole-protocol audit, cryptographic proof or clean security result. Aisle is the external reporting organization; Linux maintainers reviewed the patch. Public attribution is recorded, without a separate financial/conflict investigation. Fort explicitly said the early report had no specific stack trace; neither that correspondence nor this round establishes an executed exploit. Later patch revisions refine the proposed checks, so v4 is the primary analysis. The v6.12 source mapping does not assert vulnerability of every current kernel or deployed NET/ROM system, nor acceptance of every proposed patch detail. No F15 availability verdict or runtime qualification changes." }, { "id": "E02-BA", "feature": "E02", "stack": "BA", "status": "Y", "reason": "Hoque, Lee, Potharaju, Killian and Nita-Rotaru published Automated Adversarial Testing of Unmodified Wireless Routing Implementations (Turret-W, 2016). Their external implementation assessment includes batman-adv 2014.1.0, including OGM/TQ manipulation and packet-dropping attacks. The selected BATMAN_IV mechanism still consumes advertised TQ and uses it in next-hop selection in Linux 6.12 bat_iv_ogm.c. This maps the protocol-level security analysis to a mechanism actually present in the selected composition.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://endadul.github.io/pubs/Turret-W-ToN2016.pdf", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/bat_iv_ogm.c" ], "editorial_references": [], "qualification": "The authors are university/industry researchers, not the batman-adv implementation team identified by this report. Credit the bounded independent routing-security assessment only. No audit of Linux 6.12, automatic transfer of old replay bugs, current attack reproduction, or evaluation of every optional feature is claimed. E04 remains Pending for the exact selected version/configuration." }, { "id": "E02-BL", "feature": "E02", "stack": "BL", "status": "Y", "reason": "Silverajan, Vajaranta and Kolehmainen (Tampere University of Technology) published Home Network Security: Modelling Power Consumption to Detect and Prevent Attacks on Homenet Routers, AsiaJCIS 2016, DOI 10.1109/AsiaJCIS.2016.10; the paper is retained in Kolehmainen’s public dissertation. Section IV-D analyzes a no-HMAC Babel route-injection scenario. The selected RFC 8966 no-MAC/no-DTLS profile retains the underlying unauthenticated Hello/IHU/Update trust boundary explicitly described in RFC 8966 section 6. This is an independent empirical security assessment of that mechanism.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://trepo.tuni.fi/bitstream/10024/161895/2/978-952-03-3709-4.pdf", "https://doi.org/10.1109/AsiaJCIS.2016.10", "https://www.rfc-editor.org/rfc/rfc8966.html#section-6" ], "editorial_references": [], "qualification": "Historical experiment: Quagga-RE-derived Babel on OpenWrt/Linux 4.1.16, with Homenet components. Credit only the no-authentication control-plane analysis; it is not a test of the selected ULA hierarchy/filters or all RFC 8966 behavior. IPv4-prefix flooding measurements and power numbers do not transfer to the IPv6-only selected configuration. E04 and G05 remain Pending." }, { "id": "E02-RI", "feature": "E02", "stack": "RI", "status": "Y", "reason": "Fischlin, Guenther and Janson, Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3, Journal of Cryptology 37:9 (published 30 January 2024), supplies third-party computational analysis of DTLS 1.3 RFC 9147 protected-record processing in section 7. It models sliding-window handling of unreliable delivery and active ciphertext manipulation, proving conditional confidentiality/integrity bounds. This is analysis of a selected protocol mechanism, not merely an AEAD primitive. E02 permits bounded critical-mechanism coverage; it does not require a whole-stack audit.", "method": "Published computational protocol-security analysis; explicit component and independence scope", "source_label": "Fischlin, Guenther and Janson (2024), Journal of Cryptology 37:9; sections 7 and acknowledgements", "sources": [ "https://doi.org/10.1007/s00145-023-09489-9", "https://tuprints.ulb.tu-darmstadt.de/server/api/core/bitstreams/27a6eee0-7abb-4846-8c4b-f0cfa0fa6346/content" ], "editorial_references": [ "round291-sources.json" ], "qualification": "The paper excludes header protection and key updates from its channel constructions, assuming those mechanisms behave as intended. It does not establish external-PSK provisioning/handshake, RPL, 6LoWPAN or radio implementation. Established traffic-key assumptions remain prerequisites. Non-tight integrity bounds and repeated forgery attempts are discussed; Yes means published analysis exists, not unconditional security. Authors declare TU Darmstadt and IBM Research Europe affiliations (most Guenther work at ETH Zurich), academic DFG/ATHENE support and IETF feedback. They are distinct from the cited RFC author teams; no commissioning by the compared implementation projects is reported in the acknowledgements. This is disclosed academic third-party review, not a separate conflicts-of-interest investigation or certification. No new runtime test or benchmark." }, { "id": "E02-HP", "feature": "E02", "stack": "HP", "status": "Y", "reason": "ENISA commissioned an external cryptographic protocol assessment by KU Leuven and the University of Bristol, published as Study on cryptographic protocols (November 2014). Section 3.3 assesses ESP packet protection, including CBC encryption, integrity ordering and HMAC-SHA2, rather than only the component ciphers. HIP RFC 7402 uses RFC 4303 ESP; its selected transform 8 combines AES-128-CBC with HMAC-SHA-256. This supplies published independent assessment of the selected data-protection mechanism, sufficient for the bounded critical-mechanism scope of E02.", "method": "Primary published external security assessment mapped to a retained critical mechanism; no execution", "source_label": "ENISA Study on cryptographic protocols (2014), authorship and section 3.3; RFC 7402 sections 3/5.1.2", "sources": [ "https://www.enisa.europa.eu/publications/study-on-cryptographic-protocols", "https://www.enisa.europa.eu/sites/default/files/publications/Study%20on%20cryptographic%20protocols.pdf", "https://www.rfc-editor.org/rfc/rfc7402.html", "https://www.rfc-editor.org/rfc/rfc4303.html" ], "editorial_references": [ "round441-sources.json", "round441.html" ], "qualification": "Credit the ESP assessment only, not HIPv2 base exchange, HIT binding, BEET address handling, rekey or RFC 8046 mobility. The report predates final RFC 7402 and does not prove their composition. It recommends CTR/AEAD for future deployment; Yes is evidence of review, not endorsement of the selected CBC suite. Its encryption-only and MAC-then-encrypt attack discussion is not a finding that authenticated transform 8 has those flaws. Contributors, external reviewers and ENISA commissioning are disclosed in the report; no separate conflict investigation, current-code audit, formal-tool replay or clean certification is claimed." }, { "id": "E02-CX", "feature": "E02", "stack": "CX", "status": "Y", "reason": "Goergen, Cholez, Francois and Engel (University of Luxembourg), Security Monitoring for Content-Centric Networking (2013), publish an external security assessment of CCNx pending-Interest state. Sections 2.3 and 4 describe resource-exhaustion threats and a controlled ccnd experiment. This is a protocol/state-handling assessment, not merely analysis of a signature primitive. The selected CCNx 1.0 still retains pending Interests and reverse-path state: RFC 8569 sections 2.4 and 10.3.4 explicitly describe PIT lifetime and insufficient-resource handling. E02 is Yes for published analysis of this retained critical mechanism.", "method": "Primary published external security assessment mapped to a retained critical mechanism; no execution", "source_label": "Goergen et al., Security Monitoring for Content-Centric Networking, HAL-00785254 v1, sections 2.3/4; RFC 8569 sections 1/2.4/10.3.4", "sources": [ "https://hal.science/hal-00785254/document", "https://doi.org/10.1007/978-3-642-35890-6_20", "https://orbilu.uni.lu/handle/10993/3830", "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round441-sources.json", "round441.html" ], "qualification": "Historical CCNx 0.x experiment, not a CCNx 1.0 implementation audit. Exact-name matching and Interest Return differ in 1.0; no attack rate, detection score, vulnerable build or quantitative impact transfers to it. Consumer-validated ECDSA content does not remove the pending-Interest mechanism, but this paper does not audit the selected signature implementation. Authors are external to the RFC 8569 author team; declared affiliation is not a separate conflict investigation. Their proposed monitoring system is not added to the selected stack. No F15 or E04 verdict follows." }, { "id": "E02-LI", "feature": "E02", "stack": "LI", "status": "Y", "reason": "Mahdi Aiash (Middlesex University), A Novel Security Protocol for Resolving Addresses in the Location/ID Split Architecture (NSS 2013), section 3.2, publishes a Casper/FDR analysis of basic LISP mapping. It models ITR, Map-Server and ETR exchanges and tests secrecy and authentication assertions against an active intruder. The author is distinct from the selected RFC author team. This qualifies as published third-party analysis of a critical protocol mechanism. RFC 9301 sections 5.2-5.4 and 8.3 retain the relevant non-proxy Map-Request/Map-Reply exchange and nonce correlation. The selected profile excludes LISP-SEC; registration authentication is not equivalent to authenticating every mapping reply.", "method": "Published academic formal analysis; bounded mechanism mapping, no execution", "source_label": "Aiash, NSS 2013, section 3.2; RFC 9301 sections 5.2-5.4 and 8.3", "sources": [ "https://doi.org/10.1007/978-3-642-38631-2_6", "https://repository.mdx.ac.uk/download/61eee920feab40434d102f8b17cddd3d2c6b63f18dd9182bec78283ae2e7c0b8/408413/LISP%20%281%29.pdf", "https://www.researchgate.net/publication/235925860_A_Novel_Security_Protocol_for_Resolving_Addresses_in_the_LocationID_Split_Architecture", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [ "round440-sources.json" ], "qualification": "Credit only the historical basic mapping analysis. Its later encrypted exchanges and proposed key-agreement protocol are not selected LISP. Nonce secrecy is a model assertion, not automatically a requirement of RFC 9301; reported model attacks do not establish a current implementation vulnerability. No full-stack audit, validation of registration changes, or formal proof of RFC 9301 is claimed. Academic affiliation establishes disclosed provenance, not an independent investigation of all conflicts of interest. No implementation or runtime test was performed." }, { "id": "E02-IL", "feature": "E02", "stack": "IL", "status": "Y", "reason": "Kadi, Suleiman and Jammoul (HIAST, Damascus), IJERT 10(1), January 2021, sections III and V, analyze ILCC state growth and experimentally attack the St Andrews Linux 4.9 ILNPv6 prototype. Their authorship and institution are distinct from the RFC authors and the assessed implementation team. The experiment exercises network-layer cache allocation using forged correspondent identifiers and reports resource-exhaustion behavior. This is published external experimental security assessment of a native mechanism, using the same bounded rule as E02-ND. RFC 6741 section 5 requires the logical ILCC for ILNP communication, including the selected TCP composition.", "method": "External experimental security assessment; bounded mechanism mapping", "source_label": "Kadi, Suleiman and Jammoul, Caching in ILNP (2021), sections III/V; RFC 6741 section 5", "sources": [ "https://www.ijert.org/research/caching-in-ilnp-identifier-locator-communication-cache-ilcc-implementation-using-three-way-handshake-IJERTV10IS010043.pdf", "https://www.rfc-editor.org/rfc/rfc6741.html#section-5" ], "editorial_references": [ "round639.html" ], "qualification": "Credit the assessment of the St Andrews baseline, not independent validation of the researchers’ own replacement policy. The attack workload uses UDP; its numerical results and exploitability are not transferred to the selected TCP profile or later implementations. The proposed ICMP handshake is not added to this column. This is experimental mechanism analysis, not formal verification or a complete implementation audit. Independence is inferred from disclosed authorship and affiliations, not an investigation of private relationships. No new attack, runtime test, interoperability test or security certification was performed. E01, E03, E04, F15 and G05 remain unchanged." }, { "id": "E02-TS", "feature": "E02", "stack": "TS", "status": "Y", "reason": "Lipp, Blanchet and Bhargavan (INRIA, EuroS&P 2019) publish a mechanised cryptographic analysis of WireGuard handshake and transport messages, with public CryptoVerif models. The selected Tailscale data plane uses this protocol; its pinned wireguard-go dependency identifies Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s. This is independent analysis of a selected security-critical protocol mechanism, not merely of a cipher primitive. E02 accepts bounded mechanism coverage, as already applied to TLS, QUIC and BPSec compositions.", "method": "Published third-party protocol analysis mapped to a pinned selected dependency; no proof rerun", "source_label": "Lipp, Blanchet and Bhargavan, EuroS&P 2019; author-hosted models and Tailscale wireguard-go e61b6b78110b", "sources": [ "https://bblanche.gitlabpages.inria.fr/cryptoverif/WireGuard/", "https://bblanche.gitlabpages.inria.fr/publications/LippBlanchetBhargavanEuroSP19.pdf", "https://tailscale.com/docs/concepts/tailscale-encryption", "https://raw.githubusercontent.com/tailscale/wireguard-go/e61b6b78110b/device/noise-protocol.go" ], "editorial_references": [ "round596.html", "round596-sources.json" ], "qualification": "Protocol-model analysis, not an audit of the current Tailscale fork, managed coordination, DERP, identity-provider enrollment or Tailnet Lock. Model assumptions and compromise cases remain relevant; no post-quantum or secret-PSK guarantee is credited to the selected no-additional-PSK profile. The authors report a Curve25519-model correction in their longer version and provide corrected model artifacts; the conference PDF is retained as historical analysis, not treated as an unqualified current security proof. Proof scripts were not rerun. The authors are distinct from the selected implementation team; the paper acknowledges discussion with the WireGuard designer, not independent certification of the complete product." }, { "id": "E02-RA", "feature": "E02", "stack": "RA", "status": "?", "reason": "Khondoker, Nugraha, Marx and Bayarou published an external survey mapping future-network security mechanisms to threats, including a RINA section. It provides architectural security discussion, but the inspected report does not establish an audit or formal analysis of the selected IRATI security mechanisms.", "method": "Primary documentation and external-report scope inspection; no runtime test", "source_label": "RINA architecture, IRATI and external evidence review", "sources": [ "https://publica-rest.fraunhofer.de/server/api/core/bitstreams/636aa1ac-4428-48a5-a48d-d0f1e97690f6/content" ], "editorial_references": [ "round662.html" ], "qualification": "Find an independent audit or formal analysis with identifiable security policy, assumptions and implementation/protocol version. The survey is retained as a research lead, without importing its threat-mitigation verdicts into this matrix." }, { "id": "E03-PN", "feature": "E03", "stack": "PN", "status": "N", "reason": "The project owner explicitly confirms that the code is intended to be public but has not yet been made available. Announced openness does not meet the criterion of a publicly obtainable complete implementation under OSI-approved licenses.", "method": "Owner-confirmed availability assessment, with separate primary-source IPR policy analysis", "source_label": "Dated project-owner declaration; RFC 8179 section 5.5 for patent-policy distinction", "sources": [], "editorial_references": [ "round355-review.json", "round355-review.json", "round355-sources.json" ], "qualification": "Reassess when an obtainable release, immutable source reference and license manifest cover the selected composition and required components. No inference about private implementation completeness." }, { "id": "E03-PI", "feature": "E03", "stack": "PI", "status": "N", "reason": "The project owner explicitly confirms that the code is intended to be public but has not yet been made available. Announced openness does not meet the criterion of a publicly obtainable complete implementation under OSI-approved licenses.", "method": "Owner-confirmed availability assessment, with separate primary-source IPR policy analysis", "source_label": "Dated project-owner declaration; RFC 8179 section 5.5 for patent-policy distinction", "sources": [], "editorial_references": [ "round355-review.json", "round355-review.json", "round355-sources.json" ], "qualification": "Reassess when an obtainable release, immutable source reference and license manifest cover the selected composition and required components. No inference about private implementation completeness." }, { "id": "E03-IP", "feature": "E03", "stack": "IP", "status": "Y", "reason": "Linux 6.12 provides native IPv4/IPv6/ICMP and multicast host support in public GPL-compatible kernel source. FRR 10.2 supplies public BGP and PIM routing code with its composite GPLv2-or-later distribution terms. This is a complete open software path for the selected native IP stack, not merely a sockets wrapper.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/COPYING", "https://github.com/frrouting/frr/blob/frr-10.2/COPYING", "https://docs.frrouting.org/en/stable-10.2/overview.html" ], "editorial_references": [], "qualification": "The Linux/FRR source and documented open dependencies are the witness; proprietary router firmware is unnecessary. Installation, operational scale and configured policies are separate, and no fresh build was performed." }, { "id": "E03-BP", "feature": "E03", "stack": "BP", "status": "?", "reason": "The pinned HDTN candidate has an explicit outgoing TLS 1.3 selector: useTlsVersion1_3 chooses tlsv13_client when BOOST_VERSION >= 106900. Older builds log a warning and use TLS 1.2 instead. With certificate verification enabled, the outduct loads local CA material, requires peer verification, and checks the configured next-hop EID against id-on-bundleEID (OID 1.3.6.1.5.5.7.8.11); the code also accepts the older URI SAN form. Session initialization separately compares the remote EID with the configured next hop. These close the source-location questions for outgoing version selection and next-hop binding, not complete-profile qualification.", "method": "Source-path and configuration review; no build or runtime execution", "source_label": "Version-pinned HDTN outduct, induct and TCPCL session code", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/outduct_manager/src/TcpclV4Outduct.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/induct_manager/src/TcpclV4Induct.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/tcpcl/src/TcpclV4BidirectionalLink.cpp" ], "editorial_references": [ "round284-sources.json", "round283.html" ], "qualification": "Candidate configuration must enable tryUseTls, tlsIsRequired, useTlsVersion1_3, doX509CertificateVerification and verifySubjectAltNameInX509Certificate, with compatible Boost/OpenSSL and locally supplied trust. The inspected induct configures its server certificate/key and supports TLS 1.2/1.3, but does not configure the corresponding client-certificate verification path; trace and test reciprocal NODE-ID authentication rather than treating session EID parsing as proof. The verification callback checks SANs on each invoked chain certificate, without an explicit leaf-depth condition in this function; qualify the intended local CA chain instead of assuming arbitrary chains work. Test version negotiation, wrong EID, untrusted and missing certificates and no-TLS rejection. Preserve the round 2.83 ION adapter gap. Complete BPSec primary/payload and native delivery-policy mapping remains; CG additionally requires SABR metadata/custody mapping. No wire execution, exploit, universal implementation failure or profile downgrade is claimed." }, { "id": "E03-CG", "feature": "E03", "stack": "CG", "status": "?", "reason": "The pinned HDTN candidate has an explicit outgoing TLS 1.3 selector: useTlsVersion1_3 chooses tlsv13_client when BOOST_VERSION >= 106900. Older builds log a warning and use TLS 1.2 instead. With certificate verification enabled, the outduct loads local CA material, requires peer verification, and checks the configured next-hop EID against id-on-bundleEID (OID 1.3.6.1.5.5.7.8.11); the code also accepts the older URI SAN form. Session initialization separately compares the remote EID with the configured next hop. These close the source-location questions for outgoing version selection and next-hop binding, not complete-profile qualification.", "method": "Source-path and configuration review; no build or runtime execution", "source_label": "Version-pinned HDTN outduct, induct and TCPCL session code", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/outduct_manager/src/TcpclV4Outduct.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/induct_manager/src/TcpclV4Induct.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/tcpcl/src/TcpclV4BidirectionalLink.cpp" ], "editorial_references": [ "round284-sources.json", "round283.html" ], "qualification": "Candidate configuration must enable tryUseTls, tlsIsRequired, useTlsVersion1_3, doX509CertificateVerification and verifySubjectAltNameInX509Certificate, with compatible Boost/OpenSSL and locally supplied trust. The inspected induct configures its server certificate/key and supports TLS 1.2/1.3, but does not configure the corresponding client-certificate verification path; trace and test reciprocal NODE-ID authentication rather than treating session EID parsing as proof. The verification callback checks SANs on each invoked chain certificate, without an explicit leaf-depth condition in this function; qualify the intended local CA chain instead of assuming arbitrary chains work. Test version negotiation, wrong EID, untrusted and missing certificates and no-TLS rejection. Preserve the round 2.83 ION adapter gap. Complete BPSec primary/payload and native delivery-policy mapping remains; CG additionally requires SABR metadata/custody mapping. No wire execution, exploit, universal implementation failure or profile downgrade is claimed." }, { "id": "E03-LT", "feature": "E03", "stack": "LT", "status": "?", "reason": "HDTN 7fbe90c supplies public LtpEncapLocalStreamEngine source: SendPacket wraps each LTP segment using GetCcsdsEncapHeader(ENCAP_PACKET_TYPE::LTP) and writes it to a local stream. LICENSE.md is Apache-2.0. This identifies a concrete open-source LTP/Encapsulation component rather than an unspecified candidate; it does not establish the complete selected BPv7/BPSec/SABR/Encapsulation/AOS implementation or all dependency licenses.", "method": "Source review and evidence reconciliation; no new runtime execution", "source_label": "Pinned HDTN source and retained executed QUIC evidence", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/ltp/src/LtpEncapLocalStreamEngine.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/util/include/EncapAsyncDuplexLocalStream.h", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/tests/test_scripts_linux/test_stcp_to_ltpencap_fast_cutthrough.sh" ], "editorial_references": [ "round287.html", "round287-sources.json" ], "qualification": "Bind an actual AOS virtual-channel packet-service provider and its Encapsulation interface, then map BPv7/BPSec and SABR metadata to the selected all-red LTP composition. The shipped demonstration enters via STCP and leaves via LTP/Encapsulation local sockets; it does not qualify the selected no-IP complete path. The EncapRepeater only forwards encapsulation packets between local streams and is not an AOS frame/channel implementation. Do not infer universal absence of another implementation. Audit required dependency licenses and provider source availability before an E03 Yes." }, { "id": "E03-LP", "feature": "E03", "stack": "LP", "status": "Y", "reason": "go-libp2p v0.43.0 publishes its QUIC transport, identity authentication, host and ConnectionGater interfaces under MIT. Its versioned module manifest selects quic-go v0.54.0, also MIT, with the Go BSD-licensed runtime/TLS and public dependency sources. This supplies the selected native QUIC role without a closed service.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/libp2p/go-libp2p/blob/v0.43.0/LICENSE", "https://github.com/libp2p/go-libp2p/blob/v0.43.0/go.mod", "https://github.com/quic-go/quic-go/blob/v0.54.0/LICENSE", "https://github.com/libp2p/go-libp2p/blob/v0.43.0/p2p/transport/quic/transport.go" ], "editorial_references": [], "qualification": "Public source availability only: no assertion that every optional architectural feature has a new runtime witness. Preserve the existing migration, policy and interoperability scopes; browser WebTransport and pubsub are not substituted." }, { "id": "E03-TO", "feature": "E03", "stack": "TO", "status": "N", "reason": "No for the complete selected composition, which includes onion-service Conflux linking and session resumption. The official onion-service implementation matrix lists Conflux as planned for both C Tor and Arti. The C Tor source explicitly excludes onion-service Conflux; Arti issue 1836 remains open, and the design sketch at commit 3adfc4b052b6520c12f6193c593c5557fa5f3771 explicitly excludes full session resumption from the initial implementation work. These positive implementation-scope statements establish the missing component, rather than merely an unsuccessful source search.", "method": "Documentary implementation-scope assessment; no runtime or exhaustive third-party fork audit", "source_label": "Official implementation matrix, open Arti implementation ticket and pinned C Tor/Arti source documents; reviewed 2026-10-15", "sources": [ "https://onionservices.torproject.org/dev/implementations/", "https://gitlab.torproject.org/tpo/core/arti/-/issues/1836", "https://gitlab.torproject.org/tpo/core/arti/-/blob/3adfc4b052b6520c12f6193c593c5557fa5f3771/doc/dev/notes/conflux-sketch.md", "https://gitlab.torproject.org/tpo/core/tor/-/blob/8dbbbe6e86a6ca0d058ec3c6a4e937859857d7bb/src/core/or/conflux.c" ], "editorial_references": [ "round230-sources.json", "round229-sources.json" ], "qualification": "This does not deny that C Tor and Arti are public open-source implementations of deployed Tor onion services. It denies complete implementation coverage of the richer profile selected in this comparison. General exit Conflux and design-level support do not satisfy this implementation criterion. The matrix is dated 2026-08-19; the ticket and pinned October source were checked separately. Revisit on a concrete implementation of onion-service linking and full resumption, or an explicitly approved profile change. No other Tor capability verdict changes." }, { "id": "E03-I2", "feature": "E03", "stack": "I2", "status": "Y", "reason": "i2pd 2.58.0 publishes the NTCP2 transport, netDB, tunnel, Destination and client API implementation under BSD-3-Clause. Its CMake source declares the public Boost/OpenSSL-based build; a Linux build without optional UPnP supplies the selected transport and local-bootstrap mechanisms. No proprietary I2P engine is required.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/PurpleI2P/i2pd/blob/2.58.0/LICENSE", "https://github.com/PurpleI2P/i2pd/blob/2.58.0/build/CMakeLists.txt", "https://github.com/PurpleI2P/i2pd/blob/2.58.0/README.md" ], "editorial_references": [], "qualification": "Use public Boost/OpenSSL/zlib and Linux/C++ runtime components with their open licenses; preserve notices. This does not select a post-quantum destination type or establish an independent interoperability measurement." }, { "id": "E03-YG", "feature": "E03", "stack": "YG", "status": "Y", "reason": "Public Yggdrasil commit 422836eeb21a99790caa286aa63d493bbc4766d7 explicitly selects Ironwood d50055b11f5ec5b56ee4e56ba9a75261461821dc in go.mod. This closes the revision-binding gap without substituting Ironwood. The source includes core forwarding/encryption integration, TLS 1.3 transport and the Linux TUN adapter. Yggdrasil uses LGPL-3.0 with an additional linking permission; Ironwood and phony use MPL-2.0, gologme/log BSD-3-Clause and the WireGuard TUN dependency MIT. Public Go runtime and module sources supply the remaining software dependencies.", "method": "Documentary review; no new build or runtime experiment", "source_label": "Primary source and versioned dependency review, 2026-10-15", "sources": [ "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/go.mod", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/LICENSE", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/core.go", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/tls.go", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/tun/tun.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/LICENSE", "https://github.com/Arceliar/phony/blob/530938a4b13d/LICENSE", "https://github.com/gologme/log/blob/v1.3.0/LICENSE", "https://github.com/WireGuard/wireguard-go/blob/ecfc5a8d5446/LICENSE" ], "editorial_references": [], "qualification": "Source availability only, not a fresh build, runtime, security or license-compatibility certification. This witness is the pinned commit, not v0.5.12. Earlier version-scoped findings are not automatically requalified; selected TCP/TLS and Linux roles are retained, without Windows or optional QUIC transport claims." }, { "id": "E03-CJ", "feature": "E03", "stack": "CJ", "status": "Y", "reason": "A public implementation witness is the pinned cjdns client f5902ac on Linux ARM32 together with the replicated Rust route server 46c9c1b on Linux. Earlier source mapping established matching route-query, signed-announcement, state-hash and reset interfaces. The two exceptional entries in the 413-version registry license inventory are target-specific: BoringTun f288b2f enables ring only when target_arch is not arm; its ARM32 data path instead uses the included BSD-3-Clause ChaCha20Poly1305 implementation and a /dev/urandom wrapper. The server constant_time_eq 0.1.5 chain is reached through Redox-only dirs-sys/redox_users dependencies, not the Linux configuration. The remaining registry entries offer OSI-approved licensing options. Required Git components have GPL-3.0, MIT/Apache or BSD notices. Both pinned sodiumoxide revisions reference the same native libsodium submodule 8acd22717f6af798b1ed5fd275e2b4c789425cf5, whose actual license is ISC. The native cjdns build uses that source; its legacy-named event wrappers call the Rust interface rather than requiring an unaccounted libuv implementation. These public sources cover the selected protocol functions without an editorial code patch.", "method": "Documentary selected-function and target-specific license coverage", "source_label": "Pinned cjdns/BoringTun/route-server source, target guards, registry inventory and native libsodium submodule license", "sources": [ "https://github.com/cjdelisle/cjdns/tree/f5902acab6dd2f1a68bf6e4c89e352ed71f93698", "https://github.com/CJDNS-Development-Team/CJDNS/tree/46c9c1b6828f746f00733c10d8e82c5295107514" ], "editorial_references": [ "round635.html", "round635-sources.json", "round439-sources.json" ], "qualification": "E03 credits documentary source availability and license coverage for this target-specific witness, not a newly executed ARM build or interoperability test. ARM32 means Rust target_arch=arm, not aarch64. The existing x86 client candidate retains ring with legacy OpenSSL/SSLeay sources and is not the licensing witness used for this Yes. The score does not relabel CC0 as OSI-approved, claim identical announcement lists at all times, or certify cryptography, global scale, runtime behavior or every redistribution obligation. Dependency review reuses the retained 413-version inventory and inspects target guards, Git notices and native-source provenance; no fresh full binary/link-map audit was performed. The protocol column remains unchanged; this is an identified implementation configuration, not a new cipher or routing design." }, { "id": "E03-MQ", "feature": "E03", "stack": "MQ", "status": "?", "reason": "A private editorial policy harness now pins the client SubjectPublicKeyInfo SHA-256 while retaining the OpenSSL certificate/signature verifier. Two live mutually authenticated multipath connections, in separate server contexts, each received 10,142 bytes of an unfinished 2 MB upload. After policy revocation and explicit connection enumeration/close, both endpoints disconnected and neither server application received additional bytes. Fresh attempts with the revoked key and with a valid certificate whose key was outside the allowlist both failed with TLS access_denied (QUIC crypto error 305). A fresh relink with a retained linker map now identifies 84 extracted archive objects: 58 picoquic test/log/core objects, 22 Picotls Minicrypto objects, three Picotls core objects and one OpenSSL adapter. Minicrypto includes Cifra and micro-ecc; it cannot be omitted from this binary inventory simply because the test uses OpenSSL verification. Fusion and picohttp archives were offered but contributed no extracted members. ELF dependencies are libcrypto.so.3 and libc.so.6.", "method": "Rebuilt unchanged harness with linker map; documentary dependency inventory, not a new traffic test", "source_label": "Pinned source notices, CMake provenance, actual ELF/linker map and installed package copyright records", "sources": [ "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquic/tls_api.c", "https://github.com/h2o/picotls/blob/f06553b877ada93c860dd1db9002eabf7365292d/CMakeLists.txt", "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/LICENSE", "https://github.com/openssl/openssl/blob/openssl-3.0.13/LICENSE.txt" ], "editorial_references": [ "round296-runtime.json", "round296-sources.json", "round296_policy.c", "round297-inventory.json", "round297-sources.json" ], "qualification": "E03 remains Pending: the private policy harness is not an already public complete selected implementation. Dependency provenance is now concrete: picoquic repository MIT with individual ISC-style permission notices, Picotls MIT, Cifra CC0/public-domain notices, micro-ecc BSD-2-Clause, OpenSSL Apache-2.0 and glibc package notices (mostly LGPL-2.1-or-later). Public-domain dedication is not mislabeled as an OSI-approved license. This is not an exhaustive redistribution audit: transitive headers, generated/toolchain objects and full notice obligations remain outside the inventory. Static inclusion does not prove which provider negotiated the session. The round296 limits remain: simulated links, fixture certificates, UID 0, two server contexts, no selective multi-identity/concurrent revocation or application-owned queue cancellation. Preserve positive multipath limits and the draft-21 zero-limit deviation; no hybrid suite is silently selected." }, { "id": "E03-SC", "feature": "E03", "stack": "SC", "status": "Y", "reason": "SCION v0.12.0, commit e6b0576682c73845a185f14ea68e8b0923374874, publishes the router, control service, dispatcher, daemon, endpoint tools and local PKI tools under Apache-2.0. Its README gives a Go source-build command for the deployment binaries; go.mod identifies the public Go, crypto, RPC and database dependencies. This supplies a complete open software path for the selected IPv4/UDP-underlay, SCION/UDP role with locally provisioned topology and trust; no proprietary Anapaya appliance is mandatory.", "method": "Documentary source and dependency review; no new execution", "source_label": "Versioned primary repositories and official documentation, 2026-10-15", "sources": [ "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/LICENSE", "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/README.md", "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/go.mod", "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/pkg/snet", "https://docs.scion.org/en/v0.12.0/overview.html" ], "editorial_references": [], "qualification": "Source-availability finding only: no new build, runtime, interoperability or dependency-license compatibility audit. Go and component licenses/notices remain applicable. This witness does not replace the separately scoped JPAN D01 witness or add end-to-end TLS, production provisioning or a security certification. Optional gateway features and test tooling are not needed for this role." }, { "id": "E03-RT", "feature": "E03", "stack": "RT", "status": "Y", "reason": "LXMF-rs v0.13.0 provides publicly obtainable native Rust Reticulum transport and core implementations under EPL-2.0 with a GPL-2.0-or-later secondary-license option. Source coverage includes raw serial HDLC with secret IFAC, Link identification and recursive path requests dispatched by transport nodes. The library initializes routing/cache state in memory and makes persistence explicit; the selected private tmpfs host policy can also contain configuration/state files. The pinned 1.5.5 delta ledger and exact-tag Link download evidence support a bounded compatibility mapping: the documented remaining gaps concern discovery auto-connect, live virtual-child pacing and Python-specific request-receipt API states, not missing implementation of the selected serial Link composition. The published lockfile contains 247 package records; registry license metadata was obtained for all of them, including reticulum-rs-core, with OSI-approved licensing options throughout. E03 requires an available implementation covering the selected functions, not official reference status or an independently executed interoperability test.", "method": "Selected-function source mapping and documentary license coverage", "source_label": "Pinned LXMF-rs v0.13.0 source, compatibility ledger, repository license and complete published-lockfile license inventory", "sources": [ "https://github.com/FreeTAKTeam/LXMF-rs/tree/fbc75b86e15550722923b366398f0a4116182894", "https://opensource.org/licenses" ], "editorial_references": [ "round633.html", "round633-sources.json" ], "qualification": "Documentary implementation-availability decision, not a fresh build, full Python API parity, security audit or raw-HDLC interoperability certificate. The dependency inventory includes optional, development and other-platform packages; it is a conservative lockfile inventory, not a resolved Linux build graph or legal provenance audit. Registry license declarations and repository license text are the licensing evidence. Cargo metadata could not run with the installed older Cargo because the upstream lockfile uses version 4; no successful build is claimed. E01-RT remains Pending: the exact-1.5.5 TCP download and separate KISS/IFAC and identification tests do not establish one executed selected serial profile. The Python reference license is unchanged; this Yes rests on the independent Rust implementation. No LXMF application, IP carrier or local TCP sharing is added to the selected profile." }, { "id": "E03-NS", "feature": "E03", "stack": "NS", "status": "Y", "reason": "The selected nostr-rs-relay commit publishes the NIP-01 relay and SQLite implementation under MIT, with a public Cargo dependency manifest. A complete open source path includes go-nostr v0.9.0 (MIT) for event signing, verification and multiple WSS relays, and nginx 1.26.3 (BSD-2-Clause) with OpenSSL for TLS 1.3 and HTTP Upgrade proxying. The Go/Rust runtimes, WebSocket and secp256k1 libraries and bundled SQLite are public-source components. Thus the selected relay need not rely on a proprietary client or TLS service.", "method": "Documentary classification; no new build or runtime experiment", "source_label": "Versioned primary-source review, 2026-10-15", "sources": [ "https://github.com/scsibug/nostr-rs-relay/blob/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/LICENSE", "https://github.com/scsibug/nostr-rs-relay/blob/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/Cargo.toml", "https://github.com/scsibug/nostr-rs-relay/blob/b5c1f642e4f4c3b9c54f5d18d66f4c53642076b4/README.md", "https://github.com/nbd-wtf/go-nostr/blob/v0.9.0/LICENSE.md", "https://github.com/nbd-wtf/go-nostr/blob/v0.9.0/README.md", "https://github.com/nbd-wtf/go-nostr/blob/v0.9.0/event.go", "https://github.com/nbd-wtf/go-nostr/blob/v0.9.0/relaypool.go", "https://github.com/nginx/nginx/blob/release-1.26.3/LICENSE", "https://nginx.org/en/docs/http/websocket.html", "https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols" ], "editorial_references": [], "qualification": "Public source availability only; no fresh composed build, interoperability or deployment certification. Preserve the selected in-memory relay and host no-retention conditions, disable proxy persistence as previously required, and select TLS 1.3 explicitly. The nginx example is a source witness for the already selected WSS layer, not an added protocol or public deployment. Optional NIPs are not credited; SQLite is public domain and other components retain their own notices." }, { "id": "E03-MT", "feature": "E03", "stack": "MT", "status": "Y", "reason": "The pinned public Meshtastic firmware and native Portduino implementation cover the selected source-level composition under open-source licenses. The earlier 63-package inventory is now reconciled with 49 declared library.properties dependency edges: each maps to an inventoried package or the native display-library exclusion; CH341/libusb and the pinned LGPL WiFi submodule are accounted for separately. The source exposes a headless configuration without disabling PKI: MESHTASTIC_EXCLUDE_SCREEN forces HAS_SCREEN to zero, leaving niche graphics undefined excludes MessageStore, and MESHTASTIC_EXCLUDE_STOREFORWARD excludes that module. The earlier source reviews identify native real-LoRa routing, PKI/STRICT, local admission controls, independent MAC/state contexts and host-backed VFS. Firmware GPL, Portduino LGPL, platform Apache and the inspected MIT/BSD/GPL/LGPL library sources provide an open implementation candidate rather than just a specification or partial demo. A new firmware build or RF experiment is not a prerequisite of this source-availability criterion.", "method": "Documentary source and dependency-closure assessment; no firmware compilation or RF execution", "source_label": "Pinned Meshtastic/Portduino implementation, dependency manifests and license notices; reviewed 2026-10-15", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/configuration.h", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/MessageStore.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/MessageStore.h", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/modules/Modules.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/CryptoEngine.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/variants/native/portduino.ini" ], "editorial_references": [ "round232-sources.json", "round231-sources.json", "round229-sources.json", "round122-sources.json", "round131-sources.json" ], "qualification": "Yes concerns availability of the open-source implementation, not successful execution of every configured behavior. Keep the selected headless F16 variant explicit: exclude screen and store-forward, disable message persistence, leave niche graphics and global minimize/PKI exclusions undefined. Preserve private-channel/STRICT and local KNOWN_ONLY/key provisioning for that separate witness; ordinary CLIENT/ALL remains the C04 scope. The 49-edge reconciliation covers declared library metadata, not every conditional include or an independently certified SBOM. Host libraries and build tools remain necessary; no new claim of a frozen reproducible build, license-compliance certification, independent interoperability, benchmark or real-radio qualification is made. Existing per-cell runtime acceptance tests, including revocation cutover and volatile VFS checks, remain outstanding." }, { "id": "E03-GN", "feature": "E03", "stack": "GN", "status": "Y", "reason": "The public GNUnet 0.20.0 release includes UDP transport, CORE, R5N/DHT and CADET services under AGPL-3.0-or-later, with its required public GNU/crypto/database libraries. The selected direct UDP, known-HELLO role needs no proprietary naming, VPN or relay service.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://ftpmirror.gnu.org/gnunet/gnunet-0.20.0.tar.gz", "https://www.gnu.org/licenses/agpl-3.0.html" ], "editorial_references": [], "qualification": "The archive contains COPYING, dependency instructions and service sources; selected components were already traced in earlier rounds. AGPL obligations apply. Alpha maturity, restart qualifications and unexecuted integration checks remain unchanged." }, { "id": "E03-ND", "feature": "E03", "stack": "ND", "status": "Y", "reason": "NFD 24.07 and ndn-cxx 0.9.0 publish the forwarding, direct-Ethernet/Unix faces, ECDSA signing and configured-anchor validation code under GPL-3.0-or-later for NFD and LGPL-3.0-or-later for ndn-cxx. The documented Linux build uses public Boost, OpenSSL, SQLite and libpcap sources; no proprietary protocol engine is required.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/named-data/NFD/blob/NFD-24.07/COPYING.md", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/COPYING.md", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/docs/INSTALL.rst", "https://docs.named-data.net/NFD/24.07/INSTALL.html", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/COPYING.lesser" ], "editorial_references": [ "round607-sources.json" ], "qualification": "GPL/LGPL components with Boost Software License, OpenSSL 3 Apache-2.0, public-domain SQLite and BSD libpcap components. Optional platform integrations are not needed. This does not resolve runtime privileges or performance." }, { "id": "E03-AX", "feature": "E03", "stack": "AX", "status": "Y", "reason": "Linux 6.12 publicly supplies the selected classic NET/ROM-over-AX.25 implementation, including the native socket and routing code, under GPL-compatible kernel terms (the NET/ROM source declares GPL-2.0-or-later). This supplies an open implementation of the private serial role; executable configuration and physical serial testing remain unqualified.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/af_netrom.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/COPYING" ], "editorial_references": [], "qualification": "Use the existing Linux source witness and its stock serial/AX.25 support. No RF test or regulator approval inferred." }, { "id": "E03-BA", "feature": "E03", "stack": "BA", "status": "Y", "reason": "The complete selected Linux 6.12 BATMAN_IV/batman-adv implementation is publicly distributed in the kernel source under GPL-2.0, with source-level license identifiers and the kernel COPYING terms. The selected native Ethernet service needs no proprietary protocol implementation. Source availability is not a new interoperability or execution result.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/main.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/COPYING", "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "" }, { "id": "E03-BL", "feature": "E03", "stack": "BL", "status": "Y", "reason": "The official babeld 1.13.1 release archive includes the previously unavailable rfc6234 source: sha.h and the SHA implementation carry the IETF BSD-style three-clause grant. Together with babeld MIT, BLAKE2 Apache-2.0 option, Linux GPL-2.0 and the GNU C runtime, this closes the source/license witness for IPv6/Babel.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://www.irif.fr/~jch/software/files/babeld-1.13.1.tar.gz", "https://github.com/jech/babeld/blob/3d61ea1e843e2c5f9706c74d1adad4e1d24d44b9/LICENCE", "https://github.com/jech/babeld/blob/3d61ea1e843e2c5f9706c74d1adad4e1d24d44b9/Makefile" ], "editorial_references": [], "qualification": "The release archive, not a failed GitHub submodule lookup, supplies the missing code. This is source availability, not a new build or legal compatibility audit of arbitrary distributions." }, { "id": "E03-RI", "feature": "E03", "stack": "RI", "status": "?", "reason": "New approved IPv6 IoT / RPL composition. No verdict is inherited from plain IP or another selected stack. Assess the explicit 6LoWPAN, routing, UDP and end-to-end DTLS profile together.", "method": "Column registration and research inventory", "source_label": "Primary standards for the declared composition; no new implementation qualification", "sources": [ "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc4944.html", "https://www.rfc-editor.org/rfc/rfc6282.html", "https://www.rfc-editor.org/rfc/rfc8200.html", "https://www.rfc-editor.org/rfc/rfc6552.html", "https://www.rfc-editor.org/rfc/rfc6554.html", "https://www.rfc-editor.org/rfc/rfc6775.html", "https://www.rfc-editor.org/rfc/rfc768.html", "https://www.rfc-editor.org/rfc/rfc9147.html", "https://www.rfc-editor.org/rfc/rfc8446.html" ], "editorial_references": [ "round244.html#iot-rpl" ], "qualification": "Locate public code, exact version, license texts, dependencies and supported profile scope. A private checkout or absent implementation files in a specification mirror does not decide public availability. Preserve the declared PSK-only DTLS, RPL mode and leaf/forwarder roles; do not substitute a cloud broker or an application-security layer." }, { "id": "E03-HP", "feature": "E03", "stack": "HP", "status": "?", "reason": "The December 2025 Linkoping project report supersedes treating the 2024 ECDSA failure as the latest candidate evidence. Section 4.1 reports PyHIP using ECDSA/SHA-384 with AES-256-GCM. Section 4.2 separately reports OpenHIP/OpenSSL provider integration and algorithm tests, and asserts base-exchange/ESP support. These are different implementation tracks; their results cannot be combined into one demonstrated profile.", "method": "Newer primary developer report, implementation-track and selected-suite comparison; no execution", "source_label": "Rosengren, Amin, Kanefall and Sohail, Improving the Open Source HIPv2 Implementation, 17 December 2025, sections 4.1 and 4.2", "sources": [ "https://www.ida.liu.se/~TDDE21/info/hip_report_2025.pdf", "https://www.ida.liu.se/~TDDE21/info/hip_report_2024.pdf", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/util/hitgen.c", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/linux/hip_linux_umh.c", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/include/hip/hip_proto.h", "https://www.ida.liu.se/~TDDE21/info/hip_report_2025.pdf" ], "editorial_references": [ "round270-sources.json", "round428-sources.json", "round444-sources.json", "round444.html" ], "qualification": "Pending: bind a public code revision and license/dependency inventory to ECDSA P-256, ECDH P-256, HIT suite 2, ESP transform 8 and RFC 8046 mobility together. The report does not supply that exact complete binding. Its OpenSSL algorithm/provider results alone do not establish the selected HIP composition; its PyHIP GCM witness does not establish the selected CBC transform. The old failure is historical, not evidence that current ECDSA support is absent." }, { "id": "E03-CX", "feature": "E03", "stack": "CX", "status": "?", "reason": "The original PARC Libccnx-common repository was checked independently of the FD.io fork. At commit 69d39e0, DictionaryEncode also leaves signer attachment commented out, and the crypto-suite conversion also leaves EcSecp256K1 unsupported. Thus selecting this upstream snapshot does not remove the concrete ECDSA integration gaps found in the first candidate.", "method": "Documentary profile-boundary and source-path analysis; no execution", "source_label": "Primary RFCs and pinned PARC upstream source", "sources": [ "https://raw.githubusercontent.com/PARC/Libccnx-common/69d39e04b528ae703c1061bd597ce92bf8ea3b57/ccnx/common/codec/schema_v1/ccnxCodecSchemaV1_CryptoSuite.c", "https://raw.githubusercontent.com/PARC/Libccnx-common/69d39e04b528ae703c1061bd597ce92bf8ea3b57/ccnx/common/codec/schema_v1/ccnxCodecSchemaV1_PacketEncoder.c" ], "editorial_references": [ "round274-sources.json" ], "qualification": "The complete selected ECDSA-SHA256 profile remains unqualified. This bounded inspection of two related code lines is not an exhaustive absence proof or a runtime failure. Locate a working native encoding/verification path, its exact wire curve and all required licenses before crediting a complete implementation. No RSA substitution or source repair is counted as an existing implementation." }, { "id": "E03-LI", "feature": "E03", "stack": "LI", "status": "Y", "reason": "The pinned Apache-2.0 lispers.net implementation provides ITR, ETR, Map-Resolver and Map-Server sources and declares RFC 9300/9301 support. Its configuration reference provides numeric addresses, EID prefixes and local authentication keys for the selected composition. The Python 3 recipe identifies its required packages; direct/default-runtime dependencies have published source distributions and open-license metadata. Direct source-license checks confirm BSD-3-Clause for cheroot and curve25519-donna and MIT for python-pytun. This is sufficient documentary evidence of publicly obtainable open-source implementation, without requiring a successful local build.", "method": "Pinned implementation, configuration and public dependency-source review", "source_label": "lispers.net source/configuration; published package sources and license records", "sources": [ "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/README.md", "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/LICENSE", "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/lisp/README", "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/build/Dockerfile", "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/docs/lisp-config-commands.txt", "https://pypi.org/project/cheroot/11.1.2/", "https://pypi.org/project/python-pytun/2.4.1/", "https://pypi.org/project/curve25519-donna/1.3/" ], "editorial_references": [ "round387-dependencies.json", "round387-license-checks.json" ], "qualification": "No installation, complete SBOM audit, compatible dependency lock, conformance test or independent interoperability result is claimed. The dependency-source inventory uses current package metadata rather than resolving all version constraints. OS/toolchain sources and open licenses are supporting platform dependencies, not a reproduced build. Other optional LISP features are not silently added to the selected profile." }, { "id": "E03-IL", "feature": "E03", "stack": "IL", "status": "?", "reason": "The pinned public glibc companion repository contains a patch only to nss/nss_files/files-hosts.c. Its instructions explicitly use /etc/hosts for I-LV resolution. This confirms that the older source release does not, by itself, supply the selected DNS NID/L64 discovery. The newer DNS-enabled FreeBSD release remains documented as binaries.", "method": "Pinned source-tree and release-instruction review", "source_label": "ilnp-glibc-1 tree c815f2d3d77146b4a33cd6178a9008f4b1a14630", "sources": [ "https://github.com/ilnp/ilnp-glibc-1/blob/c815f2d3d77146b4a33cd6178a9008f4b1a14630/README-glibc_patch", "https://github.com/ilnp/ilnp-glibc-1/blob/c815f2d3d77146b4a33cd6178a9008f4b1a14630/README.md", "https://ilnp.cs.st-andrews.ac.uk/freebsd/20260718-ietf126_hackathon/" ], "editorial_references": [], "qualification": "Locate matching public source and licenses for the DNS-enabled release, or another complete selected-profile implementation. This is not a claim that no such source exists; it records the concrete gap in the public repository inspected." }, { "id": "E03-TS", "feature": "E03", "stack": "TS", "status": "N", "reason": "Linux client and DERP code are open source, but the selected hosted coordination server is proprietary. Public client code therefore does not cover all necessary implementation components of this managed profile.", "method": "Official implementation and installation documentation review", "source_label": "Tailscale Linux installation and open-source component inventory", "sources": [ "https://tailscale.com/opensource" ], "editorial_references": [ "round584.html", "round584-sources.json" ], "qualification": "Selected standard Linux TUN and managed-control profile only. Headscale, tsnet and userspace proxy mode are different compositions. Documentary assessment, not a runtime test." }, { "id": "E03-RA", "feature": "E03", "stack": "RA", "status": "Y", "reason": "IRATI publicly supplies the Linux implementation of normal DIFs and the Ethernet shim, together with user-space libraries, management daemons, routing policies and build instructions. Component license files and source headers identify GPL v2 and LGPL v2.1 families, both OSI-approved. This establishes an obtainable open-source implementation for the selected composition.", "method": "Public source-tree, license-file and component-header inspection", "source_label": "IRATI public implementation and component licenses at pinned commit", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/LICENSE", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/LICENSE", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rina-tools/LICENSE", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/rmt.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/kernel/ipcps/shim-eth-core.c", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/default/routing-ps.cc", "https://opensource.org/license/gpl-2.0", "https://opensource.org/license/lgpl-2-1" ], "editorial_references": [ "round655.html" ], "qualification": "Source-availability assessment pinned to IRATI commit 726b535c908f8a74e8c68dd493cfbb1bd8726546. The inspected kernel RMT and Ethernet shim use GPL-2.0-or-later; librina carries LGPL-2.1, rinad and tools GPL-2.0 license texts, and the inspected default routing policy has an LGPL-2.1-or-later header. File-specific and bundled third-party notices remain applicable. No build, runtime qualification, security-suite validation or independent interoperability test was performed." }, { "id": "E04-PN", "feature": "E04", "stack": "PN", "status": "N", "reason": "The owner states that no third party had published about PRP as of 2026-10-16. This directly supports No for independently published quantitative measurements, also under revised E04.", "method": "Owner-confirmed availability assessment, with separate primary-source IPR policy analysis", "source_label": "Dated project-owner declaration; RFC 8179 section 5.5 for patent-policy distinction", "sources": [], "editorial_references": [ "round355-review.json", "round355-review.json", "round355-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Author-run experiments are not independent measurements. Reassess when an external party publishes a relevant scenario, method and quantitative results; exact binary pins and replay artifacts are optional." }, { "id": "E04-PI", "feature": "E04", "stack": "PI", "status": "N", "reason": "The owner states that no third party had published about PRP as of 2026-10-16. This directly supports No for independently published quantitative measurements, also under revised E04.", "method": "Owner-confirmed availability assessment, with separate primary-source IPR policy analysis", "source_label": "Dated project-owner declaration; RFC 8179 section 5.5 for patent-policy distinction", "sources": [], "editorial_references": [ "round355-review.json", "round355-review.json", "round355-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Author-run experiments are not independent measurements. Reassess when an external party publishes a relevant scenario, method and quantitative results; exact binary pins and replay artifacts are optional." }, { "id": "E04-IP", "feature": "E04", "stack": "IP", "status": "Y", "reason": "RIPE Atlas publishes ICMP echo measurements with timestamped RTT samples and repeatable measurement definitions. Retrieved measurement 1001 records IPv4 ping, a 240-second interval and three packets; retained public anchor results identify firmware 5130, measurement version 2.6.4, packet size 32, source/destination addresses and individual RTTs. Anchors 6251, 6313 and 6316 each report three replies; their source addresses equal their public reporting addresses. This is external measured IP/ICMP behavior with inspectable inputs and results, not a theoretical header calculation.", "method": "Primary documentary evidence review; no new protocol execution", "source_label": "Evidence checked 2026-10-15; versions and hashes in round234-sources.json", "sources": [ "https://atlas.ripe.net/api/v2/measurements/1001/", "https://atlas.ripe.net/docs/apis/measurement-result-format/" ], "editorial_references": [ "round234-atlas-results.json", "round234-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Credit published ICMP RTT evidence only. Neither low RTT nor the absence of a source-address mismatch proves a particular path, absence of all middleboxes, global-scale capacity or the full selected profile. API reads retrieved existing results; no probe traffic was scheduled. The RTT values are not comparisons against PRP and do not resolve G05 or F15." }, { "id": "E04-BP", "feature": "E04", "stack": "BP", "status": "Y", "reason": "Li and Hesselbach (UPC, 2026) report executed measurements of DTN7-rs 0.21.0 and NASA ION 4.1.3s. Three Linux hosts, a 100 Mbps link, controlled delay, file workloads and five repetitions are described. Figures 5–8 publish transfer, timing and delivery-completion results. The UPC measurement authors are distinct from the named existing implementation providers. This supplies external quantitative evidence for the shared BPv7 bundle-delivery mechanism under revised E04.", "method": "Revised E04 documentary assessment of executed bundle delivery", "source_label": "Li and Hesselbach, Applied Sciences 2026: external BPv7 measurements", "sources": [ "https://doi.org/10.3390/app16178614", "https://www.mdpi.com/2076-3417/16/17/8614" ], "editorial_references": [ "round624.html", "round624-sources.json" ], "qualification": "The experiment does not establish performance of the selected TLS/BPSec composition. No security overhead, disruption recovery, custody, CGR route selection or global capacity is credited. In particular, the paper’s custody terminology is not adopted as a BPv7 property. Throughput definitions differ across protocol families; their numerical ranking is not imported. The study concerns controlled delay rather than a loss/disruption campaign. Independence is based on disclosed authorship and use of existing implementations, not an exhaustive contributor audit. No experiment was rerun." }, { "id": "E04-CG", "feature": "E04", "stack": "CG", "status": "Y", "reason": "Hou, Zhao, Li and Du (Nanjing University, 2022) execute ION-DTN in an external container-based emulation platform. Section 5.3 describes four nodes, a contact plan and ten 50 kB bundles. Figure 13 and the results record six bundles delivered through a gateway and four through a later direct contact, with explicit contact times. This is quantitative observation of delivery using CGR and scheduled links, rather than an analytical route model alone. The platform authors measure the existing ION routing implementation; revised E04 accepts this bounded shared-mechanism evidence.", "method": "Revised E04 documentary assessment of executed contact-plan routing", "source_label": "Hou et al., Electronics 2022, external ION contact-plan experiment", "sources": [ "https://doi.org/10.3390/electronics11081236", "https://www.mdpi.com/2079-9292/11/8/1236" ], "editorial_references": [ "round625.html", "round625-sources.json" ], "qualification": "This small, negligible-loss scenario measures routing and delivery jointly, not isolated CGR CPU cost. Exact ION revision and modern SABR equivalence are not established. No security-profile, current-version, global-scale or comparative-speed result is inferred. The study reproduces an earlier scenario on its own platform; it is not an independent protocol implementation. Independence rests on disclosed Nanjing authorship and use of existing ION software, not an exhaustive contributor audit. No new experiment was run." }, { "id": "E04-LT", "feature": "E04", "stack": "LT", "status": "Y", "reason": "Ding Wang, Ethan Wang and Ruhai Wang publish measurements of ION 4.1.1 on a three-PC cislunar relay testbed. Table 1 identifies Fedora 38, 100% red LTP data, segment and buffer settings, link delays/error rates and 16 repetitions. Numerical goodput results measure the existing reliable LTP transfer mechanism. Author affiliations are outside JPL, which is credited for the implementation; the study declares no conflict of interest.", "method": "Revised E04 documentary assessment of existing implementation measurements", "source_label": "External Sensors 2025 cislunar testbed study, Table 1 and Sections 5–7", "sources": [ "https://doi.org/10.3390/s25010195", "https://pmc.ncbi.nlm.nih.gov/articles/PMC11723082/" ], "editorial_references": [ "round619.html", "round619-sources.json" ], "qualification": "The study uses UDP/IP/PPP and mixed convergence-layer paths, not our Encapsulation/AOS binding. Credit external measurements of all-red LTP only, not BPSec, AOS, complete selected-stack performance or mission conformance. Link disruption was not introduced. The paper acknowledges uncontrolled UDP congestion loss as a testbed artifact. Discussions with protocol developers are disclosed; independence means external execution of the existing implementation, not absence of technical contact. No new experiment or exhaustive affiliation audit." }, { "id": "E04-LP", "feature": "E04", "stack": "LP", "status": "Y", "reason": "Kasyanchuk (2026), author of the competing librats implementation, reports external js-libp2p 3.3.8 measurements with hardware, Node version, TCP/Noise configuration, loopback workload, pacing and three-run median method. Quantitative results include memory and transfer behavior. Tong (2023) separately publishes rust-libp2p perf commands and byte/time results for loopback transfers with controlled delay or loss. These measure executed libp2p peer connections and streams. The connection specification establishes the shared reliable, bidirectional stream abstraction across TCP and QUIC transports. Under the revised E04 definition, this is evidence of independent quantitative measurement of a relevant protocol mechanism.", "method": "Revised E04 documentary assessment; shared stream mechanism, transport-scoped evidence", "source_label": "External js-libp2p and rust-libp2p measurements; libp2p connection specification", "sources": [ "https://blog.degitx.com/blog/librats-vs-libp2p/", "https://quantonganh.com/posts/2023/10/27/libp2p-perf-benchmark/", "https://github.com/libp2p/specs/blob/master/connections/README.md" ], "editorial_references": [ "round623.html", "round623-sources.json" ], "qualification": "The measured stacks use TCP, not the selected go-libp2p QUIC/TLS stack. Shared stream semantics justify relevance, not numerical transferability: transport, security, multiplexing, language and implementation costs differ. No QUIC, migration, ConnectionGater or post-quantum performance is inferred. Kasyanchuk has an explicit commercial/competitive interest; his libp2p baseline is external to libp2p, not a neutral ranking. Tong presents an external user experiment; no exhaustive contributor audit is claimed. Small loopback studies do not establish Internet performance, scale or statistical robustness. E04 records availability of published measurements, not favorable performance. No benchmark was rerun." }, { "id": "E04-TO", "feature": "E04", "stack": "TO", "status": "Y", "reason": "Dhungel, Steiner, Rimac, Hilt and Ross, Waiting for Anonymity: Understanding Delays in Tor, report an instrumented experiment through public Tor relays. Ten probes per reachable relay and timestamp/network-latency measurements expose cell transit delay. The study describes setup, sampling and numerical results; the shared measured mechanism is Tor relay cell forwarding.", "method": "Revised E04 documentary assessment; no runtime experiment", "source_label": "External academic measurement study of an existing implementation", "sources": [ "https://cse.engineering.nyu.edu/~ross/papers/Tor.pdf" ], "editorial_references": [ "round618.html", "round618-sources.json" ], "qualification": "The NYU/Bell Labs authors are external to the Tor implementation authors. Their instrumented client uses two-hop circuits and an exit, not the selected authorized v3 onion service. Credit relay transit measurements only: no onion-service rendezvous, authorization, Conflux, present-day latency or complete selected-profile benchmark. Probe failures and historical sampling limit representativeness; inferred queuing delay depends on the stated latency subtraction. No new experiment or exhaustive affiliation audit." }, { "id": "E04-I2", "feature": "E04", "stack": "I2", "status": "Y", "reason": "Wang et al. publish quantitative I2P experiments with a described VPS/host environment, controlled routers and services, and a method for observing online behavior. The external study supplies method and results for a relevant I2P mechanism rather than promotional performance numbers. Revised E04 does not require the exact builds of their customized Java and C++ routers.", "method": "Reassessment under owner-approved independent-measurement criterion; no new execution", "source_label": "Wang et al., extended I2perception paper, sections V and appendices B/E", "sources": [ "https://arxiv.org/html/2512.15510v1" ], "editorial_references": [ "round299-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Credit the existence of external online-behavior measurements only. The public-network/custom-router study is not an NTCP2-only private-bootstrap experiment and does not establish the selected profile’s vulnerability, anonymity guarantees or throughput. Custom research instrumentation is distinguished from authorship of the evaluated I2P implementations." }, { "id": "E04-YG", "feature": "E04", "stack": "YG", "status": "Y", "reason": "Moritz Warning’s separately maintained meshnet-lab publishes a scenario, method and raw measurements. The reviewed grid CSV has 30 observations on 49 emulated nodes, each with 200 probes after an increasing startup delay. The measured mechanism is route convergence and packet delivery. This qualifies under revised E04; exact reproduction of the selected configuration is not required. The report identifies Yggdrasil 0.5.2. At the last recorded delay of 58 seconds the CSV reports 200 of 200 replies.", "method": "Revised E04 documentary reassessment; CSV consistency and provenance review, no runtime experiment", "source_label": "External meshnet-lab campaign, retained raw CSV and implementation attribution review", "sources": [ "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/convergence1/convergence1-yggdrasil-grid4.csv", "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/README.md" ], "editorial_references": [ "round609.html", "round610.html", "round616.html", "round616-sources.json" ], "qualification": "The experiment uses automatic discovery rather than the selected numeric IPv4/TLS peers. Credit Yggdrasil routing and endpoint delivery, not TLS-specific overhead or the exact pinned Ironwood revision. The generic launcher’s incomplete -useconffile argument remains a reproduction discrepancy; published results are not silently described as an editorial replay. Independent attribution rests on the external comparative laboratory and distinct implementation maintainers. The reviewed GitHub contributor lists contain no mwarning entry (Yggdrasil 51, cjdns 188, batman-adv mirror 113 entries); this supports attribution but is not proof of no affiliation or an exhaustive identity/conflict audit. Network-namespace emulation and historical configuration constrain applicability. The README’s linked driver is a Yggdrasil-only variant; the general multi-protocol driver was recovered in round609. No new benchmark, cross-protocol ranking, global-scale conclusion or current-version guarantee is claimed." }, { "id": "E04-CJ", "feature": "E04", "stack": "CJ", "status": "Y", "reason": "Moritz Warning’s separately maintained meshnet-lab publishes a scenario, method and raw measurements. The reviewed grid CSV has 30 observations on 49 emulated nodes, each with 200 probes after an increasing startup delay. The measured mechanism is route convergence and packet delivery. This qualifies under revised E04; exact reproduction of the selected configuration is not required. The report identifies cjdns 20.6. At the last recorded delay of 58 seconds the CSV reports 197 of 200 replies.", "method": "Revised E04 documentary reassessment; CSV consistency and provenance review, no runtime experiment", "source_label": "External meshnet-lab campaign, retained raw CSV and implementation attribution review", "sources": [ "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/convergence1/convergence1-cjdns-grid4.csv", "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/README.md" ], "editorial_references": [ "round609.html", "round610.html", "round616.html", "round616-sources.json" ], "qualification": "The retained launcher generates its configuration and does not pin the selected private IPv4/UDP peering. Credit cjdns route formation and native endpoint delivery; do not transfer transport-specific overhead or private-peer authorization conclusions. Independent attribution rests on the external comparative laboratory and distinct implementation maintainers. The reviewed GitHub contributor lists contain no mwarning entry (Yggdrasil 51, cjdns 188, batman-adv mirror 113 entries); this supports attribution but is not proof of no affiliation or an exhaustive identity/conflict audit. Network-namespace emulation and historical configuration constrain applicability. The README’s linked driver is a Yggdrasil-only variant; the general multi-protocol driver was recovered in round609. No new benchmark, cross-protocol ranking, global-scale conclusion or current-version guarantee is claimed." }, { "id": "E04-MQ", "feature": "E04", "stack": "MQ", "status": "Y", "reason": "Kramer et al. (2022), On the Potential of MP-QUIC as Transport Layer Aggregator for Multiple Cellular Networks, publish Picoquic measurements in a Mininet/Minitopo environment. Section 4 describes trace-derived varying paths, application execution and log processing; Tables 4–5 report goodput and completion times for 40 MB downloads. This measures the existing multipath transfer mechanism, not only a theoretical capacity model.", "method": "Revised E04 documentary assessment; no new runtime measurement", "source_label": "External Electronics 2022 Picoquic measurement study, Section 4 and Tables 4–5", "sources": [ "https://doi.org/10.3390/electronics11091492", "https://www.mdpi.com/2079-9292/11/9/1492", "https://github.com/private-octopus/picoquic" ], "editorial_references": [ "round620.html", "round620-sources.json" ], "qualification": "The research team is distinct from the Private Octopus implementation owner. Its demo-client extension scripts path addition/removal; it is an external evaluation with disclosed adaptation, not an unmodified baseline. Capacity and latency are estimated from radio traces, not direct measurements of simultaneous multi-operator radio service. Historical Picoquic results do not establish multipath-21 equivalence, the selected PQ configuration, authentication policy, proactive duplication or current performance. Exact build/replay artifacts are not required by revised E04. No new execution or exhaustive affiliation audit." }, { "id": "E04-SC", "feature": "E04", "stack": "SC", "status": "Y", "reason": "Independent ScionPathML researchers publish a SCIONLab campaign with path observations and application bandwidth measurements. The retained Lab1 archive supplies numeric server addresses, bandwidth commands, durations, packet sizes, achieved rates and execution logs. These are measurements of SCION path behavior and application-UDP transport, relevant to the selected composition. The published method and inspected records meet revised E04 without exact binary pins.", "method": "Reassessment under owner-approved independent-measurement criterion; no new execution", "source_label": "Pinned ScionPathML Lab1 raw archive and historical execution logs", "sources": [ "https://doi.org/10.3390/telecom7040081", "https://doi.org/10.3390/telecom7040081" ], "editorial_references": [ "round613.html", "round614.html", "round614-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Credit the published SCIONLab campaign only. Its VPN attachment, cloud hosts and historical software affect results; binary versions remain unidentified. SCMP latency and UDP bandwidth are distinct measurements. No global-capacity, current-release throughput or full-profile certification follows. Previously recorded cadence and provenance observations remain available in rounds 613–614." }, { "id": "E04-RT", "feature": "E04", "stack": "RT", "status": "Y", "reason": "MeshCam/Clover Hill publishes field delivery timings for Reticulum-over-LoRa probes: 5 KB payloads, gateway-side reception records, quiet/busy-channel conditions and sample counts. Its surveyor build uses the separately maintained attermann/microReticulum library, pinned at c02b6e3d985567cced4450fb65902106ebda5a39 with a disclosed local patch. The measured shared mechanism is Reticulum Resource delivery. Revised E04 accepts this external application team’s quantitative observation of an existing protocol implementation, with the implementation and measurement limits below.", "method": "Revised E04 documentary assessment of external Resource delivery measurements", "source_label": "MeshCam field measurements, surveyor build and microReticulum upstream", "sources": [ "https://docs.getmeshcam.com/numbers", "https://github.com/meshcam/meshcam-firmware", "https://github.com/attermann/microReticulum" ], "editorial_references": [ "round627.html", "round627-sources.json" ], "qualification": "These are manufacturer-reported observations of its own application, using a third-party protocol library; no neutral product comparison is claimed. The build applies a transport deadlock patch and disables persistent packet-hash storage. It is not unmodified Python RNS. Published timings cover one radio hop, not multihop routing or global scale. Raw logs were not obtained, experiments were not repeated, and current build settings are not proof of every historical field setting. No camera range, energy, security, interoperability or selected-profile performance certification is inferred. Independence rests on disclosed project provenance, not an exhaustive contributor audit." }, { "id": "E04-NS", "feature": "E04", "stack": "NS", "status": "Y", "reason": "Yasuhiro Matsumoto publishes elapsed seconds and executable scripts for five sequential publish, ID-query and deletion-request cycles against named public WSS relays. Credit is restricted to external strfry relays, not his own relay entries. strfry is separately maintained by hoytech. The shared mechanism is Nostr event publication and subscription through WebSocket relays. The disclosed client workload, endpoints, implementation family and timing boundary meet revised E04 as a small external quantitative observation.", "method": "Revised E04 documentary assessment of bounded client-workload timings", "source_label": "Matsumoto external relay timing report and scripts; strfry upstream", "sources": [ "https://github.com/mattn/nostr-relay-benchmark", "https://github.com/hoytech/strfry" ], "editorial_references": [ "round626.html", "round626-sources.json" ], "qualification": "The scripts time complete nak command sequences, including client and network overhead. They do not robustly assert every returned event, acceptance or deletion; measurements are workload elapsed times, not verified successful-event throughput. Deletion requests are additional workload, not a selected-profile capability. Hardware, relay versions and TLS versions are unspecified; remote configurations vary. No ranking, isolated server latency, TLS 1.3 cost, selected nostr-rs-relay memory configuration or delivery guarantee is inferred. Author-operated relay results are excluded; no exhaustive contributor audit is claimed. Scripts were inspected but not executed." }, { "id": "E04-MT", "feature": "E04", "stack": "MT", "status": "Y", "reason": "Hernandez Ortiz, Quiroz Puentes and Rugeles publish controlled Meshtastic radio measurements using identified Heltec and RAK4631 hardware, modem presets, attenuation steps and a 50-packet-per-step procedure. Packet error, RSSI and SNR results assess the LoRa radio mechanism used by the selected stack. This external experimental report meets revised E04 despite the missing firmware release pin.", "method": "Reassessment under owner-approved independent-measurement criterion; no new execution", "source_label": "Publisher-deposited Crossref abstract and official Meshtastic advisory; full paper unavailable (HTTP 403)", "sources": [ "https://arxiv.org/html/2605.17063v1", "https://arxiv.org/pdf/2605.17063", "https://doi.org/10.32877/bt.v9i1.3847" ], "editorial_references": [ "round299-sources.json", "round331-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Credit radio-preset/link measurements only. No result is transferred to multihop capacity, field range, STRICT-signature/PKI verification cost or security. Hardware revision is not firmware version. The separately located replay/tamper abstract is not needed for this Yes." }, { "id": "E04-GN", "feature": "E04", "stack": "GN", "status": "Y", "reason": "The TU Dortmund UbiMuC project report (31 March 2009) documents executed throughput measurements on Nokia N810 devices. Section 3.1 identifies existing GNUnet peer transport, cyphertext_send and HELLO-based key agreement as the underlying communication component. Section 4.2.3 specifies the benchmark, elapsed-time and byte-count method, two/three-device scenarios and results in Tables 4.1–4.4. The disclosed application team and supervisors are distinct from the GNUnet framework authors. Under revised E04, an external application measurement exercising an existing relevant component qualifies; isolated component timing is not required.", "method": "External application measurement of an existing component; no isolation requirement", "source_label": "TU Dortmund, PG 526 UbiMuC final report (2009), sections 3.1 and 4.2.3", "sources": [ "https://eldorado.tu-dortmund.de/bitstreams/1e159aff-bec3-48de-a768-698f4904b076/download" ], "editorial_references": [ "round629.html", "round629-sources.json" ], "qualification": "Measurements cover a historical GNUnet/UbiMuC composition, including the evaluators’ own packet service, routing messages and framework adaptations. They do not isolate GNUnet throughput or validate current CADET, GNS, security, interoperability or global capacity. The report’s revision labels 804/1179/1187 are not independently mapped to upstream releases. No favorable ranking or transfer of numerical results to the selected current stack is inferred. Independence is based on disclosed attribution, not an exhaustive contributor audit. The previous follow-up’s demand for an isolated baseline was stricter than the component/composition rule already used elsewhere in E04." }, { "id": "E04-ND", "feature": "E04", "stack": "ND", "status": "Y", "reason": "Silva, Macedo and Costa (2022), NDN Content Store and Caching Policies: Performance Evaluation, report executed ndnSIM 2.7 experiments with scenario, method and quantitative results. Section 5 specifies two topologies, cache-placement fractions, request workloads, replacement policies and 20 simulations per scenario. Measured outputs include cache-hit ratio, traffic, retrieval delay, retransmissions and hop count. This is external measurement of software execution, not an exclusively analytical prediction. The measured common mechanism is cache-assisted NDN Interest/Data retrieval.", "method": "Revised E04 documentary reassessment of executed simulation measurements; no new benchmark", "source_label": "Independent Computers 2022 study and ndnSIM implementation documentation", "sources": [ "https://doi.org/10.3390/computers11030037", "https://ndnsim.net/2.7/intro.html", "https://zenodo.org/records/5902396" ], "editorial_references": [ "round617.html", "round617-sources.json" ], "qualification": "Yes is scoped to simulated content-store and retrieval behavior. ndnSIM integrates ndn-cxx/NFD code but also supports simulator-specific legacy content stores; the individual replacement policies are not established as the selected production NFD implementation. Simulated links and historical software do not establish current NFD performance, Ethernet wire costs, signature costs, physical deployment or global capacity. Independent attribution is based on the study authors and affiliations being distinct from the documented simulator authors; no exhaustive affiliation audit is claimed. Dataset metadata and retained paper were reviewed, without downloading multi-gigabyte result archives or rerunning experiments. The article figure caption says 43 nodes where its setup/table say 42 routers; this discrepancy is retained and does not erase the described experiment." }, { "id": "E04-AX", "feature": "E04", "stack": "AX", "status": "Y", "reason": "Zielinski (Silesian University of Technology, 2013) measures AX.25 throughput using existing commercial TNC hardware and firmware. Section 3 specifies computers, controllers, serial and link rates, windows, payload sizes and timing boundaries; figures report executed measurements alongside a separate analytical model. The university evaluator is distinct from the identified vendors and firmware authors. AX.25 is an explicit component of the selected AX.25/NET-ROM stack. Revised E04 accepts a measured relevant component: the earlier demand for NET/ROM measurements as well was stricter than this definition.", "method": "Revised E04 component-scoped documentary assessment; earlier full-stack requirement corrected", "source_label": "Zielinski, Effective throughput of AX.25 protocol (2013)", "sources": [ "https://doi.org/10.2478/bpasts-2013-0068", "https://journals.pan.pl/Content/83769/PDF/14_paper.pdf" ], "editorial_references": [ "round628.html", "round628-sources.json" ], "qualification": "Credit applies only to AX.25 frame exchange and throughput. NET/ROM route selection, transport circuits and the selected Linux implementation were not measured. Controllers were connected by wire to approximate error-free radio conditions; no over-the-air range or interference result is inferred. Hardware and firmware differences prevent transfer of numerical performance to current systems. The study’s analytical curves are not counted as measurements. No new experiment, ranking or exhaustive contributor audit was performed." }, { "id": "E04-BA", "feature": "E04", "stack": "BA", "status": "Y", "reason": "Moritz Warning’s separately maintained meshnet-lab publishes a scenario, method and raw measurements. The reviewed grid CSV has 30 observations on 49 emulated nodes, each with 200 probes after an increasing startup delay. The measured mechanism is route convergence and packet delivery. This qualifies under revised E04; exact reproduction of the selected configuration is not required. The report identifies batman-adv 2023.2. At the last recorded delay of 58 seconds the CSV reports 200 of 200 replies.", "method": "Revised E04 documentary reassessment; CSV consistency and provenance review, no runtime experiment", "source_label": "External meshnet-lab campaign, retained raw CSV and implementation attribution review", "sources": [ "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/convergence1/convergence1-batman-adv-grid4.csv", "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/README.md" ], "editorial_references": [ "round609.html", "round610.html", "round616.html", "round616-sources.json" ], "qualification": "The experiment attaches interfaces to bat0 and measures delivery over the mesh. Its BATMAN_IV/V selection and bonding setting are not established. Credit the shared L2-mesh delivery/convergence mechanism, not IV-specific behavior, bonding performance or the selected Linux 6.12 implementation. Independent attribution rests on the external comparative laboratory and distinct implementation maintainers. The reviewed GitHub contributor lists contain no mwarning entry (Yggdrasil 51, cjdns 188, batman-adv mirror 113 entries); this supports attribution but is not proof of no affiliation or an exhaustive identity/conflict audit. Network-namespace emulation and historical configuration constrain applicability. The README’s linked driver is a Yggdrasil-only variant; the general multi-protocol driver was recovered in round609. No new benchmark, cross-protocol ranking, global-scale conclusion or current-version guarantee is claimed." }, { "id": "E04-BL", "feature": "E04", "stack": "BL", "status": "Y", "reason": "Moritz Warning publishes external meshnet-lab measurements of Babel 1.13.1, with Debian 11.7/Linux 5.10.179, Ryzen 9 Pro 3900 hardware, configuration scripts, topology files and raw CSV results. The Babel launcher assigns ULA IPv6 addresses and starts babeld on the emulated interface; the convergence test uses ICMP probes, matching the selected IPv6/ICMPv6 composition without an added security or application layer. Three published CSVs contain 30 observations each for 49-node grid and 50-node line/tree topologies. Each observation sends 200 probes after an increasing startup delay. At the final 58-second delay all three record 200 replies; these are publisher measurements, not editorial reruns. The experiment comes from a separately maintained comparative laboratory, not the Babel implementation release team. The published method and artifacts support reproduction of this bounded convergence/packet-delivery measurement.", "method": "Independent report, pinned scripts and raw CSV review; source-pointer reconciliation, no new execution", "source_label": "Moritz Warning, meshnet-lab 2024 comparative measurements", "sources": [ "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/README.md", "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/convergence1/convergence1-babel-grid4.csv", "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/convergence1/convergence1-babel-line.csv", "https://github.com/mwarning/meshnet-lab/blob/68c867d58750d029fc742aae5ad57cd3db5350fd/results/2024/convergence1/convergence1-babel-rtree.csv", "https://github.com/mwarning/meshnet-lab/blob/e52fbb62056f42ce4af63a851398f847553b1c80/protocols/babel_start.sh", "https://github.com/mwarning/meshnet-lab/blob/3f53e443f728bbb5a59a0ec4fea026c84835748c/tests/convergence1/run.py" ], "editorial_references": [ "round609.html", "round609-sources.json", "round615.html", "round615-sources.json" ], "qualification": "The results README links test revision e52fbb6, whose convergence driver selects only Yggdrasil versions. The recovered general driver at 3f53e44 differs solely in that protocol-list loop and includes Babel; the tested-version declaration, retained Babel launcher and CSV names identify the Babel experiment. Reproduction requires selecting Babel in that loop and installing declared Babel 1.13.1, not blindly running the Yggdrasil-only setup. Retain this source-pointer discrepancy. The driver uses a 100-Mbit/s TBF with latency parameter 1ms; that parameter is a queue bound, not proof of a 1ms propagation-delay model. Namespace emulation, host load, topology, sampling and configuration limit transfer to physical networks. No throughput ranking, global-scale result, G01 hierarchy measurement, present-version performance guarantee or exact replay of numeric outputs is claimed. Independent attribution rests on the external laboratory and identified maintainers; it is not a conflict-of-interest certification. No local benchmark was run." }, { "id": "E04-RI", "feature": "E04", "stack": "RI", "status": "Y", "reason": "Vucinic, Tourancheau and Duda measure existing ContikiRPL in a Cooja home-automation experiment, comparing it with their own LOADng implementation. Compiled Tmote Sky software, UDP/IPv6/6LoWPAN, declared traffic, topology and timers, five runs and confidence intervals provide identifiable executed measurements. Credit the RPL baseline and its shared DODAG/control and routed-delivery mechanisms.", "method": "Revised E04 documentary assessment; no runtime experiment", "source_label": "External academic measurement study of an existing implementation", "sources": [ "https://arxiv.org/abs/1401.0997v1", "https://raw.githubusercontent.com/contiki-os/contiki/2.6/core/net/rpl/rpl.c" ], "editorial_references": [ "round618.html", "round618-sources.json" ], "qualification": "Grenoble authors are distinct from the SICS ContikiRPL authors credited in the historical source. Credit is not based on their self-authored LOADng. The experiment uses storing mode, modified CSMA and simulated radio; our profile selects non-storing/OF0 and DTLS 1.3 with link protection. No non-storing downward-routing cost, security overhead, modern implementation or physical-radio result is established. No new execution or exhaustive affiliation audit." }, { "id": "E04-HP", "feature": "E04", "stack": "HP", "status": "Y", "reason": "Okwuibe, Liyanage and Ylianttila (2015) report an external testbed evaluation of existing OpenHIP 0.9.1 and HIPL 1.0.8 packages on Ubuntu 12.04 laptops. Sections IV–V describe LAN/WLAN/campus paths, iperf TCP/UDP transfers, 10/200-second sessions and 50 repetitions per direction, followed by numerical throughput results. Credit the OpenHIP protected host-to-host data path, a mechanism relevant to the selected HIP/ESP composition.", "method": "Revised E04 documentary assessment of published throughput measurements", "source_label": "External ICIIS 2015 measurement study, Sections IV–V; RFC 6538 implementation attribution", "sources": [ "https://doi.org/10.1109/ICIINFS.2015.7398986", "https://www.researchgate.net/publication/281968202_Performance_Analysis_of_Open-Source_Linux-Based_HIP_Implementations", "https://www.rfc-editor.org/rfc/rfc6538.html", "https://oulurepo.oulu.fi/handle/10024/40884" ], "editorial_references": [ "round621.html", "round621-sources.json" ], "qualification": "Independence rests on Oulu researchers measuring the existing Boeing-origin OpenHIP implementation (RFC 6538 Section 7), not an assumption that all HIPL work is institutionally unrelated. Historical HIP software does not validate HIPv2 wire compatibility, selected P-256 identities/transforms, mobility or current throughput. The paper inconsistently names latency/jitter tools, repeats OpenHIP in its WLAN latency comparison and misdescribes historical ESP in its discussion; these claims are not adopted. The verdict relies on the described throughput experiment, not its causal explanations or latency ranking. No new run or exhaustive affiliation audit." }, { "id": "E04-CX", "feature": "E04", "stack": "CX", "status": "Y", "reason": "Drescher, DeHart, Parwatikar and Crowley (ICN 2020) measure Metis e59f9c7 on bare-metal Open Networking Laboratory hosts. Section 3 identifies hardware, operating system and synthetic workloads; Sections 4–7 report forwarding, Interest/Data exchange, cache, FIB and latency results. These are executed measurements of CCNx forwarding, not only a model. Mosko’s Metis documentation identifies it as a CCNx 1.0 implementation, establishing the relevant shared mechanism.", "method": "Revised E04 documentary assessment of executed forwarding measurements", "source_label": "External ICN 2020 measurement study; Metis author documentation", "sources": [ "https://doi.org/10.1145/3405656.3418722", "https://par.nsf.gov/servlets/purl/10231644", "https://arxiv.org/abs/1707.04832" ], "editorial_references": [ "round622.html", "round622-sources.json" ], "qualification": "The Washington University measurement team is distinct from the PARC/Marc Mosko implementation attribution; Crowley’s additional Cisco affiliation is disclosed. No exhaustive contributor/affiliation audit is claimed. The experiment uses custom packet generators and documented configuration workarounds, including the default-prefix issue. It does not establish the selected UDP binding or ECDSA/CRC32C verification costs, RFC conformance, current performance or global capacity. Synthetic workloads and the limited tested FIB sizes constrain generalization. No new benchmark or cross-protocol ranking is adopted." }, { "id": "E04-LI", "feature": "E04", "stack": "LI", "status": "Y", "reason": "Haeri, Gill, Hay, Wong and Trajkovic publish an external SFU/BCNET LISP testbed study, describing topology, traffic and results for multihoming, traffic distribution and recovery from link failures. The relevant measured mechanism is EID-to-RLOC forwarding across alternative attachments. Revised E04 accepts this historical measurement despite the BitTorrent workload and missing router release pin.", "method": "Reassessment under owner-approved independent-measurement criterion; no new execution", "source_label": "Multihoming with Locator/ID Separation Protocol: An Experimental Testbed (2015), section III", "sources": [ "https://www.sfu.ca/~ljilja/papers/manfi2015_final.pdf" ], "editorial_references": [ "round615.html", "round615-sources.json" ], "qualification": "This is evidence of measured LISP multihoming behavior, not application-UDP throughput, current RFC 9300/9301 conformance or single-flow packet-level multipath. The study predates those RFCs; workload and router configuration differ from the selected profile. Aggregate transfer results do not resolve F09." }, { "id": "E04-IL", "feature": "E04", "stack": "IL", "status": "Y", "reason": "Kadi, Suleiman and Jammoul measure ILNPv6 identifier-locator communication-cache size, kernel processing and packet service/drop behavior. Their comparison includes the independently developed St Andrews prototype, as well as their own modified prototype. The external measurements of the St Andrews baseline qualify: the network-layer ILCC is relevant to the selected ILNPv6 architecture even though the experimental workload uses UDP.", "method": "Reassessment under owner-approved independent-measurement criterion; no new execution", "source_label": "Performance Analysis of Identifier Locator Communication Cache Effects on ILNPv6 Stack (2021)", "sources": [ "https://onlinelibrary.wiley.com/doi/10.1155/2021/5599254" ], "editorial_references": [ "round615.html", "round615-sources.json" ], "qualification": "Credit external evaluation of the St Andrews baseline, not independent validation of the authors’ own replacement policy. UDP socket behavior and cache growth are workload-specific. The study does not measure the selected TCP connection continuity, DNS discovery or TCP mobility; its numerical UDP results are not transferred to TCP. Exact replay artifacts are not required under revised E04." }, { "id": "E04-TS", "feature": "E04", "stack": "TS", "status": "Y", "reason": "External reporter Michael Renner (terrorobe) published quantitative Tailnet Lock authority-reconstruction measurements for Tailscale 1.98.9, with an explicit synthetic 825-AUM generation recipe, filesystem configurations, timing boundary and allocation counts. Linux amd64/ext3 measured tka.Open at 5.871 seconds and 1.98 GB cumulative allocation; tmpfs measured 5.468 seconds. PR 20736 publishes the fix and benchmark machinery. This is a reproducible measurement of a selected client mechanism, satisfying E04 without requiring every performance dimension.", "method": "Broad primary-source and pinned-code review; no new runtime test", "source_label": "Round 597 primary-source review", "sources": [ "https://github.com/tailscale/tailscale/issues/20735", "https://github.com/tailscale/tailscale/pull/20736" ], "editorial_references": [ "round597.html", "round597-sources.json", "round615.html", "round615-sources.json" ], "qualification": "Independent execution is attributed to the external reporter, subsequently a contributor of the fix, not independently rerun here. The measured 825-AUM workload differs from the merged 2000-AUM regression benchmark. B/op is cumulative allocation, not retained memory. Historical results do not describe current patched performance, packet throughput, managed-coordinator capacity, global scale or the macOS behavior of the selected Linux profile." }, { "id": "E04-RA", "feature": "E04", "stack": "RA", "status": "Y", "reason": "Jeroen van Leur and Jeroen Klomp published an independent University of Amsterdam assessment of IRATI in February 2016. It reports RTT and throughput measurements with method, topology and software versions: Debian/KVM, Ethernet shims and normal DIFs, including master 9d796f2 and pristine-1.4 9ce9644. This directly supplies external quantitative implementation evidence.", "method": "Primary independent report or pinned recovery-policy source inspection; no local execution", "source_label": "University of Amsterdam IRATI assessment", "sources": [ "https://rp.os3.nl/2015-2016/p22/report.pdf" ], "editorial_references": [ "round661.html" ], "qualification": "Historical small virtual testbed, not the current source revision or the Wi-Fi mobility mode. Developer assistance is acknowledged; the authors are distinct from the developers. The report also found routing/resilience limitations. Yes records the existence of measurements, not a favorable performance verdict or current-profile certification. See sections 4.1-4.3 and 5.1-5.2." }, { "id": "E05-PN", "feature": "E05", "stack": "PN", "status": "N", "reason": "On 16 October 2026 the PRP owner explicitly confirmed that no independent operation exists. That declaration also fails the revised adoption rule, which no longer requires six months or an exact configuration.", "method": "Owner-confirmed independent operation status", "source_label": "Direct PRP owner declaration, editorial conversation, 2026-10-16", "sources": [], "editorial_references": [ "round358-review.json", "round358-review.json" ], "qualification": "Dated owner declaration, not technical impossibility. Reassess when attributable independent real use is documented. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-PI", "feature": "E05", "stack": "PI", "status": "N", "reason": "On 16 October 2026 the PRP owner explicitly confirmed that no independent operation exists. That declaration also fails the revised adoption rule, which no longer requires six months or an exact configuration.", "method": "Owner-confirmed independent operation status", "source_label": "Direct PRP owner declaration, editorial conversation, 2026-10-16", "sources": [], "editorial_references": [ "round358-review.json", "round358-review.json" ], "qualification": "Dated owner declaration, not technical impossibility. Reassess when attributable independent real use is documented. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-IP", "feature": "E05", "stack": "IP", "status": "Y", "reason": "RIPE NCC documents RIPE Atlas as an operational distributed measurement service begun in 2010, with users, deployed probes and published IP/ICMP results in its September 2015 account. The measurement-1001 public record begins in 2010 and remains marked Ongoing; retained 2026 anchor results show current IPv4 ICMP replies. This independently operated real-user IP service exceeds six months of operation; evidence is not inferred from software downloads.", "method": "Primary documentary evidence review; no new protocol execution", "source_label": "Evidence checked 2026-10-15; versions and hashes in round234-sources.json", "sources": [ "https://www-static.ripe.net/static/rnd-ui/atlas/static/page/InternetProtocolJournal-18-3.pdf", "https://atlas.ripe.net/api/v2/measurements/1001/", "https://atlas.ripe.net/docs/faq/technical-details/" ], "editorial_references": [ "round234-atlas-results.json" ], "qualification": "Credit operational IP/ICMP use, not the entirety of Atlas control/reporting protocols as part of the compared stack. No uninterrupted availability percentage, operator-by-operator certification, every optional profile feature or PRP-comparable performance is inferred. RIPE NCC is an external network measurement operator, not an internal PRP project. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-BP", "feature": "E05", "stack": "BP", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E05" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-CG", "feature": "E05", "stack": "CG", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E05" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-LT", "feature": "E05", "stack": "LT", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E05" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-LP", "feature": "E05", "stack": "LP", "status": "Y", "reason": "Pinata identifies Spinamp as an actual customer using its IPFS nodes to store and distribute music in an October 2024 account. Its operational documentation describes its nodes retrieving content directly from customer IPFS Desktop peers. IPFS documentation identifies libp2p as its peer networking layer. Together these support external practical adoption of libp2p through Pinata-operated IPFS infrastructure; the component mapping is a documentary inference.", "method": "Primary operator evidence and explicit component mapping under revised E05", "source_label": "Pinata operator/customer account (7 October 2024), Matt Ober operational documentation (1 August 2023), and IPFS libp2p documentation", "sources": [ "https://pinata.cloud/blog/how-spinamp-doubled-developer-efficiency-by-outsourcing-ipfs-hosting-to-pinata-2/", "https://knowledge.pinata.cloud/en/articles/5508876-how-to-use-ipfs-desktop-with-pinata", "https://docs.ipfs.tech/concepts/libp2p/" ], "editorial_references": [ "round641.html" ], "qualification": "Pinata is the credited network operator; a listener reaching an HTTP gateway is not thereby a libp2p endpoint. The provider-authored customer account is commercial evidence, not an independent uptime audit. Transport, library versions, QUIC-only operation, migration and post-quantum settings of the selected column are not attested. IPFS content semantics and Pinata service guarantees are not attributed to libp2p. No new network transaction was performed." }, { "id": "E05-TO", "feature": "E05", "stack": "TO", "status": "Y", "reason": "The Guardian documented newsroom SecureDrop operation on 4 April 2024. FPF subsequently identified its SecureDrop service on 18 February 2025, an interval of 320 days. FPF also records the newsroom contributing operational client improvements in late 2024 and June 2025. This supports sustained real-user operation by a news organization independent of the Tor implementation team, rather than a laboratory demonstration or download count. The selected authenticated onion-service role maps to SecureDrop journalist access: its deployment documentation requires the v3 service and persistent app-journalist.auth_private credentials. The public source-submission interface alone is not the authentication witness. The mapping from the operator reports to the documented standard deployment is a documentary inference.", "method": "Documentary adoption inference with explicit private-configuration limits; no network or operator audit", "source_label": "Dated operator report, FPF deployment/release reports and SecureDrop authenticated-v3 onboarding documentation", "sources": [ "https://securedrop.org/news/five-things-to-know-about-securedrop/", "https://theguardian.engineering/blog/info-2024-apr-04-when-security-matters-working-with-qubes-os-at-the-guardian", "https://docs.securedrop.org/en/stable/admin/deployment/onboarding_journalists.html", "https://securedrop.org/news/looking-back-at-october-and-november-2024/", "https://securedrop.org/news/securedrop-client-0_16_0_released/" ], "editorial_references": [ "round368-sources.json" ], "qualification": "Credit is for documented sustained Tor/onion-v3 operation with the SecureDrop authenticated journalist workflow. The dated reports establish adoption, not uninterrupted availability or a complete private-configuration audit. No private journalist endpoint was accessed and no credentials were obtained. Exact operator Tor builds, relay logging settings, individual authorization revocation events and optional Conflux deployment are not attested by these sources; no such runtime behavior is certified or newly credited. SecureDrop application login, document encryption and Qubes isolation are not attributed to Tor. Contributions to SecureDrop do not make this newsroom a second independent Tor implementation, and E01 is unchanged. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-I2", "feature": "E05", "stack": "I2", "status": "Y", "reason": "I2P announced StormyCloud's operational outproxy on 4 August 2022. A November 2022 direct interview describes the nonprofit's independently operated servers serving community traffic; the January 2023 project account explicitly identifies the service as third-party operated rather than hosted or maintained by I2P. On 16 September 2023 a community report reproduced the operator's one-year service anniversary statement. These dated records support more than six months of real-user I2P destination/tunnel service by an external organization.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Dated I2P announcement and direct StormyCloud operator accounts", "sources": [ "https://i2p.net/en/blog/2022/08/04/how-to-switch-to-the-stormycloud-outproxy-service/", "https://theoverlay.ghost.io/meet-your-maintainer-a-conversation-with-i2p-outproxy-operators-stormycloud-inc/", "https://theoverlay.ghost.io/i2p-core-outproxy-workflow-new-user-testing-and-evaluation/", "https://theoverlay.ghost.io/milestones/" ], "editorial_references": [ "round575.html", "round575-sources.json" ], "qualification": "Historical role-level documentary inference, using the same adoption granularity as Tor, AX.25/NET/ROM, batman-adv and Nostr. Credit the I2P destination/tunnel role serving users in 2022-2023, not the outproxy's separate clearnet forwarding capability. Cooperation with I2P developers is disclosed; independent operation here means separately administered infrastructure, not an absence of collaboration or a second independent implementation. These sources do not attest the selected later i2pd 2.58.0 hybrid type-6 session, exact NTCP2-only transport policy, private-address bootstrap configuration or isolated-key/no-history options. No post-quantum deployment or every optional setting is credited by this adoption result. No live service test, traffic count, uninterrupted uptime or present governance independence is inferred. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-YG", "feature": "E05", "stack": "YG", "status": "Y", "reason": "Robert James Kaes, 4 May 2023, describes using Yggdrasil to reach his home systems while away. He reports SSH over Yggdrasil IPv6 between his laptop and desktop and adds a public server with TLS peering and a key allowlist. This is a named external user addressing a personal remote-access need.", "method": "Owner-approved adoption rule and primary operator evidence", "source_label": "Named operator account; reviewed 2026-10-25", "sources": [ "https://www.wormbytes.ca/2023/05/04/yggdrasil-vpn/" ], "editorial_references": [ "round640.html" ], "qualification": "The account uses SSH/TCP and a public server; the column selects application UDP and a distinct underlay configuration. Exact software version and continued operation after the account are not established. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-CJ", "feature": "E05", "stack": "CJ", "status": "Y", "reason": "John Cook reports an existing cjdns site-to-site connection between his home and an older VPS, with backend services using ULA addresses and MySQL replication from home to the VPS. His April 30, 2015 account distinguishes that existing use from instructions for adding a replacement VPS. This supports practical personal operation outside the cjdns author team under E05; the verdict does not rely on installation instructions or ping tests alone.", "method": "First-person account of existing operational use under revised E05", "source_label": "John Cook, Using a CJDNS Tunnel for Site-Site Encryption, April 30, 2015", "sources": [ "https://web.johncook.uk/articles/vps/cjdns-tunnel" ], "editorial_references": [ "round644.html", "round644-research.json" ], "qualification": "This is an operator self-report, not an independent audit. The reported layering includes an IPv6 ULA tunnel over cjdns over IPv6, with Hurricane Electric connectivity, and the author reports occasional outages. Exact cjdns release, selected cryptographic configuration, duration and continuing operation are not established. Historical adoption does not qualify the current technical profile or demonstrate public Hyperboria-scale deployment. No endpoint was contacted and no technical or security verdict changes." }, { "id": "E05-MQ", "feature": "E05", "stack": "MQ", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E05" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-SC", "feature": "E05", "stack": "SC", "status": "Y", "reason": "SIX and libC describe operating the Secure Swiss Finance Network in their SCION Day 2023 presentation. The operator account covers customer gateways, financial-market participation, certificate renewal and redundant operational CAs. It documents SCION serving a financial connectivity need outside the protocol author team.", "method": "Owner-approved adoption rule and primary operator evidence", "source_label": "Named operator account; reviewed 2026-10-25", "sources": [ "https://www.scion.org/wp-content/uploads/2024/08/LibC-SIX_Steinmann-Suter_SCIONDay2023.pdf" ], "editorial_references": [ "round640.html" ], "qualification": "SSFN uses Anapaya SCION IP gateways and explicitly has no SCION-enabled hosts. Credit SCION transport adoption; do not replace the native UDP column with SIG or infer every selected endpoint property. Operator participation in the SCION ecosystem is disclosed. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-RT", "feature": "E05", "stack": "RT", "status": "Y", "reason": "Ed Braaten (N7EKB) documents his own Reticulum messaging setup: a phone running Sideband, RNode radio links and a home relay with LXMF propagation. Published January and March 2026 status snapshots corroborate traffic and message handling. This is an external radio operator using the network for communication.", "method": "Owner-approved adoption rule and primary operator evidence", "source_label": "Named operator account; reviewed 2026-10-25", "sources": [ "https://reticulum.n7ekb.net/" ], "editorial_references": [ "round640.html" ], "qualification": "This deployment combines LoRa, TCP, Bluetooth, LXMF and a Tailscale backup. The status identifies rnstatus 1.0.0; the selected column uses a different serial/IFAC composition. Snapshot counters do not prove uninterrupted operation or qualify that selected configuration. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-NS", "feature": "E05", "stack": "NS", "status": "Y", "reason": "Kirino's 21 December 2023 operator account identifies relay.nostr.wirednet.jp and companion relays and describes real client event/REQ processing over WebSocket using Nostream. The same operator's 11 December 2024 annual report states that the Japanese and globally open relays operated through the year, with monthly maintenance and actual user traffic. The two accounts span 356 days. Nostream documents the basic NIP-01 flow. Together these support sustained operation of the basic event-relay role by an external community operator, rather than a research demonstration.", "method": "Primary documentation and pinned source review; no runtime experiment", "source_label": "Dated Kirino operator accounts and Nostream basic protocol documentation", "sources": [ "https://zenn.dev/imksoo/articles/19287395ff403e", "https://zenn.dev/imksoo/articles/92be671d734551", "https://github.com/Cameri/nostream" ], "editorial_references": [ "round574.html", "round574-sources.json" ], "qualification": "Historical role-level documentary inference, matching the adoption granularity used for Tor, AX.25/NET/ROM and batman-adv. The global relay is the witness; regional IP filtering is not imported into the selected profile. Kirino contributed SQL optimizations and filtering tooling to an existing Nostream deployment; this contribution is disclosed and is not a second-independent-implementation claim. Credit basic event publication/REQ retrieval, not optional authentication, encryption extensions or a guaranteed service level. Exact TLS builds, optional padding, client multi-relay policy and every study-specific configuration are not attested. In particular the operator used persistent PostgreSQL and logs, not the separate historical C08 memory-only nostr-rs-relay witness. No live WebSocket transaction or runtime qualification was performed. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-MT", "feature": "E05", "stack": "MT", "status": "Y", "reason": "Davide Gomba reports his own Meshtastic use at Fusion Festival in July 2025. Beyond his separate talk and earlier workshop experiment, he describes receiving weather information and stage recommendations on the primary channel, with messages exchanged by festival participants. This is actual community communication serving an event need, not merely a node inventory or a proposed application.", "method": "Primary operator evidence and explicit component mapping under revised E05", "source_label": "Davide Gomba, first-person Fusion Festival report, 21 July 2025; vendor collaboration disclosed", "sources": [ "https://www.seeedstudio.com/blog/2025/07/21/cyberpunk-communication-protocols-at-fusion-festival-a-report/" ], "editorial_references": [ "round641.html" ], "qualification": "The author discloses collaboration with hardware vendor Seeed, which hosts his account. Credit external participant use relative to the protocol authors, not an unaffiliated product review. The witness is primary-channel communication; firmware version, private channels and the selected STRICT-signature DM behavior are not established. The reported node count is not a coverage or reliability measurement. No current service, uninterrupted operation or security audit is inferred." }, { "id": "E05-GN", "feature": "E05", "stack": "GN", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E05" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-ND", "feature": "E05", "stack": "ND", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved criterion and initial research task", "sources": [], "editorial_references": [ "round201.html#E05" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-AX", "feature": "E05", "stack": "AX", "status": "Y", "reason": "NCPACKET operator news records working radio links on 27 March 2017 and 12 January 2018, with intervening operational updates: a 291-day interval exceeding six months. This is a community-operated social communication network, not solely a research demonstration. The TARPN command documentation supplies a concrete profile mapping: radio-port NET/ROM circuit traffic between TADD and FIN carries conversation, while NODES/ROUTES documentation describes routing announcements. Installation instructions identify G8BPQ software by John Wiseman, distinct from the local node operators. Independence is credited to the user/operator community relative to the AX.25/NET/ROM protocol and node implementation authors; TARPN integration and hardware contributions are disclosed, not treated as a second independent implementation.", "method": "Historical operator evidence and explicit profile mapping; no new operational experiment", "source_label": "Dated NCPACKET operator history and TARPN NET/ROM trace, routing and installation documentation", "sources": [ "https://ncpacket.net/north_carolina_packet_radio_network.html", "https://tarpn.net/t/builder/g8bpq/g8bpq_cmds_user.html", "https://tarpn.net/t/builder/builders_init_rpi_for_node-sept-2021.html" ], "editorial_references": [ "round370-sources.json" ], "qualification": "Documentary adoption finding for the historical direct-radio AX.25/NET/ROM role. The dated network history, protocol trace and configuration documentation are complementary evidence, not synchronized captures of every node. Exact binaries and uninterrupted availability are not attested. Later IL2P links are not substituted for the selected AX.25 binding. Local management interfaces and chat applications are outside the credited inter-node stack; no IP tunnel, mailbox semantics, encryption, radio-licensing exemption or modern full-profile runtime qualification is inferred. No radio transmission or private service access was performed. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-BA", "feature": "E05", "stack": "BA", "status": "Y", "reason": "Freifunk Stuttgart's operator report of 11 June 2015 describes eleven radio-meshed routers serving a residential shelter, with 40–50 simultaneous client devices and paths of up to five hops. Its 22 January 2016 operational incident report explicitly identifies batman-adv carrying mesh packets in the same community network, 225 days later. The operator's Gluon repository identifies batman-adv and direct WLAN mesh links. Together these primary records support sustained real-user operation of the native L2 mesh service by a local community operator rather than a research-only demonstration.", "method": "Selected-composition primary documentary review; no runtime experiment", "source_label": "Dated Freifunk Stuttgart operator reports and nostr.wine operator documentation", "sources": [ "https://freifunk-stuttgart.de/2015/06/11/1-stuttgarter-fluechtlingsunterkunft-mit-freifunk/", "https://freifunk-stuttgart.de/2016/01/22/ipv6-router-advertisements-legen-freifunk-router-lahm/", "https://gitlab.freifunk-stuttgart.de/firmware/gluon" ], "editorial_references": [ "round573.html", "round573-sources.json" ], "qualification": "Historical role-level documentary evidence, using the same adoption scope as the AX and Tor decisions. The dates and component mapping are complementary records, not synchronized traces of every installation. Credit the local radio/Ethernet-style batman-adv L2 mesh service; gateway VPNs and user IP applications are outside that boundary. The evidence does not establish six months on Linux 6.12, uninterrupted uptime, optional bonding or every study-specific setting. Community participation in Freifunk is disclosed; this credits an operational community deployment, not a second independent implementation or an organizational audit of every contributor. No live network test performed. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-BL", "feature": "E05", "stack": "BL", "status": "Y", "reason": "Nexedi reports using re6st since 2013 for transnational business applications. Its design documentation identifies Babel as the routing component that installs the routes used by re6st. This is external operational adoption of Babel for business connectivity.", "method": "Owner-approved adoption rule and primary operator evidence", "source_label": "Named operator account; reviewed 2026-10-25", "sources": [ "https://www.nexedi.com/pt/blog/blog-Routerless.Enterprise", "https://www.nexedi.com/fr/Re6st-Design-Document.Understanding.Re6st" ], "editorial_references": [ "round640.html", "round282-sources.json" ], "qualification": "Nexedi develops re6st and contributes integration work; this credits an external user of Babel, not an independent Babel implementation. The deployment includes a registry and dynamic tunnels rather than the selected direct-adjacency IPv6 configuration. The retained production account was rehashed against round282-sources.json; a fresh web fetch failed. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-RI", "feature": "E05", "stack": "RI", "status": "Y", "reason": "The City of London Smart City Programme report for 28 January 2022 identifies Urban Controls as managing its existing Wi-SUN street-lighting mesh. The Wi-SUN Alliance separately reports completion of the municipal FAN deployment in February 2021, naming Itron, Urban Control and DW Windsor. The Alliance-authored FAN overview and TI implementation documentation identify IPv6, 6LoWPAN and RPL in the FAN network stack. Together these document practical municipal adoption of IPv6/RPL IoT networking by an external service operator. The mapping from the named FAN deployment to its network protocols is a documentary inference.", "method": "Primary operator evidence and explicit component mapping under revised E05", "source_label": "City of London municipal report; Wi-SUN Alliance deployment accounts and FAN overview; TI stack documentation", "sources": [ "https://democracy.cityoflondon.gov.uk/documents/s165393/A5%20-%20Smart%20City%20Progress.pdf", "https://wi-sun.org/news/wi-sun-alliance-global-membership-up-20-as-demand-grows-for-industrial-iot-and-smart-city-applications/", "https://wi-sun.org/blog/wi-sun-technology-provides-the-platform-for-city-of-london-smart-city-initiative/", "https://datatracker.ietf.org/doc/html/draft-heile-lpwan-wisun-overview-00#section-4", "https://www.ti.com/document-viewer/lit/html/SWRA714B/GUID-3F537B1D-50A9-4481-AEE6-A657B86853D9" ], "editorial_references": [ "round642.html", "round642-research.json" ], "qualification": "Credit the existing street-lighting network, not the proposed environmental-sensor pilots in the same municipal report. The deployment includes Wi-SUN frequency hopping and its security integration; it does not attest the selected end-to-end DTLS 1.3 PSK profile, exact binaries or every routing option. The 2017 FAN overview is an informational Internet-Draft, not an adopted IETF standard; TI documentation corroborates the component mapping. No private configuration, packet capture, uptime, scale or interoperability certification was obtained. Municipal use is independent of the RPL author team; supplier participation is disclosed." }, { "id": "E05-HP", "feature": "E05", "stack": "HP", "status": "Y", "reason": "The Tempered customer case study identifies the City of Meridian Public Works Department and its network administrator Eli Daniel. It describes deployed Airwall gateways connecting 26 water and wastewater sites to City Hall for operational monitoring, plus use by other municipal departments. The product documentation explicitly identifies Host Identity Protocol as the basis of Airwall. Together these support practical HIP adoption by a municipal operator independent of the protocol author team, rather than a vendor-only laboratory deployment. The product-to-protocol mapping is documentary.", "method": "Attributed customer operation and product-to-protocol mapping under revised E05", "source_label": "Tempered City of Meridian customer case study, pages 1–3; Airwall HIP documentation", "sources": [ "https://tempered.io/assets/pdfs/city-of-meridian-case-study.pdf", "https://airwall.io/airwall/host-identity-protocol/", "https://airwall.io/solutions/municipalities/" ], "editorial_references": [ "round643.html", "round643-research.json" ], "qualification": "The case study is vendor-published with attributed customer statements; it is not an independent operational audit. Its 2020 copyright and reported three years of use do not establish exact commissioning dates or continuous current operation. The deployed system includes Airwall gateways, a cloud Conductor and Relays. Those management features and all security, availability or cost claims remain product-specific. Exact HIP version, ECDSA P-256 and ESP cipher choices of the selected technical column are not attested. No municipal endpoint was contacted, no network test was performed and no additional technical verdict changes." }, { "id": "E05-CX", "feature": "E05", "stack": "CX", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "Approved editorial scope and primary protocol specifications", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html", "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round245.html" ], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-LI", "feature": "E05", "stack": "LI", "status": "Y", "reason": "The April 2012 InTouch customer case study attributes statements to its CEO Rager Ossel and project leader Gioberto Balinge about LISP moving from the lab to live production. It describes a retail customer connecting twelve stores through a LISP platform. This documents an external service provider using LISP for customer connectivity, beyond the separate international beta network.", "method": "Primary operator evidence and explicit component mapping under revised E05", "source_label": "Cisco/InTouch customer case study, printed April 2012, pages 1–3; named operator statements", "sources": [ "https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/intouch_casestudy.pdf" ], "editorial_references": [ "round641.html" ], "qualification": "Cisco publishes the account and InTouch collaborated with its development team; that relationship is disclosed. Credit external customer operation, not independent implementation or an independently audited performance claim. The four-year duration belongs to the beta network and is not assigned to InTouch. Historical Cisco deployment does not establish exact RFC 9300/9301-era behavior or every option of the selected column. No uptime, cost or scale claim is imported." }, { "id": "E05-IL", "feature": "E05", "stack": "IL", "status": "?", "reason": "Independent practical adoption has not yet been established by the retained evidence under the revised E05 rule. Previous exact-profile or six-month research gaps are no longer disqualifiers. Reassess the linked material for actual operator use; specifications and available software alone do not establish adoption.", "method": "Revised adoption evidence inventory", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "Find an attributable independent operator account of actual use and its purpose. Document known dates, versions and deployment components. Downloads, tutorials alone, node lists, announcements and research-only demonstrations do not suffice. Yes requires documented use; No requires confirmed absence; otherwise Pending. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-TS", "feature": "E05", "stack": "TS", "status": "Y", "reason": "Daniel Brennand reports on 29 September 2024 that he is accessing home services and routing traffic through his home network from a coffee shop using Tailscale. He documents his own devices, subnet routers, exit nodes and Tailnet Lock enrollment. This is attributed independent personal use for remote access.", "method": "Owner-approved adoption rule and primary operator evidence", "source_label": "Named operator account; reviewed 2026-10-25", "sources": [ "https://dbren.uk/blog/tailscale/" ], "editorial_references": [ "round640.html" ], "qualification": "The account documents Tailnet Lock at that date, not continuous use of identical settings for six months. It also uses subnet routers, MagicDNS and exit nodes; these options do not change the selected technical profile. Exact client versions are not established. E05 uses the owner-approved adoption rule from revision 6.40. Deployment differences are disclosed rather than imported into the technical column. Independence is assessed from public operator attribution and role, not a private affiliation audit. No runtime, security, uptime or full-profile certification is implied." }, { "id": "E05-RA", "feature": "E05", "stack": "RA", "status": "?", "reason": "The i2CAT 2018 annual report describes IRATI used by Ciena, BT, i2CAT and TSSG for a multi-operator virtual-network proof of concept at the Telecom Infra Project Summit. This is attributable demonstration evidence, but it does not document independent operational use beyond demonstrations. It therefore does not settle this adoption criterion.", "method": "Distinguish documented demonstration scope from the criterion required evidence", "source_label": "Primary project documentary evidence", "sources": [ "https://i2cat.net/wp-content/uploads/2019/07/AnnualReport_2018_i2cat.pdf" ], "editorial_references": [ "round674.html" ], "qualification": "Find an attributable independent operator account of actual use serving a real need beyond demonstrations. Record purpose, operator, components and dates. The TIP Summit proof of concept is a lead, not evidence of continuing production use; lack of a qualifying account is not confirmed absence." }, { "id": "D01-PN", "feature": "D01", "stack": "PN", "status": "Y", "reason": "Architectural Yes, based on the author's explicit endpoint model and the inspected portable processing boundary. A native PRP endpoint is an ordinary user process owning its identity and relationship state. It exchanges complete PRP records through a provisioned system transport interface; receiving a complete record does not itself require a raw Ethernet socket or administrative network authority. The endpoint need not configure the carrier, routing or host-wide networking. Linux userspace is the examined architectural target. The portable session API separates record processing from transport callbacks. Requiring the endpoint itself to implement privileged Ethernet access conflated transport provisioning with routine endpoint operation. This is a capability assessment, not a claim that the current native Linux interface has already implemented this unprivileged path.", "method": "Author-confirmed architectural capability with retained implementation qualification", "source_label": "Owner clarification and approval, 2026-10-20; retained portable API and Linux privilege audits", "sources": [], "editorial_references": [ "round411.html", "round411-evidence.json", "round352-operation-map.json", "round352-sources.json", "round353-boundary.json", "round353-sources.json" ], "qualification": "Author-confirmed architecture plus source-level separation, not an executed unprivileged native stack. The inspected Linux generic-netlink path requires GENL_ADMIN_PERM for session and TX operations; delegated receive access alone does not remove that restriction. That implementation remains unqualified for complete ordinary-user TX/RX and new-session operation. Privileged initial installation, carrier provisioning and any continuing privileged userspace mediator must be disclosed; no such mediator is silently counted as unprivileged runtime. The architectural witness requires a suitably scoped endpoint interface, not permission to transmit arbitrary raw frames. Tests with in-memory callbacks do not demonstrate native Ethernet, HS2, framing, MTU handling or the selected protected composition under a checked UID and capability set. No kernel code or security policy was changed." }, { "id": "D01-PI", "feature": "D01", "stack": "PI", "status": "Y", "reason": "The documented Linux portable PRP path separates session/connection processing from its application-supplied transport. The provider supplies userspace randomness, time, storage and software cryptography; a normal IPv4/UDP socket on a high port and user-owned keys/storage require no elevated networking authority. This is a concrete plausible ordinary-user composition after network provisioning, rather than a requirement to use the default privileged PRP kernel dataplane.", "method": "Documentary ordinary-user plausibility; no complete privilege execution", "source_label": "Pinned PRP portable runtime/provider documentation and Linux datagram facilities", "sources": [ "https://man7.org/linux/man-pages/man7/ip.7.html" ], "editorial_references": [ "round234-sources.json", "round304-sources.json", "round308-sources.json" ], "qualification": "Plausibility only: the retained portable gate injects transport records, and the complete 0x0202 UDP endpoint has not been executed under a checked UID/capability set. Explicitly select the portable path with ordinary sockets and user-owned state; a kernel-ring or privileged continuing helper is not this witness. Initial network/firewall/package provisioning remains separate. No transfer to native Ethernet D01-PN, which has a distinct raw-packet authority boundary." }, { "id": "D01-IP", "feature": "D01", "stack": "IP", "status": "Y", "reason": "In an isolated Debian 13.6 guest, Linux 6.12.101+deb13-amd64, two peers per address family created native protocol-253 raw sockets during privileged setup, then permanently changed all UID/GID values to 65534, cleared supplementary groups and set no_new_privs. Effective, permitted, inherited and ambient capabilities were zero. Both root reacquisition and creation of a fresh raw socket were rejected, while request/reply exchange through the retained sockets passed for IPv4 and IPv6. The parent only synchronized readiness; it neither opened nor used a network socket. This closes the previous sandbox-only prerequisite failure with an actual bounded runtime witness.", "method": "Executed isolated QEMU/KVM guest experiment; no external network interface", "source_label": "Evidence checked 2026-10-15; versions and hashes in round234-sources.json", "sources": [ "https://man7.org/linux/man-pages/man7/raw.7.html" ], "editorial_references": [ "round234-raw-ip-result.json", "round234_raw_ip_drop.py" ], "qualification": "Privileged socket creation is required once and is disclosed. The experiment used local loopback, not an external NIC, routed multi-host network, BGP or multicast administration; it is not a performance test. A complete deployment must still provision routes/interfaces and preserve its security policy. Native IP datagrams were used, with no added TCP/UDP transport. Signed result digest fd2d6f7e538c4f48790bbf13f5444bd56451f08b3018978088febc7e686e0b4a." }, { "id": "D01-BP", "feature": "D01", "stack": "BP", "status": "Y", "reason": "HDTN provides a documented Linux userspace endpoint path: bpgen-async and bpsink-async run directly from the build directory with configured BPSec files. TCPCLv4 uses Boost.Asio TCP sockets; the published TLS configuration binds port 4556 and loads PEM credentials from configured files. With high-numbered ports, user-owned credentials/storage and preconfigured host networking, routine operation requires no raw socket or elevated networking capability. Package installation and host provisioning are separate privileged steps.", "method": "Documentary classification; no new build or runtime experiment", "source_label": "Versioned primary-source review, 2026-10-15", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/runscript.sh", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/induct_manager/src/TcpclV4Induct.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/config_files/hdtn/hdtn_ingress1tcpclv4tls_port4556.json", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/config_files/bpsec/ipn1.1_con_plus_int.json", "https://man7.org/linux/man-pages/man7/ip.7.html" ], "editorial_references": [], "qualification": "Documentary execution-requirement finding, not a fresh unprivileged runtime test. Replace example Windows certificate paths with readable Linux paths; provision participant trust, TLS and BPSec policies for the selected profile. The sample runscript itself uses non-TLS configuration and is not an end-to-end secure-profile test. No transfer of the separate ION F16/F21 witnesses or CGR/LTP qualification is inferred." }, { "id": "D01-CG", "feature": "D01", "stack": "CG", "status": "Y", "reason": "On documented Ubuntu/Debian hosts, HDTN implements contact-plan computation, BP/BPSec processing and TCPCLv4/TLS in userspace. Its TCP transport uses ordinary sockets, and endpoint examples use high ports and configured key files. Local route-plan computation does not require changing host IP routes. With preprovisioned networking, user-owned storage/keys and nonprivileged ports, ordinary endpoint operation is architecturally plausible without continuing elevated networking authority.", "method": "Documentary privilege-boundary plausibility; no new execution", "source_label": "Pinned HDTN Linux deployment and userspace transport/routing sources", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/tcpcl/src/TcpclV4BidirectionalLink.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/cgr/src/libcgr.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/module/router/src/router.cpp" ], "editorial_references": [ "round233-sources.json", "round306-sources.json" ], "qualification": "Documentary plausibility only. This is not a fresh UID/capability test or a complete executable SABR/BPv7 integration witness. Initial installation/network provisioning may require an administrator. Do not substitute the inspected ION TCPCLv3 adapter for selected TCPCLv4/TLS; HDTN and ION component evidence does not certify their integration. Keep complete-profile availability and exact metadata/security mapping questions in E03-CG. No raw-Ethernet, privileged-port or host-route administration is credited." }, { "id": "D01-LT", "feature": "D01", "stack": "LT", "status": "?", "reason": "The identified HDTN encapsulation boundary uses Boost.Asio AF_UNIX local sockets on POSIX and duplex named pipes on Windows. On POSIX the creator removes the configured existing socket path and binds a local acceptor; path ownership/access must be provisioned. This component does not itself establish the privilege requirements of the AOS provider, its device driver or continuing helpers. The demo shell script contains no sudo, but that is not a credential/capability execution receipt.", "method": "Source review and evidence reconciliation; no new runtime execution", "source_label": "Pinned HDTN source and retained executed QUIC evidence", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/ltp/src/LtpEncapLocalStreamEngine.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/util/include/EncapAsyncDuplexLocalStream.h", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/tests/test_scripts_linux/test_stcp_to_ltpencap_fast_cutthrough.sh" ], "editorial_references": [ "round287.html", "round287-sources.json" ], "qualification": "Bind an actual AOS virtual-channel packet-service provider and its Encapsulation interface, then map BPv7/BPSec and SABR metadata to the selected all-red LTP composition. The shipped demonstration enters via STCP and leaves via LTP/Encapsulation local sockets; it does not qualify the selected no-IP complete path. The EncapRepeater only forwards encapsulation packets between local streams and is not an AOS frame/channel implementation. Do not infer universal absence of another implementation. Pin OS, provider/device permissions and all helpers, then execute routine communication after permanent privilege drop. A local stream alone is not the complete endpoint." }, { "id": "D01-LP", "feature": "D01", "stack": "LP", "status": "Y", "reason": "On ordinary Linux, the inspected go-libp2p QUIC connection manager creates net.ListenUDP sockets. With a nonprivileged listening port, user-owned peer keys and the selected known-peer configuration, routine endpoint operation requires neither raw sockets nor route administration. Provisioning the underlying network remains administrative; NAT helpers are not selected.", "method": "Documentary endpoint/profile analysis; no new software execution", "source_label": "Primary documentation and code reviewed 2026-10-15", "sources": [ "https://raw.githubusercontent.com/libp2p/go-libp2p/master/p2p/transport/quicreuse/connmgr.go", "https://raw.githubusercontent.com/libp2p/go-libp2p/master/p2p/transport/quic/transport.go" ], "editorial_references": [], "qualification": "Documented dependency/privilege witness only. No live deployment, permission trace, interoperability or performance qualification. Preserve the selected communication and privacy configuration." }, { "id": "D01-TO", "feature": "D01", "stack": "TO", "status": "Y", "reason": "The Debian Tor manual supports a normal runtime user; the onion-service guide requires that user to own/read the service key directory. Use user-owned state and authorization files, a high local TCP port or Unix socket backend, and no transparent proxy. Virtual onion port 80 does not require a privileged local listener. Installation, account provisioning and service-manager restart may require administration; they are distinct from routine communication.", "method": "Documentary endpoint/profile analysis; no new software execution", "source_label": "Primary documentation and code reviewed 2026-10-15", "sources": [ "https://community.torproject.org/onion-services/setup/", "https://manpages.debian.org/bookworm/tor/tor.1.en.html" ], "editorial_references": [], "qualification": "Documented dependency/privilege witness only. No live deployment, permission trace, interoperability or performance qualification. Preserve the selected communication and privacy configuration." }, { "id": "D01-I2", "feature": "D01", "stack": "I2", "status": "Y", "reason": "The Linux Java router can be launched directly by the supplied runplain.sh without a privileged service wrapper. Use user-owned installation/state and nonprivileged NTCP2/control ports. The selected numeric bootstrap and destination/tunnel processing need ordinary TCP sockets, not route configuration or raw packet access. This does not test the private bootstrap configuration or its reachability.", "method": "Documentary endpoint/profile analysis; no new software execution", "source_label": "Primary documentation and code reviewed 2026-10-15", "sources": [ "https://raw.githubusercontent.com/i2p/i2p.i2p/master/installer/resources/runplain.sh", "https://i2p.net/en/downloads/", "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "Documented dependency/privilege witness only. No live deployment, permission trace, interoperability or performance qualification. Preserve the selected communication and privacy configuration." }, { "id": "D01-YG", "feature": "D01", "stack": "YG", "status": "Y", "reason": "Yggdrasil v0.5.12 on Linux initializes its TUN interface before the explicit -user privilege drop. chuser_unix.go clears supplementary groups and calls setgid/setuid; the running endpoint then retains the opened interface while using ordinary TCP/TLS sockets. Thus supported setup can be privileged while routine endpoint traffic runs as an ordinary user.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/yggdrasil-network/yggdrasil-go/blob/v0.5.12/cmd/yggdrasil/main.go", "https://github.com/yggdrasil-network/yggdrasil-go/blob/v0.5.12/cmd/yggdrasil/chuser_unix.go" ], "editorial_references": [], "qualification": "Choose a non-root account, readable user configuration and nonprivileged peer ports; do not set keep-capabilities or retain a privileged helper. This is a documentary code path, not a measured capability trace or proof of every service-unit default." }, { "id": "D01-CJ", "feature": "D01", "stack": "CJ", "status": "Y", "reason": "The official non-root method 1 provisions a user-owned persistent TUN interface and configures its address/MTU administratively, then runs cjdroute as that normal user. This supports routine Linux operation without elevated networking capabilities. Method 2, which grants CAP_NET_ADMIN/CAP_NET_RAW, is not this witness.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://github.com/cjdelisle/cjdns/blob/master/doc/non-root-user.md" ], "editorial_references": [], "qualification": "Privileged TUN preparation is required again after restart as documented. Keep method 1 and the selected UDP peer configuration; no new execution." }, { "id": "D01-MQ", "feature": "D01", "stack": "MQ", "status": "Y", "reason": "In an isolated Debian 13 guest running Linux 6.12.101+deb13-amd64, the retained picoquic c124cbe / Picotls f06553b build passed sockloop_ipv4 after permanent UID/GID drop to 65534, removal of supplementary groups, no_new_privs and zero effective/permitted/inherited/ambient capabilities. Root reacquisition was denied. Sockets were created by the unprivileged test executable, not pre-opened by a privileged network helper. The same ordinary-user executable separately passed upstream client_auth and multipath_basic. This closes the host setgroups blocker recorded in round 2.80 with an actual supported Linux endpoint execution.", "method": "One live-loopback test plus two simulated-network tests under ordinary-user credentials; all three exit zero", "source_label": "Executed QEMU/KVM guest experiment and pinned upstream tests", "sources": [ "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquictest/sockloop_test.c" ], "editorial_references": [ "round285-runtime.json", "round285_guest.py", "round285-sources.json", "round280-runtime.json", "round226-runtime.json" ], "qualification": "The VM had no external NIC. sockloop_ipv4 exercises actual loopback UDP sockets; client_auth and multipath_basic use the upstream simulated-network harness and are not a combined live authenticated multipath deployment. Administrative image/installation provisioning and user-owned public test fixtures are disclosed. The build is reused unchanged from round 2.26; the guest launcher changes process credentials, not protocol code. This establishes routine privilege requirements, not independent interoperability, hybrid key exchange, full selected-profile conformance, external-path handover or performance. The multipath zero-path-limit issue and complete profile mapping in E03-MQ remain separate. No host permissions or privileges were changed." }, { "id": "D01-SC", "feature": "D01", "stack": "SC", "status": "Y", "reason": "JPAN 0.7.0 documents an ordinary Java SCION/UDP endpoint with an in-process SHIM on UDP port 30041 and standalone or daemon-assisted path service. The standalone option with provisioned numeric topology/trust avoids a privileged local packet dispatcher; 30041 and configured application ports are unprivileged on Linux.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/scionproto-contrib/jpan", "https://github.com/scionproto-contrib/jpan/blob/master/README.md" ], "editorial_references": [], "qualification": "This is the endpoint, not unprivileged installation or operation of every transit/control service. Existing network provisioning remains necessary. No new Java execution, packet capture or interoperability claim." }, { "id": "D01-RT", "feature": "D01", "stack": "RT", "status": "Y", "reason": "Reticulum documents normal-user Python operation. For the selected standalone SerialInterface, provision ordinary read/write permission on the serial device and keep the configuration directory user-owned; subsequent rnsd/Link operation needs no root or networking capability. No privileged radio or shared-IP helper is added.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://reticulum.network/manual/using.html", "https://reticulum.network/manual/interfaces.html#serial-interface" ], "editorial_references": [], "qualification": "Serial-device ACL/group setup may require an administrator. Pin the actual distribution and driver in any live acceptance test; this is a documentary Linux serial witness." }, { "id": "D01-NS", "feature": "D01", "stack": "NS", "status": "Y", "reason": "A normal-user browser client can perform NIP-01 event signing/verification and WSS relay communication using JavaScript and the WebSocket API. It needs no raw socket or administrative capability. This is the author/reader endpoint, not an administrator provisioning the relay or browser.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://github.com/nbd-wtf/nostr-tools", "https://websockets.spec.whatwg.org/" ], "editorial_references": [], "qualification": "No new browser run; local key custody and trusted client code remain the endpoint assumption." }, { "id": "D01-MT", "feature": "D01", "stack": "MT", "status": "Y", "reason": "A documented Linux meshtasticd endpoint may run as a user with device permissions. The bounded witness is direct headless native execution with a compatible CH341 USB radio, user-owned state/configuration, explicit General.MACAddress, and only nonprivileged local ports (or disabled optional servers). Provision USB access administratively. Do not inherit the packaged service ambient CAP_NET_BIND_SERVICE; that default unit is not an unprivileged witness. No raw networking, display/GPIO helper or privileged service manager is credited as routine endpoint operation.", "method": "Documentary code/dependency analysis; no new execution or radio operation", "source_label": "Primary source and official installation review 2026-10-15", "sources": [ "https://meshtastic.org/docs/meshtasticd/hardware/", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/bin/meshtasticd.service", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/bin/config-dist.yaml", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/platform/portduino/PortduinoGlue.cpp", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/platform/portduino/USBHal.h" ], "editorial_references": [], "qualification": "Documentary execution-path finding, not a measured permission trace. Keep real LoRa, selected keys/policies and isolated state; privileged package installation and USB ACL provisioning are separate. Direct invocation without ambient capabilities is required." }, { "id": "D01-GN", "feature": "D01", "stack": "GN", "status": "Y", "reason": "The documented single-user GNUnet setup starts the services with gnunet-arm as the user. In the selected known-neighbor UDP/CORE/CADET profile, NAT/ICMP/VPN/DNS helpers are excluded and a nonprivileged UDP port can be used. System-wide installation is separate from routine user operation.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.gnunet.org/v0.20.x/users/configuration.html", "https://docs.gnunet.org/v0.20.x/installing.html" ], "editorial_references": [], "qualification": "Keep privileged optional helpers disabled and user-owned stores; no live permissions trace was performed." }, { "id": "D01-ND", "feature": "D01", "stack": "ND", "status": "N", "reason": "The identified Linux NFD Ethernet configuration retains elevated authority during routine operation. PrivilegeHelper records its original effective IDs; drop changes only effective IDs, while raise restores the privileged values. The newly traced PcapHelper::activate calls pcap_activate inside PrivilegeHelper::runElevated, which raises privileges for the operation and then drops them again. EthernetTransport uses this activation path, and EthernetFactory handles interfaces added after startup as well as face requests. Thus the mechanism is not merely a privileged installer followed by irreversible privilege removal. It fails D01 for this pinned configuration even when its current effective UID is an ordinary account. The documented Linux file-capability alternative also grants elevated networking authority (CAP_NET_RAW and CAP_NET_ADMIN).", "method": "Privilege lifecycle and live face-activation source trace; no runtime test", "source_label": "Pinned NFD 24.07 source and official FAQ, reviewed 2026-10-22", "sources": [ "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/pcap-helper.cpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/face/ethernet-factory.cpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/daemon/common/privilege-helper.cpp", "https://github.com/named-data/NFD/blob/a1480a7c947dc6a48ee12c6c0637fc488c0c73a1/docs/FAQ.rst" ], "editorial_references": [ "round427.html", "round427-sources.json" ], "qualification": "This No is scoped to the identified NFD/Linux direct-Ethernet deployment, not all possible NDN implementations. It does not mean each packet needs a fresh elevation: established faces use their existing capture/injection handles. An application using a local Unix socket may itself be unprivileged, but D01 includes the local forwarder and any continuing helper. The macOS BPF-permission alternative and a hypothetical permanently reduced, pre-opened-face design are not qualified by this finding. No OS changes, capability grants, packet capture, runtime privilege test or complete-stack interoperability test was performed." }, { "id": "D01-AX", "feature": "D01", "stack": "AX", "status": "N", "reason": "The unprivileged NET/ROM application socket does not cover the selected endpoint control plane. In the pinned ax25-tools source, netromd receives NODES announcements and calls receive_nodes; netromr.c installs learned entries using SIOCADDRT. Periodically, netromd calls transmit_nodes; netromt.c invokes SIOCNRDECOBS to age routes. Linux v6.12 nr_ioctl explicitly checks capable(CAP_NET_ADMIN) on both commands, returning EPERM otherwise. These checks occur when the recurring operations execute, not only when a socket is opened or the interface installed. The identified Linux/netromd configuration therefore does not satisfy D01: routine operation needs an elevated network-administration actor. Moving that actor into a helper would not make the complete endpoint unprivileged under the existing criterion.", "method": "Recurring syscall/capability trace with explicit executable binding; no runtime test", "source_label": "Debian-retained ax25-tools upstream archive and Linux v6.12 source, reviewed 2026-10-22", "sources": [ "https://sources.debian.org/src/ax25-tools/0.0.10-rc5%2Bgit20230513%2Bd3e6d4f-3/netrom/netromr.c/", "https://sources.debian.org/src/ax25-tools/0.0.10-rc5%2Bgit20230513%2Bd3e6d4f-3/netrom/netromt.c/", "https://github.com/torvalds/linux/blob/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [ "round426.html", "round426-sources.json", "round426-privileges.json" ], "qualification": "The No is scoped to the explicitly identified active-announcement Linux/netromd configuration, not a claim that the NET/ROM wire protocol makes every alternative implementation privileged. Application SOCK_SEQPACKET use with a provisioned UID/callsign mapping can remain unprivileged. nrattach configures an interface and exits; kissattach installs the serial line discipline and remains alive holding the attachment. Those setup/lifetime facts are separate from the decisive recurring route-maintenance checks. A pre-opened socket does not bypass nr_ioctl capability checks. Static routing without netromd, a userspace implementation, or a different kernel authority model would require a separately qualified configuration. No live serial/radio test, privilege escalation, hardware or OS change was performed." }, { "id": "D01-BA", "feature": "D01", "stack": "BA", "status": "Y", "reason": "A QEMU/KVM Debian 13 guest with stock Linux 6.12.101+deb13-amd64 and batman-adv 2024.2 exchanged 16 native Ethernet requests and replies between two bat0 endpoints over a veth link. BATMAN_IV was explicitly selected and independently read back through generic netlink at both endpoints. Before all payload traffic, both application processes permanently dropped to UID/GID 65534, cleared supplementary groups, enabled no_new_privs and verified zero effective/permitted/inherited/ambient capabilities. Both denied root reacquisition and creation of another raw socket, while sending and receiving through their provisioned descriptors. No IP/UDP payload or continuing privileged userspace forwarding helper was used.", "method": "Sixteen bidirectional request/reply transactions after permanent privilege drop; kernel algorithm readback and negative privilege controls", "source_label": "Executed QEMU/KVM native Ethernet experiment; Linux and packet socket documentation", "sources": [ "https://docs.kernel.org/6.12/networking/batman-adv.html", "https://man7.org/linux/man-pages/man7/packet.7.html" ], "editorial_references": [ "round286-runtime.json", "round286_guest.py", "round286-sources.json" ], "qualification": "Privileged installation, kernel module loading, namespace/interface provisioning and AF_PACKET socket creation are required and disclosed. The Yes concerns routine operation on the provisioned endpoint, not permissionless socket creation or a kernel-module-free stack. The retained socket is an explicitly delegated networking resource. This single-guest, two-namespace, one-link experiment does not establish multihop/radio behavior, bonding, mobility, performance, isolation against malicious raw-frame applications or full-profile interoperability. Small frames were used; the 1500-byte underlay MTU warning is retained and large-frame behavior is unqualified. Initial module-parameter and ip-output diagnostic failures occurred before traffic; a later capture attempt produced no usable result. Only the retained final PASS is credited." }, { "id": "D01-BL", "feature": "D01", "stack": "BL", "status": "Y", "reason": "The selected IPv6/Babel composition already includes provisioned leaf LANs. An ordinary leaf endpoint uses the stock IPv6 data plane; Babel speakers maintain routes on the routers, rather than requiring every consuming application to administer routing. The retained Debian 13.6 / Linux 6.12.101 experiment in round 2.34 demonstrates native IPv6 protocol-253 request/reply through pre-opened raw sockets after both endpoints permanently dropped UID/GID to 65534 and cleared effective, permitted, inherited and ambient capabilities. Combining that endpoint witness with the documented separation of routing and forwarding supports unprivileged routine leaf operation.", "method": "Documentary role/composition analysis with reused bounded runtime evidence; no new runtime execution", "source_label": "RFC 8966, babeld maintainer documentation and retained Linux IPv6 endpoint experiment", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html", "https://www.irif.fr/~jch/software/babel/babeld.html" ], "editorial_references": [ "round234-raw-ip-result.json", "round234_raw_ip_drop.py", "round281-sources.json" ], "qualification": "This is a documentary composition finding, not a newly executed Babel network test. The reused experiment was loopback-only and did not run Babel, a routed multi-host topology or an external NIC. Initial raw-socket creation and interface/address/route provisioning require privileges. Routers may continue to require privileged route installation; no claim is made that babeld itself runs without elevated capabilities. The Yes applies to the ordinary provisioned leaf endpoint allowed by D01, not to a node simultaneously acting as a router. No UDP/TCP application transport or new profile is added." }, { "id": "D01-RI", "feature": "D01", "stack": "RI", "status": "?", "reason": "Linux 6.12 documents separate IEEE 802.15.4 management through netlink and 6LoWPAN interface provisioning, while the endpoint data path can use ordinary IPv6 UDP sockets. This narrows the privilege question but does not settle the selected complete leaf. RFC 6775 address registration has a lifetime and renewal procedure; RPL leaf signaling and any route/neighbor updates must also be assigned to an identified process. A userspace DTLS candidate and an unprivileged UDP socket alone do not establish who performs that recurring control work. RIOT now supplies a concrete alternate userspace-stack candidate: its native RPL tutorial uses TAP networking, and socket_zep exposes an IEEE 802.15.4 radio HAL through UDP encapsulation for simulation. Neither source alone demonstrates the selected physical IEEE 802.15.4 leaf with the required privilege boundary and exact DTLS profile.", "method": "Documentary privilege-boundary analysis; no runtime execution", "source_label": "Linux 6.12 network management documentation, Linux capabilities and 6LoWPAN neighbor registration", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/ieee802154.html", "https://man7.org/linux/man-pages/man7/ipv6.7.html", "https://man7.org/linux/man-pages/man7/capabilities.7.html", "https://www.rfc-editor.org/rfc/rfc6775.html", "https://docs.riot-os.org/networking/rpl/", "https://api.riot-os.org/group__drivers__socket__zep.html" ], "editorial_references": [ "round307-sources.json", "round322-sources.json", "round323-sources.json" ], "qualification": "Pin a concrete leaf executable and stock kernel configuration; trace initial PAN/channel/interface/address provisioning separately from sustained operation. Identify the owner and lifetime of ICMPv6/raw sockets, registration renewal, RPL signaling and route/neighbor updates. Linux CAP_NET_RAW controls raw-socket creation and CAP_NET_ADMIN covers network administration; document pre-opened descriptors, privilege drop or any persistent helper rather than assuming none. Then establish the selected DTLS 1.3 psk_ke/AES-128-GCM path with final-peer keys. Retained descriptors may avoid repeated privileged opens, but no exact full-stack leaf witness has been qualified here. No negative verdict or new runtime claim follows." }, { "id": "D01-HP", "feature": "D01", "stack": "HP", "status": "?", "reason": "RFC 6538 sections 2.1-2.2 documents kernel-integrated and userspace HIP implementations. Its userspace approach still diverts and reinjects packets, for example through TAP plus routing or filtering rules; userspace is not evidence of unprivileged execution. The HIPL manual explicitly requires root for its experimental Android hipd port, a historical implementation-specific limitation. RFC 7402 sections 3.2 and 3.4 and Appendix A describe alternative ESP integration choices rather than prescribing an OS privilege model. Pinned OpenHIP hipv2_new_crypto source uses TUNSETIFF and raw ESP sockets in src/linux/hip_linux_umh.c. These are concrete privileged networking setup paths, but they do not alone establish the credentials retained after setup. The separate 2024 developer report documents a root-run CORE test environment; emulator privileges are not a measurement of daemon privileges.", "method": "Pinned candidate source trace and developer report; no execution", "source_label": "IETF HIP experiment report, ESP integration specification and HIPL author manual; retained source hashes", "sources": [ "https://www.rfc-editor.org/rfc/rfc7402.html", "https://mkomu.kapsi.fi/hipl/manual/HOWTO.html", "https://www.ida.liu.se/~TDDE21/info/hip_report_2024.pdf", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/util/hitgen.c", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/linux/hip_linux_umh.c", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/include/hip/hip_proto.h" ], "editorial_references": [ "round428.html", "round328-sources.json", "round428-sources.json" ], "qualification": "First identify a build matching the selected ECDSA profile; then trace retained credentials, delegated descriptors, SA and mobility updates. The 2024 report identifies ECDSA as nonworking in its own OpenSSL 3 branch. Do not transfer either that defect or the older branch privilege model to every HIP implementation." }, { "id": "D01-CX", "feature": "D01", "stack": "CX", "status": "Y", "reason": "The selected Ubuntu userspace CCNx/UDP path has a concrete ordinary-socket implementation: pinned Metis UdpListener creates AF_INET/SOCK_DGRAM, sets nonblocking mode and SO_REUSEADDR, and binds the configured address. Select a port above the privileged range and user-owned configuration/key files on an already provisioned IPv4 attachment. Local CCNx name-prefix forwarding and producer signing do not require changing shared host routes or interface addresses.", "method": "Documentary privilege-boundary plausibility; no new execution", "source_label": "Pinned Metis UDP and forwarder source; retained user-key and deployment evidence", "sources": [ "https://raw.githubusercontent.com/FDio/cicn/e59f9c7e0d731e02aa31c9092ce47f3aaa4d51bc/metis/ccnx/forwarder/metis/io/metis_UdpListener.c", "https://raw.githubusercontent.com/FDio/cicn/e59f9c7e0d731e02aa31c9092ce47f3aaa4d51bc/metis/ccnx/forwarder/metis/core/metis_Forwarder.c", "https://man7.org/linux/man-pages/man7/ip.7.html" ], "editorial_references": [ "round270-sources.json", "round303-sources.json", "round306-sources.json" ], "qualification": "Plausible userspace endpoint configuration, not a measured complete executable. Retain the UDP-only profile; raw Ethernet and VPP are not selected. Configure local control/client sockets and writable state under the user, with no privileged port or continuing elevated helper. Previously identified ECDSA codec integration gaps remain in E03-CX; this verdict does not assert that the pinned sample signs correctly without integration work. No new build or UID/capability execution occurred." }, { "id": "D01-LI", "feature": "D01", "stack": "LI", "status": "Y", "reason": "A Linux ordinary IPv4/UDP end host behind an administratively provisioned xTR needs no LISP protocol changes. Its routine high-port UDP socket communication needs neither root nor network-administration capabilities. Infrastructure routing and initial interface/EID provisioning remain administrative tasks.", "method": "Pinned source and documentation review", "source_label": "LISP RFC 9300; Linux socket/capability documentation; pinned lispers.net source as applicable", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-3", "https://man7.org/linux/man-pages/man7/ip.7.html" ], "editorial_references": [], "qualification": "Documentary endpoint-role result, not an unprivileged xTR claim or a completed end-to-end execution test." }, { "id": "D01-IL", "feature": "D01", "stack": "IL", "status": "Y", "reason": "The FreeBSD 14.3 ILNP release documents unmodified IPv6 nc and iperf3 binaries using ordinary stream sockets, with NID/L64 resolution supplied through modified libc. An ordinary client can use an ephemeral TCP port after administrative installation/provisioning; routine application traffic does not require raw sockets or routing privileges.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://ilnp.cs.st-andrews.ac.uk/freebsd/20260718-ietf126_hackathon/", "https://raw.githubusercontent.com/freebsd/freebsd-src/releng/14.3/share/man/man4/tcp.4", "https://raw.githubusercontent.com/freebsd/freebsd-src/releng/14.3/lib/libc/sys/socket.2" ], "editorial_references": [], "qualification": "Documentary feasibility inference from the supported sockets interface, not an observed non-root test: the demonstration does not report process credentials. Installing the modified kernel/libc and configuring interfaces/DNS require administration. Capture privileges, privileged server ports and infrastructure roles are not included." }, { "id": "D01-TS", "feature": "D01", "stack": "TS", "status": "N", "reason": "The selected standard Linux TUN deployment runs tailscaled as a privileged daemon. An ordinary application using its tunnel does not remove that runtime helper.", "method": "Official implementation and installation documentation review", "source_label": "Tailscale Linux installation and open-source component inventory", "sources": [ "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round584.html", "round584-sources.json" ], "qualification": "Selected standard Linux TUN and managed-control profile only. Headscale, tsnet and userspace proxy mode are different compositions. Documentary assessment, not a runtime test." }, { "id": "D01-RA", "feature": "D01", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Pin OS/version, endpoint role, executable, capabilities and helpers. Separate install/configure privileges from sustained operation. An untested adapter or UDP binding alone does not decide this criterion. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "D02-PN", "feature": "D02", "stack": "PN", "status": "Y", "reason": "Documentary plausibility on Linux: pinned prp-runtime exposes explicitly selected portable session/connection APIs with authenticated HS2 and protected E2E records over application-injected transport. Its documentation reports a component gate excluding PRP-specific kernel interfaces. libprp documents portable onion transforms and treats the PRP kernel module as optional acceleration. Combining these mechanisms with native Ethernet through stock Linux AF_PACKET provides a concrete module-free architectural path, rather than an assumption that the default kernel runtime is mandatory.", "method": "Documentary plausibility with explicit Linux carrier integration inference", "source_label": "Pinned PRP portable API and optional-module documentation; Linux socket manual", "sources": [ "https://man7.org/linux/man-pages/man7/packet.7.html" ], "editorial_references": [ "round234-sources.json", "round304-sources.json" ], "qualification": "This resolves architectural plausibility under the owner-approved standard, not availability of a complete supported executable. Carrier glue, selected 0x0202 adjacency/E2E integration, routing lifecycle and full endpoint operation without PRP kernel interfaces remain unqualified. The portable component gate is documentary evidence, not newly executed here. Stock Linux socket facilities and drivers must be enabled. Creating AF_PACKET sockets requires CAP_NET_RAW; this is not an unprivileged-runtime verdict. No change to D01, interoperability, performance or production-readiness findings." }, { "id": "D02-PI", "feature": "D02", "stack": "PI", "status": "Y", "reason": "Documentary plausibility on Linux: pinned prp-runtime exposes explicitly selected portable session/connection APIs with authenticated HS2 and protected E2E records over application-injected transport. Its documentation reports a component gate excluding PRP-specific kernel interfaces. libprp documents portable onion transforms and treats the PRP kernel module as optional acceleration. Combining these mechanisms with IPv4/UDP through stock Linux datagram sockets provides a concrete module-free architectural path, rather than an assumption that the default kernel runtime is mandatory.", "method": "Documentary plausibility with explicit Linux carrier integration inference", "source_label": "Pinned PRP portable API and optional-module documentation; Linux socket manual", "sources": [ "https://man7.org/linux/man-pages/man7/udp.7.html" ], "editorial_references": [ "round234-sources.json", "round304-sources.json" ], "qualification": "This resolves architectural plausibility under the owner-approved standard, not availability of a complete supported executable. Carrier glue, selected 0x0202 adjacency/E2E integration, routing lifecycle and full endpoint operation without PRP kernel interfaces remain unqualified. The portable component gate is documentary evidence, not newly executed here. Stock Linux socket facilities and drivers must be enabled. An ordinary UDP socket alone does not qualify the privileges of the complete endpoint. No change to D01, interoperability, performance or production-readiness findings." }, { "id": "D02-IP", "feature": "D02", "stack": "IP", "status": "Y", "reason": "Linux 6.12 provides stock IPv4/IPv6 networking. The selected datagram endpoint uses those facilities; BGP/PIM/IGMP/MLD control does not require an out-of-tree endpoint module. Stock features must be enabled by the OS image. This does not qualify every optional forwarding policy in a new runtime test.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/ipv6.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-BP", "feature": "D02", "stack": "BP", "status": "Y", "reason": "HDTN documents a userspace Linux implementation of BPv7/BPSec and TCPCLv4 with TLS 1.3, built with CMake, Boost, ZeroMQ and OpenSSL. Its IP/TCP transport uses the stock OS; no additional DTN kernel module or kernel rebuild is needed.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/runscript.sh" ], "editorial_references": [], "qualification": "Enable BPSec and TLS support and provision keys, policies and NODE-ID certificates. This requirement finding does not qualify the separate ION F16/F21 witnesses together or certify their complete integration." }, { "id": "D02-CG", "feature": "D02", "stack": "CG", "status": "Y", "reason": "The selected IPv4/TCP/TLS/TCPCLv4, BPv7/BPSec and contact-route processing have userspace implementations without a required added kernel module. HDTN documents Ubuntu 20.04.2 LTS and Debian 10.13 support with ordinary Boost, ZeroMQ and OpenSSL libraries; its TCPCLv4 path uses Boost.Asio sockets/TLS, while routing is C++ contact-plan processing. ION separately exposes CGR as C userspace code. The required OpenSSL FIPS module mentioned by HDTN is a cryptographic software component, not a Linux kernel module. Stock TCP/IP and ordinary NIC drivers suffice for this bounded deployment-dependency finding.", "method": "Documentary deployment-dependency assessment; no new build or execution", "source_label": "Pinned NASA HDTN and ION source/build documentation, reviewed 2026-10-15", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/CMakeLists.txt", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/tcpcl/src/TcpclV4BidirectionalLink.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/cgr/src/libcgr.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/module/router/src/router.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/bpsec/CMakeLists.txt", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/cgr/libcgr.c" ], "editorial_references": [ "round233-sources.json" ], "qualification": "This credits absence of an additional kernel-module dependency, not an end-to-end qualified SABR/BPv7 implementation. Exact SABR metadata/custody mapping, the selected ION delivery-policy integration with TCPCLv4/TLS, and full profile execution remain unresolved in E03-CG and related cells. No privilege-free operation, kernel configuration audit, new installation or runtime test is claimed. Do not replace TCPCLv4 with ION TCPCLv3." }, { "id": "D02-LT", "feature": "D02", "stack": "LT", "status": "Y", "reason": "A concrete userspace AOS/Encapsulation implementation is now identified at CCSDS library commit 3d8098a. Its stated baselines include Encapsulation 133.1-B-3 and AOS 732.0-B-4. EncapsulationPacket implements IPacket and recognizes LTP; AosSenderVirtualChannel dispatches packets into transfer frames, while AosReceiverVirtualChannel and its superclass extract/reassemble encapsulation packets. The TM/TC module exports Java APIs, has no native kernel dependency in its module descriptor, and targets Java 11. On stock Linux with JDK 17, standard AF_UNIX channels can connect a userspace adapter to the already identified HDTN Encapsulation local-stream boundary. Together with the existing userspace BP/BPSec/routing components, these facilities support module-free architectural plausibility.", "method": "Conditional module-dependency plausibility; no complete-stack execution", "source_label": "Pinned AOS/Encapsulation Java source, existing HDTN boundary and JDK local-socket API", "sources": [ "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/README.md", "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/eu.dariolucia.ccsds.tmtc/src/main/java/eu/dariolucia/ccsds/tmtc/datalink/channel/sender/AosSenderVirtualChannel.java", "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/eu.dariolucia.ccsds.tmtc/src/main/java/eu/dariolucia/ccsds/tmtc/datalink/channel/receiver/AosReceiverVirtualChannel.java", "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/eu.dariolucia.ccsds.tmtc/src/main/java/eu/dariolucia/ccsds/tmtc/datalink/channel/receiver/AbstractReceiverVirtualChannel.java", "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/eu.dariolucia.ccsds.tmtc/src/main/java/eu/dariolucia/ccsds/tmtc/transport/pdu/EncapsulationPacket.java", "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/eu.dariolucia.ccsds.tmtc/src/main/java/module-info.java", "https://github.com/dariol83/ccsds/blob/3d8098ad4bdb66a7ce9c59a8fc7eeb61a9ac4c5f/pom.xml", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/ltp/src/LtpEncapLocalStreamEngine.cpp", "https://docs.oracle.com/en/java/javase/17/core/internet-protocol-and-unix-domain-sockets-nio-example.html" ], "editorial_references": [ "round287-sources.json", "round319-sources.json", "round319-boundaries.json" ], "qualification": "Same documentary plausibility level as D02-RI, not a complete executable result. Required glue must preserve full Encapsulation packets and bind AOS virtual-channel/frame parameters in both directions; emitted AOS frames must reach the selected link through an existing stock driver/device interface. The witness assumes such a stock character/serial-device interface, not a new kernel AOS module or an IP/UDP replacement for AOS. Java callbacks are not a ready-made HDTN adapter. Exact BPv7/BPSec/SABR metadata integration, all-red LTP binding, physical-link provider/configuration and end-to-end testing remain unqualified. A configuration whose hardware needs an out-of-tree driver is outside this witness. D01 privileges, D03 specialized hardware, E03 completeness and mission/interoperability qualification remain unchanged. No build or runtime test was performed." }, { "id": "D02-LP", "feature": "D02", "stack": "LP", "status": "Y", "reason": "The inspected go-libp2p QUIC transport is userspace Go code using quic-go and UDP sockets. A Linux host with stock IP/UDP needs no libp2p-specific kernel module; native GSO/ECN facilities do not imply an out-of-tree dependency.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/libp2p/go-libp2p/master/p2p/transport/quic/transport.go" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-TO", "feature": "D02", "stack": "TO", "status": "Y", "reason": "The Tor daemon is packaged for ordinary Debian/Ubuntu amd64 and arm64 hosts. Onion v3 service configuration adds local files and a backend socket, not a special network device. This supported Linux userspace configuration needs no project-specific kernel module or kernel rebuild. The operating system provides ordinary TCP/IP sockets.", "method": "Primary-documentation analysis; no software execution", "source_label": "Tor onion service official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://support.torproject.org/little-t-tor/getting-started/installing/", "https://community.torproject.org/onion-services/setup/" ], "editorial_references": [], "qualification": "Documentary installation/dependency finding, not a new live deployment. Package installation, service configuration and interface privileges remain separate D01 questions. No claim that every distribution image enables all required stock facilities." }, { "id": "D02-I2", "feature": "D02", "stack": "I2", "status": "Y", "reason": "The Java router is distributed for Linux with Java 8 or later. The selected NTCP2 transport uses the host TCP stack; destination and tunnel processing are software operations. This supported Linux userspace configuration needs no project-specific kernel module or kernel rebuild. The operating system provides ordinary TCP/IP sockets.", "method": "Primary-documentation analysis; no software execution", "source_label": "I2P official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://i2p.net/en/downloads/", "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "Documentary installation/dependency finding, not a new live deployment. Package installation, service configuration and interface privileges remain separate D01 questions. No claim that every distribution image enables all required stock facilities." }, { "id": "D02-YG", "feature": "D02", "stack": "YG", "status": "Y", "reason": "The documented router runs as a userspace process and exposes host IPv6 through TUN. The selected TCP/TLS peerings use ordinary IP interfaces. This supported Linux userspace configuration needs no project-specific kernel module or kernel rebuild. Stock Linux TUN support must be available; D02 explicitly permits stock networking drivers. A host that omits or prohibits TUN is not this witness.", "method": "Primary-documentation analysis; no software execution", "source_label": "Yggdrasil official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://yggdrasil-network.github.io/implementation.html", "https://yggdrasil-network.github.io/installation.html" ], "editorial_references": [], "qualification": "Documentary installation/dependency finding, not a new live deployment. Package installation, service configuration and interface privileges remain separate D01 questions. No claim that every distribution image enables all required stock facilities." }, { "id": "D02-CJ", "feature": "D02", "stack": "CJ", "status": "Y", "reason": "The documented Debian-based build runs cjdroute with the host TUN interface and configured UDP peerings. It requires ordinary software dependencies and networking facilities. This supported Linux userspace configuration needs no project-specific kernel module or kernel rebuild. Stock Linux TUN support must be available; D02 explicitly permits stock networking drivers. A host that omits or prohibits TUN is not this witness.", "method": "Primary-documentation analysis; no software execution", "source_label": "cjdns official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/master/README.md", "https://docs.kernel.org/networking/tuntap.html" ], "editorial_references": [], "qualification": "Documentary installation/dependency finding, not a new live deployment. Package installation, service configuration and interface privileges remain separate D01 questions. No claim that every distribution image enables all required stock facilities." }, { "id": "D02-MQ", "feature": "D02", "stack": "MQ", "status": "Y", "reason": "Pinned picoquic c124cbe975f71b150ea929d325804335d2bdaa34 implements QUIC and its multipath scheduler in userspace. Its Linux build uses C/C++, picotls and OpenSSL, and the socket adapter uses stock UDP/IP. The locally retained Release build and round227 experiment execute proactive cross-path repetition without adding a kernel component or a physical accelerator. A supported Linux endpoint therefore needs no project-specific kernel module or kernel rebuild; ordinary stock UDP/IP facilities suffice. Optional DPDK/AF_XDP builds are not mandatory.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/README.md", "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/CMakeLists.txt", "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquic/picosocks.c" ], "editorial_references": [ "round226-runtime.json", "round227-runtime.json" ], "qualification": "Dependency finding only. Simulation is not live-network qualification, throughput evidence, unprivileged execution or full multipath-21 conformance. Positive path limits avoid the previously identified zero-limit negotiation deviation. D01 and E03 remain separate; this decision does not silently resolve them." }, { "id": "D02-SC", "feature": "D02", "stack": "SC", "status": "Y", "reason": "SCION documents Debian/Linux endhost packages and software daemon/application configuration. The selected UDP endhost service uses ordinary host IP networking, not a SCION-specific kernel module. Provider topology/TRC configuration and access to a SCION network remain necessary.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.scion.org/projects/scion-applications/en/latest/applications/access.html", "https://docs.scion.org/en/latest/dev/setup.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-RT", "feature": "D02", "stack": "RT", "status": "Y", "reason": "Reticulum 1.5.5 is distributed as a Python module, not a networking kernel module. For the selected SerialInterface on Linux, ordinary stock serial/USB drivers provide the device; no Reticulum-specific kernel module or kernel rebuild is required.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://reticulum.network/manual/using.html", "https://reticulum.network/manual/interfaces.html#serial-interface" ], "editorial_references": [], "qualification": "Use a Linux installation with the ordinary serial adapter driver available. Device permissions and any provisioning privileges remain the separate D01 question; no live endpoint test in this round." }, { "id": "D02-NS", "feature": "D02", "stack": "NS", "status": "Y", "reason": "A browser/JavaScript NIP-01 endpoint uses the native WSS/WebSocket API and software event signatures. On an ordinary Linux browser host this needs no Nostr-specific kernel module; relay processing remains a different role.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://github.com/nbd-wtf/nostr-tools", "https://websockets.spec.whatwg.org/", "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-MT", "feature": "D02", "stack": "MT", "status": "Y", "reason": "The selected native meshtasticd source includes a CH341 USB radio HAL using libpinedio, with libusb declared in Debian build dependencies. Its native build is a userspace program. On supported Debian 12/13 with standard USB facilities and a compatible real LoRa radio, no additional Meshtastic kernel module or kernel rebuild is required. This is the radio endpoint, not merely a serial-control CLI or simulated radio.", "method": "Documentary code/dependency analysis; no new execution or radio operation", "source_label": "Primary source and official installation review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/platform/portduino/USBHal.h", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/debian/control", "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/variants/native/portduino/platformio.ini", "https://meshtastic.org/docs/meshtasticd/installation/debian/" ], "editorial_references": [], "qualification": "Hardware compatibility, USB permissions and radio parameters must be provisioned. LoRa hardware remains mandatory (D03 stays No). No build, radio transmission or live driver test was executed." }, { "id": "D02-GN", "feature": "D02", "stack": "GN", "status": "Y", "reason": "The v0.20.x GNUnet documentation supplies userspace processes and libraries. The selected UDP/CORE/CADET composition excludes VPN, GNS and NAT helpers; it needs no GNUnet kernel module on Linux. Optional privileged helpers are not silently enabled.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.gnunet.org/v0.20.x/installing.html", "https://docs.gnunet.org/v0.20.x/users/configuration.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-ND", "feature": "D02", "stack": "ND", "status": "Y", "reason": "NFD 24.07 documents supported Debian 12 and Ubuntu 24.04 installations with ndn-cxx and libpcap for optional Ethernet faces. This userspace Ethernet/Unix-face configuration uses stock packet I/O, not an NDN kernel module. Raw-frame privileges are a separate D01 question.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.named-data.net/NFD/24.07/INSTALL.html", "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-AX", "feature": "D02", "stack": "AX", "status": "Y", "reason": "Linux 6.12 includes AX25 and NETROM as stock configurable networking features. A host image supplying these and its selected serial-link driver can load the supplied modules without an additional out-of-tree protocol module or kernel rebuild. This witness does not cover images omitting those features, nor qualify a serial device, port setup or a live NET/ROM circuit.", "method": "Documentary endpoint/profile analysis; no new software execution", "source_label": "Primary documentation and code reviewed 2026-10-15", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ax25/Kconfig", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/af_netrom.c" ], "editorial_references": [], "qualification": "Documented dependency/privilege witness only. No live deployment, permission trace, interoperability or performance qualification. Preserve the selected communication and privacy configuration." }, { "id": "D02-BA", "feature": "D02", "stack": "BA", "status": "Y", "reason": "The selected batman-adv is part of upstream Linux 6.12. A Linux 6.12 installation that supplies CONFIG_BATMAN_ADV can load its stock module without adding an out-of-tree module or rebuilding the kernel. D02 explicitly allows stock networking modules; an OS image omitting this feature is outside this witness.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-BL", "feature": "D02", "stack": "BL", "status": "Y", "reason": "The selected IPv6/Babel service uses Linux IP forwarding and a userspace babeld daemon. A supplied stock IPv6 kernel suffices; interface/route setup and daemon privileges are not an additional protocol-specific kernel module.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://www.irif.fr/~jch/software/babel/babeld.html", "https://www.kernel.org/doc/html/v6.12/networking/ipv6.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D02-RI", "feature": "D02", "stack": "RI", "status": "Y", "reason": "Linux 6.12 provides stock IEEE 802.15.4/6LoWPAN networking with RFC 6282 IPHC and ordinary IPv6/UDP sockets. Its source includes RPL routing-header handling and an IPV6_RPL_LWTUNNEL configuration option for RFC 6554. The RPL leaf control exchange can plausibly be implemented in userspace through existing ICMPv6 facilities, while a userspace DTLS 1.3 library protects endpoint UDP records. These concrete facilities support a composition without a new out-of-tree networking module.", "method": "Documentary module-dependency plausibility; complete composition not executed", "source_label": "Linux 6.12 kernel documentation/source, wolfSSL DTLS API documentation and selected RFCs", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/ieee802154.html", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ipv6/rpl.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ipv6/Kconfig", "https://www.wolfssl.com/documentation/manuals/wolfssl/chapter04.html", "https://www.rfc-editor.org/rfc/rfc6550.html", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round307-sources.json" ], "qualification": "Conditional architectural plausibility, not a complete executable or interoperability result. Choose a stock kernel build with the necessary IPv6, 802.15.4, 6LoWPAN and RPL-header facilities already enabled and a supported radio driver; a build lacking them may require replacement or rebuilding and is not this witness. Stock modules are permitted by D02. RPL header support alone is not an RPL control-plane implementation: OF0, non-storing leaf signaling, RFC 6775 registration and the selected external-PSK DTLS 1.3 integration remain unqualified. The wolfSSL feature documentation supplies a userspace DTLS 1.3 candidate, not proof of the exact psk_ke/AES-128-GCM configuration. No root-free operation, radio-free hardware, runtime test or E03 completeness is inferred." }, { "id": "D02-HP", "feature": "D02", "stack": "HP", "status": "Y", "reason": "HIPL documents userspace HIP with Linux BEET IPsec support included from kernel 2.6.27 onward, and separately documents selectable HIPv2 associations. Thus the HIP-control/ESP architecture has a documented Linux path using stock kernel networking features rather than a mandatory extra kernel module.", "method": "Documentary and source review; no new runtime execution", "source_label": "Primary specifications, retained implementation sources and deployment documentation", "sources": [ "https://mkomu.kapsi.fi/hipl/manual/HOWTO.html#ch_requirements", "https://mkomu.kapsi.fi/hipl/manual/HOWTO.html#ch_dual_version_support" ], "editorial_references": [ "round270-sources.json" ], "qualification": "Choose a general-purpose Linux kernel with required XFRM/ESP/BEET and crypto features enabled. This is the module-dependency boundary, not proof that the archived HIPL version implements every selected RFC 7401/7402/8046 and suite detail. E03 remains Pending. Android custom-kernel instructions are a separate platform, not this witness." }, { "id": "D02-CX", "feature": "D02", "stack": "CX", "status": "Y", "reason": "The documented socket-based CCNx forwarder uses standard userspace dependencies. Pinned Metis creates AF_INET/SOCK_DGRAM sockets for the selected UDP path; its CMake dependencies include Libevent, OpenSSL and CCNx libraries, not an added networking kernel module. Ubuntu is a documented host platform.", "method": "Documentary and source review; no new runtime execution", "source_label": "Primary specifications, retained implementation sources and deployment documentation", "sources": [ "https://raw.githubusercontent.com/FDio/cicn/e59f9c7e0d731e02aa31c9092ce47f3aaa4d51bc/metis/ccnx/forwarder/metis/io/metis_UdpListener.c", "https://raw.githubusercontent.com/FDio/cicn/e59f9c7e0d731e02aa31c9092ce47f3aaa4d51bc/metis/CMakeLists.txt", "https://wiki.fd.io/view/Cicn" ], "editorial_references": [ "round270-sources.json" ], "qualification": "This is a deployment-dependency finding. Stock IP/UDP support is required; raw Ethernet and VPP modes are not selected. Exact RFC revision, ECDSA producer integration and a fresh build remain unqualified in E03. No privilege-free or runtime-conformance claim. " }, { "id": "D02-LI", "feature": "D02", "stack": "LI", "status": "Y", "reason": "The selected ordinary Linux IPv4/UDP endpoint uses the stock IP stack and socket API behind an external xTR. LISP encapsulation and mapping roles reside in infrastructure; no additional endpoint kernel module or rebuilt kernel is required for this role.", "method": "Pinned source and documentation review", "source_label": "LISP RFC 9300; Linux socket/capability documentation; pinned lispers.net source as applicable", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-1", "https://docs.python.org/3/library/socket.html" ], "editorial_references": [], "qualification": "Endpoint-only result. Infrastructure implementation and installation requirements remain separate." }, { "id": "D02-IL", "feature": "D02", "stack": "IL", "status": "N", "reason": "The documented ILNP endpoint implementations modify the host kernel: the Linux prototype supplies a replacement Linux 4.9 kernel, and the FreeBSD implementation modifies the kernel networking stack. Unmodified application binaries do not imply an unmodified operating-system kernel.", "method": "Primary-source review and explicitly bounded composition inference; no execution", "source_label": "RFCs, project release evidence and OS interface documentation", "sources": [ "https://ilnp.github.io/ilnp-public-1/", "https://ilnp.cs.st-andrews.ac.uk/freebsd/20231105-ietf118_hackathon/20231106_ilnp_ietf118_freebsd14_demo.pdf", "https://ilnp.cs.st-andrews.ac.uk/freebsd/20260718-ietf126_hackathon/" ], "editorial_references": [], "qualification": "No for the identified implementations, including the documented FreeBSD release lineage; not a proof that a future userspace or stock-kernel implementation is impossible. D01 distinguishes routine user privileges from privileged installation." }, { "id": "D02-TS", "feature": "D02", "stack": "TS", "status": "Y", "reason": "The documented Linux deployment uses the stock TUN module and distributed userspace binaries. No additional protocol kernel module or kernel rebuild is required on a supported distribution with TUN available.", "method": "Official implementation and installation documentation review", "source_label": "Tailscale Linux installation and open-source component inventory", "sources": [ "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round584.html", "round584-sources.json" ], "qualification": "Selected standard Linux TUN and managed-control profile only. Headscale, tsnet and userspace proxy mode are different compositions. Documentary assessment, not a runtime test." }, { "id": "D02-RA", "feature": "D02", "stack": "RA", "status": "N", "reason": "The selected IRATI/Linux Ethernet composition explicitly loads the IRATI core, normal IPC-process and Ethernet VLAN shim kernel modules. It therefore requires additional kernel support.", "method": "Primary specification and implementation documentation review; no runtime experiment", "source_label": "RFC 1633, RFC 7567, RFC 2475 or IRATI Ethernet tutorial, as linked", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)" ], "editorial_references": [ "round650.html" ], "qualification": "Applies to IRATI as selected, not every RINA implementation or a hypothetical userspace port. Privileged provisioning alone does not decide D01 routine endpoint operation; D01 remains pending." }, { "id": "D03-PN", "feature": "D03", "stack": "PN", "status": "Y", "reason": "The inspected Linux native Ethernet binding uses ordinary networking facilities: net_device lookup and standard Ethernet transmission. The runtime supplies a preferred-suite software crypto callback, and libprp provides software ML-KEM/X25519 operations. No specialized radio, cryptographic accelerator, DPU or secure element is mandatory for this configuration. Additional software modules and setup privileges are distinct D01/D02 questions. The inspected shared-reference TX path requires NETIF_F_SG, 4-KiB pages and bounded link-headroom/build-charge conditions; ordinary NIC support is configuration-specific, not universal.", "method": "Read-only implementation and test-fixture inspection; no new runtime execution", "source_label": "Pinned runtime, core carrier and IP carrier source inventory in round203-sources.json", "sources": [], "editorial_references": [ "round203.html", "round203-sources.json" ], "qualification": "No new physical-NIC, throughput, latency or end-to-end hardware qualification is claimed. Retain the selected 0x0202 and carrier when measuring performance; optional hardware acceleration is not credited as mandatory." }, { "id": "D03-PI", "feature": "D03", "stack": "PI", "status": "Y", "reason": "The inspected Linux IPv4/UDP binding uses ordinary networking facilities: AF_INET/SOCK_DGRAM sockets and kernel_sendmsg. The runtime supplies a preferred-suite software crypto callback, and libprp provides software ML-KEM/X25519 operations. No specialized radio, cryptographic accelerator, DPU or secure element is mandatory for this configuration. Additional software modules and setup privileges are distinct D01/D02 questions.", "method": "Read-only implementation and test-fixture inspection; no new runtime execution", "source_label": "Pinned runtime, core carrier and IP carrier source inventory in round203-sources.json", "sources": [], "editorial_references": [ "round203.html", "round203-sources.json" ], "qualification": "No new physical-NIC, throughput, latency or end-to-end hardware qualification is claimed. Retain the selected 0x0202 and carrier when measuring performance; optional hardware acceleration is not credited as mandatory." }, { "id": "D03-IP", "feature": "D03", "stack": "IP", "status": "Y", "reason": "The selected IP datagram and routing composition can run on general-purpose Linux computers with ordinary Ethernet NICs. Software IPv6 and routing do not mandate a radio, crypto accelerator or secure element. High-capacity deployment sizing is a separate G05 question.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/ipv6.html", "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [], "qualification": "This is a documented commodity-host configuration, not a global-capacity or NIC certification result." }, { "id": "D03-BP", "feature": "D03", "stack": "BP", "status": "Y", "reason": "The same published HDTN build supports ordinary x86-64 Linux hosts and ARM platforms. TCPCLv4/TLS and BPv7/BPSec operate over standard network interfaces; specialized acceleration and RDSEED options can be disabled. Space-qualified radios or custom forwarding hardware are not mandatory for this IP-based profile.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md" ], "editorial_references": [], "qualification": "Commodity hardware is a functional requirement finding, not a throughput target or a space-link qualification. This does not transfer to the separately selected non-IP LTP/AOS column." }, { "id": "D03-CG", "feature": "D03", "stack": "CG", "status": "Y", "reason": "The selected CGR column uses ordinary IPv4/TCP networking rather than a mandatory space-radio or AOS link. HDTN documents commodity Linux x86/ARM platforms and software TCPCLv4/TLS, BPv7/BPSec and contact-plan routing. Its CMake/README explicitly allow USE_X86_HARDWARE_ACCELERATION and LTP_RNG_USE_RDSEED to be disabled; optional optimized CPU paths or external acceleration hooks are not a required radio, accelerator or secure element. ION CGR is also ordinary C route computation. This establishes the documented hardware dependency boundary without attributing a measured scale or throughput.", "method": "Documentary deployment-dependency assessment; no new build or execution", "source_label": "Pinned NASA HDTN and ION source/build documentation, reviewed 2026-10-15", "sources": [ "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/CMakeLists.txt", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/tcpcl/src/TcpclV4BidirectionalLink.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/cgr/src/libcgr.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/module/router/src/router.cpp", "https://github.com/nasa/HDTN/blob/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/bpsec/CMakeLists.txt", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/cgr/libcgr.c" ], "editorial_references": [ "round233-sources.json" ], "qualification": "Credit a commodity host and ordinary NIC for the IPv4 CGR composition only. This does not extend to the separate LTP/Encapsulation/AOS column or imply a particular physical space link is commodity. Complete selected-profile integration and runtime validation remain pending; optional acceleration benchmarks, mission hardware and protocol conformance are not inferred." }, { "id": "D03-LT", "feature": "D03", "stack": "LT", "status": "N", "reason": "The selected column is BPv7/BPSec over LTP, Encapsulation and operational AOS space links, not LTP over an ordinary IP interface. AOS 732.0-B-4 sections 1.1 and 1.6 define spacecraft/ground and spacecraft/spacecraft links; section 2.4 assumes lower-layer transfer services. An endpoint participating directly in that operational space link requires suitable space-link communications hardware. An ordinary Ethernet or Wi-Fi NIC alone does not supply that link. Under D03, this mandatory carrier constraint makes the selected composition No, using the same rule applied to the selected LoRa and IEEE 802.15.4 compositions.", "method": "Selected-carrier hardware inference; no runtime execution", "source_label": "AOS B-4 scope and lower-layer assumptions; CCSDS protocol overview; NASA SDR example", "sources": [ "https://ccsds.org/Pubs/732x0b4.pdf", "https://ccsds.org/Pubs/130x0g2s.pdf", "https://software.nasa.gov/software/LEW-19723-1" ], "editorial_references": [ "round638.html", "round636.html" ], "qualification": "This is a scope-based documentary inference for the selected operational AOS binding, consistent with S03-LT. AOS section 1.2 leaves implementation methods and products unspecified: no particular radio, FPGA, accelerator or secure element is claimed mandatory. LTP and AOS frame processing can run in software on commodity CPUs. A simulator, ground-only byte transport, remote radio gateway or LTP-over-UDP configuration is not substituted for the selected direct space-link endpoint. The NASA SDR example uses earlier AOS B-2 and illustrates hardware/software separation only; it is not a complete B-4/BPv7/BPSec interoperability witness. No new hardware or runtime test was executed." }, { "id": "D03-LP", "feature": "D03", "stack": "LP", "status": "Y", "reason": "The selected Go QUIC/libp2p endpoint processes transport and peer authentication in software over ordinary IP/UDP. A commodity Linux host and ordinary NIC suffice; no dedicated radio or cryptographic accelerator is required.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/libp2p/go-libp2p/master/p2p/transport/quic/transport.go" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D03-TO", "feature": "D03", "stack": "TO", "status": "Y", "reason": "The Tor daemon is packaged for ordinary Debian/Ubuntu amd64 and arm64 hosts. Onion v3 service configuration adds local files and a backend socket, not a special network device. A commodity Linux computer with an ordinary IP-capable NIC suffices; no dedicated radio, secure element, cryptographic accelerator or routing appliance is mandatory for this profile.", "method": "Primary-documentation analysis; no software execution", "source_label": "Tor onion service official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://support.torproject.org/little-t-tor/getting-started/installing/", "https://community.torproject.org/onion-services/setup/" ], "editorial_references": [], "qualification": "This is a hardware-dependency finding, not a throughput, scale or universal-device compatibility qualification. Keep the selected transport and privacy configuration in any performance test." }, { "id": "D03-I2", "feature": "D03", "stack": "I2", "status": "Y", "reason": "The Java router is distributed for Linux with Java 8 or later. The selected NTCP2 transport uses the host TCP stack; destination and tunnel processing are software operations. A commodity Linux computer with an ordinary IP-capable NIC suffices; no dedicated radio, secure element, cryptographic accelerator or routing appliance is mandatory for this profile.", "method": "Primary-documentation analysis; no software execution", "source_label": "I2P official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://i2p.net/en/downloads/", "https://i2p.net/en/docs/specs/ntcp2/" ], "editorial_references": [], "qualification": "This is a hardware-dependency finding, not a throughput, scale or universal-device compatibility qualification. Keep the selected transport and privacy configuration in any performance test." }, { "id": "D03-YG", "feature": "D03", "stack": "YG", "status": "Y", "reason": "The documented router runs as a userspace process and exposes host IPv6 through TUN. The selected TCP/TLS peerings use ordinary IP interfaces. A commodity Linux computer with an ordinary IP-capable NIC suffices; no dedicated radio, secure element, cryptographic accelerator or routing appliance is mandatory for this profile.", "method": "Primary-documentation analysis; no software execution", "source_label": "Yggdrasil official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://yggdrasil-network.github.io/implementation.html", "https://yggdrasil-network.github.io/installation.html" ], "editorial_references": [], "qualification": "This is a hardware-dependency finding, not a throughput, scale or universal-device compatibility qualification. Keep the selected transport and privacy configuration in any performance test." }, { "id": "D03-CJ", "feature": "D03", "stack": "CJ", "status": "Y", "reason": "The documented Debian-based build runs cjdroute with the host TUN interface and configured UDP peerings. It requires ordinary software dependencies and networking facilities. A commodity Linux computer with an ordinary IP-capable NIC suffices; no dedicated radio, secure element, cryptographic accelerator or routing appliance is mandatory for this profile.", "method": "Primary-documentation analysis; no software execution", "source_label": "cjdns official installation/architecture documentation, reviewed 2026-10-15", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/master/README.md", "https://docs.kernel.org/networking/tuntap.html" ], "editorial_references": [], "qualification": "This is a hardware-dependency finding, not a throughput, scale or universal-device compatibility qualification. Keep the selected transport and privacy configuration in any performance test." }, { "id": "D03-MQ", "feature": "D03", "stack": "MQ", "status": "Y", "reason": "Pinned picoquic c124cbe975f71b150ea929d325804335d2bdaa34 implements QUIC and its multipath scheduler in userspace. Its Linux build uses C/C++, picotls and OpenSSL, and the socket adapter uses stock UDP/IP. The locally retained Release build and round227 experiment execute proactive cross-path repetition without adding a kernel component or a physical accelerator. An ordinary CPU and IP-capable NIC suffice; no dedicated radio, secure element or crypto accelerator is mandatory. The selected two paths require two usable IP routes, not specialized computing hardware.", "method": "Primary-document and source-scope analysis; no new full-stack execution", "source_label": "Primary evidence reviewed 2026-10-15; retained hashes in round228-sources.json", "sources": [ "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/README.md", "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/CMakeLists.txt", "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquic/picosocks.c" ], "editorial_references": [ "round226-runtime.json", "round227-runtime.json" ], "qualification": "Dependency finding only. Simulation is not live-network qualification, throughput evidence, unprivileged execution or full multipath-21 conformance. Positive path limits avoid the previously identified zero-limit negotiation deviation. D01 and E03 remain separate; this decision does not silently resolve them." }, { "id": "D03-SC", "feature": "D03", "stack": "SC", "status": "Y", "reason": "SCION documents endhost and development operation on general-purpose Linux machines, including Ubuntu 18.04+ and Fedora 38+. The selected UDP endpoint has no mandatory specialized radio, secure element or forwarding appliance; network-provider availability is a separate constraint.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.scion.org/en/latest/dev/setup.html", "https://docs.scion.org/projects/scion-applications/en/latest/applications/access.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D03-RT", "feature": "D03", "stack": "RT", "status": "Y", "reason": "The selected Reticulum 1.5.5 SerialInterface can connect ordinary serial ports directly over a wire pair. A commodity serial port or USB serial adapter suffices; a radio, RNode or other specialized transceiver is not mandatory for this selected serial profile.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://reticulum.network/manual/interfaces.html#serial-interface", "https://reticulum.network/manual/understanding.html" ], "editorial_references": [], "qualification": "Serial hardware and ordinary OS drivers remain required. This does not qualify a radio deployment or physical-link performance." }, { "id": "D03-NS", "feature": "D03", "stack": "NS", "status": "Y", "reason": "The selected NIP-01 author/reader can sign and verify events in JavaScript and communicate over WSS on an ordinary computer. No dedicated radio or signing hardware is mandatory. Extension-based or hardware key custody is optional, not credited here.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://github.com/nbd-wtf/nostr-tools", "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D03-MT", "feature": "D03", "stack": "MT", "status": "N", "reason": "The selected standalone Meshtastic LoRa mesh requires a supported LoRa transceiver and compatible firmware hardware. A serial management client does not replace the radio node. Commercial availability or low cost does not remove the specialized-radio requirement in D03.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://meshtastic.org/docs/hardware/devices/", "https://meshtastic.org/docs/overview/encryption/" ], "editorial_references": [], "qualification": "" }, { "id": "D03-GN", "feature": "D03", "stack": "GN", "status": "Y", "reason": "The selected GNUnet UDP/CORE/CADET implementation uses software libraries and ordinary Linux networking. Its dependency list requires no specialized radio, secure element or cryptographic accelerator.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.gnunet.org/v0.20.x/installing.html", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D03-ND", "feature": "D03", "stack": "ND", "status": "Y", "reason": "NFD 24.07 supports ordinary Debian/Ubuntu computers and direct Ethernet faces through libpcap. Commodity Ethernet hardware and software ECDSA suffice; no special NDN forwarding hardware or secure element is mandatory.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.named-data.net/NFD/24.07/INSTALL.html", "https://docs.named-data.net/NFD/24.07/manpages/nfdc-face.html" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D03-AX", "feature": "D03", "stack": "AX", "status": "Y", "reason": "The already selected private direct-serial role can use the historical NET/ROM RS232 interconnection with ordinary serial interfaces. A dedicated RF modem or transceiver is not mandatory for that wired role. This finding does not cover the alternative radio deployment.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://hamgate.ampr.org/docs/1987_netrom_version_1_3.pdf" ], "editorial_references": [], "qualification": "Documented dependency finding only. No live carrier test, capacity result or universal OS/device certification; setup privileges remain separate." }, { "id": "D03-BA", "feature": "D03", "stack": "BA", "status": "Y", "reason": "Linux 6.12 batman-adv supports ordinary Ethernet-style interfaces and Ethernet LANs. Its selected native Ethernet service requires no dedicated mesh radio or accelerator. Kernel configuration and administrative interface setup are separate requirements.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [], "qualification": "No claim of support for every NIC or proof of measured mesh capacity." }, { "id": "D03-BL", "feature": "D03", "stack": "BL", "status": "Y", "reason": "The selected IPv6/Babel composition can use ordinary Ethernet interfaces on Linux hosts with the software babeld implementation. Neither the protocol nor this implementation requires a specialized radio or forwarding accelerator. The configured hierarchical topology is unchanged.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://www.irif.fr/~jch/software/babel/", "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [], "qualification": "No new babeld execution or hardware/performance qualification; keep the selected routing-policy configuration when testing." }, { "id": "D03-RI", "feature": "D03", "stack": "RI", "status": "N", "reason": "The selected link is IEEE 802.15.4. An actual endpoint on that link needs an IEEE 802.15.4-capable transceiver; an ordinary Ethernet or Wi-Fi interface alone does not implement it. Under D03, mandatory specialized-radio hardware does not qualify even if inexpensive or commercially available.", "method": "Documentary and source review; no new runtime execution", "source_label": "Primary specifications, retained implementation sources and deployment documentation", "sources": [ "https://www.rfc-editor.org/rfc/rfc4944.html#section-3" ], "editorial_references": [ "round270-sources.json" ], "qualification": "This is a requirement of the selected physical-link binding, not of all IPv6 or all RPL deployments. A serial gateway or simulated link does not silently replace that binding. Apply the same rule used for the selected standalone LoRa column." }, { "id": "D03-HP", "feature": "D03", "stack": "HP", "status": "Y", "reason": "The documented HIPL Linux deployment implements host control in software and uses ordinary Linux IPsec for ESP over IP. No specialized radio, accelerator or secure element is a mandatory component of the selected HIP/ESP host architecture.", "method": "Documentary and source review; no new runtime execution", "source_label": "Primary specifications, retained implementation sources and deployment documentation", "sources": [ "https://mkomu.kapsi.fi/hipl/manual/HOWTO.html#ch_requirements" ], "editorial_references": [ "round270-sources.json" ], "qualification": "Ordinary IP connectivity and software cryptography are the witness. Exact selected-suite integration, privileges and fresh execution remain separately unqualified; this is not a hardware throughput claim." }, { "id": "D03-CX", "feature": "D03", "stack": "CX", "status": "Y", "reason": "The socket-based CCNx implementation uses ordinary host computation and standard IP/UDP sockets. Its documented Linux and macOS deployments and software library dependencies require no specialized radio, cryptographic accelerator or secure element for this composition.", "method": "Documentary and source review; no new runtime execution", "source_label": "Primary specifications, retained implementation sources and deployment documentation", "sources": [ "https://raw.githubusercontent.com/FDio/cicn/e59f9c7e0d731e02aa31c9092ce47f3aaa4d51bc/metis/CMakeLists.txt", "https://raw.githubusercontent.com/FDio/cicn/e59f9c7e0d731e02aa31c9092ce47f3aaa4d51bc/metis/ccnx/forwarder/metis/io/metis_UdpListener.c", "https://raw.githubusercontent.com/parc-ccnx-archive/CCNx_Distillery/2c2ac350f4282e65a07949eb94f605cd9a73608d/README.md" ], "editorial_references": [ "round270-sources.json" ], "qualification": "Credit the hardware dependency boundary only. No performance, present-day build compatibility or complete selected-profile execution is inferred. Do not substitute the VPP/raw-Ethernet variant. " }, { "id": "D03-LI", "feature": "D03", "stack": "LI", "status": "Y", "reason": "Ordinary Linux IPv4/UDP hosts with conventional NICs can serve as LISP end systems. The pinned lispers.net implementation additionally documents software routing on Ubuntu/Debian and other general-purpose systems; specialized hardware is not mandatory for the selected role.", "method": "Pinned source and documentation review", "source_label": "LISP RFC 9300; Linux socket/capability documentation; pinned lispers.net source as applicable", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-3", "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/README.md" ], "editorial_references": [], "qualification": "No throughput, radio, deployment or interoperability qualification is inferred from platform support." }, { "id": "D03-IL", "feature": "D03", "stack": "IL", "status": "Y", "reason": "The documented DNS/ILNP/TCP experiment used a Lenovo ThinkCentre M720q client with an Intel i5-8400T and conventional Ethernet NICs, and a desktop-class Ryzen 7 5800X server. These demonstrate a commodity endpoint role without a required special radio, accelerator or secure element.", "method": "Primary experiment/release documentation review", "source_label": "ILNP project experiment and release records", "sources": [ "https://ilnp.cs.st-andrews.ac.uk/freebsd/20260718-ietf126_hackathon/" ], "editorial_references": [], "qualification": "Project-attributed demonstration, not local execution. The endpoint software includes ILNP-specific OS changes; this positive does not imply D01, D02, interoperability or complete source availability." }, { "id": "D03-TS", "feature": "D03", "stack": "TS", "status": "Y", "reason": "Supported mainstream Linux distributions and ordinary CPU-architecture binaries provide a commodity endpoint deployment. No specialized radio, accelerator or secure element is mandatory for the selected IP overlay.", "method": "Official implementation and installation documentation review", "source_label": "Tailscale Linux installation and open-source component inventory", "sources": [ "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round584.html", "round584-sources.json" ], "qualification": "Selected standard Linux TUN and managed-control profile only. Headscale, tsnet and userspace proxy mode are different compositions. Documentary assessment, not a runtime test." }, { "id": "D03-RA", "feature": "D03", "stack": "RA", "status": "Y", "reason": "The tutorial uses Linux systems with Ethernet VLAN interfaces and discusses VirtualBox adapters, providing a commodity-host deployment example without a mandatory dedicated radio, accelerator or secure element.", "method": "Primary deployment documentation and architectural dependency inference; no execution", "source_label": "IRATI Ethernet tutorial and software architecture documentation", "sources": [ "https://github.com/IRATI/stack/wiki/Tutorial-1:-DIF-over-a-VLAN-(point-to-point-DIF)", "https://github.com/IRATI/stack/wiki/Software-architecture-overview" ], "editorial_references": [ "round651.html" ], "qualification": "Ordinary VLAN-capable networking is required; the tutorial warns about a virtual adapter that strips tags. Kernel dependencies remain covered by D02. No claim about every NIC, present-day build compatibility or physical-device validation." }, { "id": "D04-PN", "feature": "D04", "stack": "PN", "status": "Y", "reason": "The selected PRP profile uses locally controlled identity key material independently of carrier locators. Architecture section 4.4 distinguishes IDENTITY SCIR public-key commitments from machine addresses. libprp exposes keypair generation and signing; the portable session configuration takes local identity material or a key handle separately from injected transport. Runtime documents identity storage protected by an application-held wrapping key. Additional identities therefore do not require additional host interface addresses or routes on an already authorized transport. This is a documented architectural/component capability, not a newly executed multiuser deployment.", "method": "Initial evidence inventory", "source_label": "Pinned architecture, hybrid identity API, portable session configuration and runtime documentation", "sources": [], "editorial_references": [ "round238.html", "round238-sources.json" ], "qualification": "D01 remains Pending: full selected native/UDP endpoint operation and privileged helper dependencies are not qualified by this Yes. Existing carrier provisioning and access permission are assumed, not removed. Counterparties still decide whether to accept a newly created identity. The criterion does not guarantee quotas, protection from key theft, or zero resource interference between users." }, { "id": "D04-PI", "feature": "D04", "stack": "PI", "status": "Y", "reason": "The selected PRP profile uses locally controlled identity key material independently of carrier locators. Architecture section 4.4 distinguishes IDENTITY SCIR public-key commitments from machine addresses. libprp exposes keypair generation and signing; the portable session configuration takes local identity material or a key handle separately from injected transport. Runtime documents identity storage protected by an application-held wrapping key. Additional identities therefore do not require additional host interface addresses or routes on an already authorized transport. This is a documented architectural/component capability, not a newly executed multiuser deployment.", "method": "Initial evidence inventory", "source_label": "Pinned architecture, hybrid identity API, portable session configuration and runtime documentation", "sources": [], "editorial_references": [ "round238.html", "round238-sources.json" ], "qualification": "D01 remains Pending: full selected native/UDP endpoint operation and privileged helper dependencies are not qualified by this Yes. Existing carrier provisioning and access permission are assumed, not removed. Counterparties still decide whether to accept a newly created identity. The criterion does not guarantee quotas, protection from key theft, or zero resource interference between users." }, { "id": "D04-IP", "feature": "D04", "stack": "IP", "status": "N", "reason": "Plain IPv4/IPv6 supplies interface addressing, not independently controlled per-user communication identities. RFC 4291 sections 2 and 2.1 define IPv6 addresses as interface identifiers; adding addresses to a shared Linux interface is network administration. An ordinary process using an existing address, including the delegated raw sockets tested for D01, has not created its own protocol identity. The selected IP column excludes application authentication and IPsec, so keys added by TLS, JWT or an overlay cannot be credited here.", "method": "Initial evidence inventory", "source_label": "IP addressing architecture and Linux capability boundary", "sources": [ "https://www.rfc-editor.org/rfc/rfc4291.html#section-2.1", "https://man7.org/linux/man-pages/man7/capabilities.7.html" ], "editorial_references": [ "round234-raw-ip-result.json" ], "qualification": "This No is about the selected plain-IP capability, not a claim that every address change needs a human administrator. SLAAC/DHCP, delegated namespaces and virtual interfaces can automate or isolate address administration; they do not supply this selected stack with a user-controlled identity independent of interface addressing. D01-IP remains Yes with its existing setup and loopback qualifications." }, { "id": "D04-BP", "feature": "D04", "stack": "BP", "status": "Y", "reason": "Pinned HDTN BPGen and BPSink accept a local endpoint EID through --my-uri-eid and load per-process BPSec configuration. BpSourcePattern places that EID in the primary block, selects its security policy and applies it to outgoing bundles. BpSecPolicyManager reads keys from configured files. Separate ordinary-user processes can select additional local private-ipn identities and hold separate key/configuration files over an already authorized TCPCL/TLS transport without changing host interface addresses, prefixes or routes.", "method": "Documentary classification; no new runtime experiment", "source_label": "Pinned HDTN source retained with SHA-256, 2026-10-15", "sources": [ "https://raw.githubusercontent.com/nasa/HDTN/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/bpcodec/src/app_patterns/BpSourcePattern.cpp", "https://raw.githubusercontent.com/nasa/HDTN/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/bpcodec/apps/bpgen/src/BpGenAsyncRunner.cpp", "https://raw.githubusercontent.com/nasa/HDTN/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/bpcodec/apps/bpsink/BpSinkAsyncRunner.cpp", "https://raw.githubusercontent.com/nasa/HDTN/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/common/bpsec/src/BpSecPolicyManager.cpp", "https://raw.githubusercontent.com/nasa/HDTN/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/config_files/bpsec/ipn1.1_con_plus_int.json", "https://raw.githubusercontent.com/nasa/HDTN/7fbe90cdbe3c8c737efaacb5985f881f95fc7d2a/README.md" ], "editorial_references": [ "round243-sources.json" ], "qualification": "Local private-ipn endpoint/BPSec identity capability, building on D01-BP's ordinary-user high-port endpoint path. This does not grant globally unique EIDs, automatic routing or peer trust. Use separate user-owned credentials and policies; distributed sample keys are not secret credentials. Pairwise BPSec key holders share authentication authority, so this is not an exclusive asymmetric identity claim. Peer acceptance and transport permission remain separate. No fresh multi-user execution or complete-profile interoperability is claimed. Do not transfer this finding to CGR/SABR or LTP/AOS." }, { "id": "D04-CG", "feature": "D04", "stack": "CG", "status": "Y", "reason": "A concrete local-ownership construction uses an already provisioned user-owned BP node instance. ION documents separate SDR databases/working-memory keys and local directories for multiple instances; bprc adds local endpoint EIDs, and ionsecrc loads locally held named keys. Additional service EIDs under the same provisioned node number, with distinct local BPSec key/policy contexts, can plausibly be created without changing host interfaces or routes. Managing an owned protocol database is distinct from requiring host-network administrator privileges.", "method": "Documentary local-identity ownership plausibility; no runtime isolation test", "source_label": "Pinned ION multi-instance, local endpoint and local key configuration", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/bprc.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod5/ionconfig.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod5/ionsecrc.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod1/ionadmin.pod" ], "editorial_references": [ "round228-sources.json", "round308-sources.json" ], "qualification": "Keep the provisioned TCPCL/TLS node transport and CGR contact/exit configuration unchanged. Credit local endpoint/service identities and user-held security context only. The user must already own its instance/store and authorized node transport; this does not grant a user control over a shared administrator-owned ION database. Avoid shared default IPC keys and use owned files. Peer trust/key acceptance is separate. Shared symmetric BPSec keys do not prove exclusive asymmetric authorship. Exact BSL key-provider/profile integration and multi-user isolation have not been executed; no full-stack conformance or automatic routing to new node numbers is claimed." }, { "id": "D04-LT", "feature": "D04", "stack": "LT", "status": "Y", "reason": "A concrete local-ownership construction uses an already provisioned user-owned BP node instance. ION documents separate SDR databases/working-memory keys and local directories for multiple instances; bprc adds local endpoint EIDs, and ionsecrc loads locally held named keys. Additional service EIDs under the same provisioned node number, with distinct local BPSec key/policy contexts, can plausibly be created without changing host interfaces or routes. Managing an owned protocol database is distinct from requiring host-network administrator privileges.", "method": "Documentary local-identity ownership plausibility; no runtime isolation test", "source_label": "Pinned ION multi-instance, local endpoint and local key configuration", "sources": [ "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/bpv7/doc/pod5/bprc.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod5/ionconfig.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod5/ionsecrc.pod", "https://github.com/nasa-jpl/ION-DTN/blob/154a4cc7354b26661169f8d8b75a4002cd509a9f/ici/doc/pod1/ionadmin.pod" ], "editorial_references": [ "round228-sources.json", "round308-sources.json" ], "qualification": "Keep the provisioned LTP engine/AOS channel and contact configuration unchanged; no new per-identity channel allocation is credited. Credit local endpoint/service identities and user-held security context only. The user must already own its instance/store and authorized node transport; this does not grant a user control over a shared administrator-owned ION database. Avoid shared default IPC keys and use owned files. Peer trust/key acceptance is separate. Shared symmetric BPSec keys do not prove exclusive asymmetric authorship. Exact BSL key-provider/profile integration and multi-user isolation have not been executed; no full-stack conformance or automatic routing to new node numbers is claimed." }, { "id": "D04-LP", "feature": "D04", "stack": "LP", "status": "Y", "reason": "libp2p Peer IDs derive from locally held keys. The go-libp2p Identity option takes a private key independently of ListenAddrs and transport options. Separate logical hosts can therefore use separate keys on already provisioned IP/UDP access without assigning each identity another interface address or route. This matches the selected separate-key/store profile.", "method": "Documentary API and selected-profile analysis; no new network execution", "source_label": "Official API/specification and implementation documentation retrieved 2026-10-15; retained source digests", "sources": [ "https://libp2p.io/docs/peers/", "https://raw.githubusercontent.com/libp2p/go-libp2p/master/options.go" ], "editorial_references": [ "round239-sources.json" ], "qualification": "One identity per host configuration is not one identity per machine: separate host instances are permitted. Use distinct ordinary socket bindings as necessary; no shared-address mutation is credited. Peer allowlists and connection gating still control acceptance. This is documentary capability evidence, not a newly executed multiuser or QUIC test." }, { "id": "D04-TO", "feature": "D04", "stack": "TO", "status": "Y", "reason": "Tor v3 onion service keys are independent of host interface addresses. The control specification supports caller-supplied Ed25519-v3 keys or generation of a new key, plus virtual-port mapping and v3 client authorization. A user controlling their own Tor instance and files can provision additional service identities over existing transport without administering shared host interfaces.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official specifications and versioned project documentation retrieved 2026-10-15; retained document hashes", "sources": [ "https://spec.torproject.org/control-spec/commands.html#add_onion" ], "editorial_references": [ "round240-sources.json" ], "qualification": "Control access is a prerequisite, not an entitlement for every local account. Credit a user-owned instance, not unrestricted access to another user's daemon. Preserve the selected persistent client-authorization files and revocation/restart policy; the API example does not replace them with an ephemeral-only configuration. Directory dependencies and incomplete Conflux implementation remain separate findings. No new Tor service was published." }, { "id": "D04-I2", "feature": "D04", "stack": "I2", "status": "Y", "reason": "The I2P SAM API supports destination-key generation and session creation with caller-supplied private destination material or a newly generated transient destination. The client can then connect or accept streams for that destination through the already available router. Additional destination identities do not require new shared interface addresses or routes.", "method": "Documentary API and selected-profile analysis; no new network execution", "source_label": "Official API/specification and implementation documentation retrieved 2026-10-15; retained source digests", "sources": [ "https://i2p.net/en/docs/api/samv3/" ], "editorial_references": [ "round239-sources.json" ], "qualification": "SAM is a local client API to the selected I2P destination mechanism, not an extra Internet transport in the column. Access to the router/API must already be authorized; Java I2P may require SAM to be enabled during setup. Destination private material is entrusted to the local bridge/router when used, so this is not exclusive custody against that component. Existing router/bootstrap policy, resource limits and peer reachability remain. No live I2P traffic was generated." }, { "id": "D04-YG", "feature": "D04", "stack": "YG", "status": "N", "reason": "The documented ordinary IPv6 application path uses a TUN interface. PrivateKey controls the node key, while IfName selects that interface; disabling it produces router-only mode. The official FAQ explicitly says that this mode cannot originate or receive application traffic through the Yggdrasil IPv6 address. Locally generating another key therefore does not by itself supply an additional usable user identity over the already configured IPv6 application endpoint; interface/address provisioning remains involved.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official API, protocol and configuration documentation; retained origin bytes or explicitly labelled web extractions, 2026-10-15", "sources": [ "https://yggdrasil-network.github.io/configurationref.html", "https://yggdrasil-network.github.io/faq.html" ], "editorial_references": [ "round241-sources.json" ], "qualification": "No is scoped to the selected ordinary IPv6/UDP application path, not key generation or external-authority independence. A separate userspace IPv6 frontend or identity-multiplexing API could change this boundary but is not credited without an explicit supported profile. Preconfiguring an address for each identity is precisely the per-identity provisioning D04 excludes. Existing delegated-interface operation in D01 remains a separate question." }, { "id": "D04-CJ", "feature": "D04", "stack": "CJ", "status": "N", "reason": "cjdns derives its node IPv6 address from the public key corresponding to privateKey. Its documented ordinary application interface is TUN, and Core_initTunnel initializes the device and assigns its IP address. In this selected native node-address/IPv6 application path, a new key changes the network address that the host interface must expose; an independently generated key is not an additional per-user application identity on an unchanged interface configuration.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official API, protocol and configuration documentation; retained origin bytes or explicitly labelled web extractions, 2026-10-15", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/master/doc/configure.md", "https://raw.githubusercontent.com/cjdelisle/cjdns/master/doc/admin-api.md" ], "editorial_references": [ "round241-sources.json" ], "qualification": "This classification does not deny self-generated cryptographic addresses, user-owned key files or running an already provisioned process without root. It concerns creating and using additional identities without per-identity network provisioning. A custom userspace packet frontend or delegated network administration is not silently substituted for the selected ordinary IPv6 path." }, { "id": "D04-MQ", "feature": "D04", "stack": "MQ", "status": "Y", "reason": "The selected QUIC profile already includes TLS 1.3 mutual certificate authentication with locally generated certificates explicitly trusted by counterparts. RFC 9001 section 4.4 supplies the TLS identity-authentication boundary, while RFC 8446 CertificateVerify proves possession of the corresponding private key. An application can supply another locally controlled key/certificate over an existing UDP/IP configuration; identity creation does not require another interface address or route.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official specifications and versioned project documentation retrieved 2026-10-15; retained document hashes", "sources": [ "https://www.rfc-editor.org/rfc/rfc9001.html#section-4.4", "https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.3" ], "editorial_references": [ "round240-sources.json" ], "qualification": "Credit the declared locally trusted certificate profile, not arbitrary public-Web PKI issuance or default client authentication. Peer trust approval remains necessary. QUIC connection IDs alone are not the identity being credited. Multipath and proactive repetition do not establish this property and are not newly tested here. Distinct ordinary socket bindings and private key stores may be needed." }, { "id": "D04-SC", "feature": "D04", "stack": "SC", "status": "N", "reason": "SCION endpoint addressing combines ISD-AS and an AS-local host address. In the selected SCION/application-UDP profile, those are network attachment and host addressing components, not an independently controlled user identity. AS trust material protects the routing/trust domain and does not turn each ordinary application user into a separately identified communication principal. The column explicitly excludes end-to-end TLS or another identity layer.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official API, protocol and configuration documentation; retained origin bytes or explicitly labelled web extractions, 2026-10-15", "sources": [ "https://docs.scion.org/en/latest/overview.html", "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "round241-sources.json" ], "qualification": "Creating UDP sockets or selecting paths is not creating a new user identity. Host-address delegation and additional AS credentials do not satisfy the defined boundary. A TLS or application-authentication composition could be assessed separately; none is added here. This No does not deny unprivileged use of an already provisioned SCION endpoint." }, { "id": "D04-RT", "feature": "D04", "stack": "RT", "status": "Y", "reason": "The Reticulum 1.5.5 API generates encryption/signing keys through RNS.Identity. Official examples construct a new identity and a SINGLE destination inside the application, then use that destination for communication. Identity and destination creation do not require another serial-interface configuration or host network address. Credit this over the selected already authorized serial transport.", "method": "Documentary API and selected-profile analysis; no new network execution", "source_label": "Official API/specification and implementation documentation retrieved 2026-10-15; retained source digests", "sources": [ "https://reticulum.network/manual/reference.html", "https://reticulum.network/manual/examples.html" ], "editorial_references": [ "round239-sources.json" ], "qualification": "Serial-device permission, IFAC credentials and initial transport setup remain prerequisites. This does not claim simultaneous exclusive ownership of one serial device by unrelated processes, unlimited announces, or exemption from resource limits. The selected no-local-TCP-sharing profile is unchanged; the evidence concerns identities within an authorized runtime, not a newly introduced sharing daemon." }, { "id": "D04-NS", "feature": "D04", "stack": "NS", "status": "Y", "reason": "NIP-01 identifies an event author by its public key and validates the corresponding signature. Clients construct and submit signed events over existing WebSocket connections; an additional author key needs no host interface or route change. This author identity is part of the selected NIP-01 stack, not an added JWT or authentication layer.", "method": "Documentary API and selected-profile analysis; no new network execution", "source_label": "Official API/specification and implementation documentation retrieved 2026-10-15; retained source digests", "sources": [ "https://raw.githubusercontent.com/nostr-protocol/nips/master/01.md" ], "editorial_references": [ "round239-sources.json" ], "qualification": "Credit user-controlled signed-event authorship. It does not authenticate the live publishing connection, identify the relay, or require a relay to accept every author. WSS/DNS access and relay policies remain as declared in the profile; no NIP-42 is added and no public event was submitted during this review." }, { "id": "D04-MT", "feature": "D04", "stack": "MT", "status": "Y", "reason": "The native Linux role already selected in D01 and C06 supplies a bounded Yes. An ordinary user with preauthorized access to a real CH341 LoRa radio can run a private meshtasticd context with its own configuration and VFS (-c and -d), explicit logical MAC, keys and peer records. NodeDB generates a new key pair inside that context, installs its private key into CryptoEngine, and derives the node number from the public key in createNewIdentity. Router assigns that local node number to originated packets. The logical MAC setting supplies firmware metadata; it does not change a Linux interface address. Creating another user-owned context therefore does not require a new host address, route, prefix or per-identity administrative allocation. Independently owned contexts, rather than serial clients sharing one firmware owner record, are the witness.", "method": "Source-level identity/privilege boundary and consistency with existing D01/C06 witnesses; no execution", "source_label": "Pinned native firmware identity and radio paths; official per-context VFS and device-permission documentation", "sources": [ "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NodeDB.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/Router.cpp", "https://github.com/meshtastic/firmware/blob/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/platform/portduino/PortduinoGlue.cpp", "https://meshtastic.org/docs/meshtasticd/usage/", "https://meshtastic.org/docs/meshtasticd/hardware/" ], "editorial_references": [ "round371-sources.json" ], "qualification": "Use the existing headless native configuration, no ambient capabilities, nonprivileged or disabled local servers, independently owned files and already provisioned device permissions. Keep the selected private-channel and STRICT policies; peers still decide whether to accept the new key. Contexts can be used sequentially on an exclusively assigned radio; concurrent contexts require separately available authorized radios, with unique CH341 device serials where applicable. This does not claim multiplexed identities inside one shared embedded node, simultaneous sharing of one USB device, seamless identity rotation or unlimited radio resources. The single-owner firmware observation remains true but no longer blocks the allowed separate-instance witness. Source/documentary finding, not a new multiuser permission trace or RF experiment." }, { "id": "D04-GN", "feature": "D04", "stack": "GN", "status": "Y", "reason": "The GNUnet v0.20.x handbook documents a per-user setup with user-owned configuration and services, and distinguishes peer public-key identity from underlying IP addresses and ports. CADET addresses the remote peer identity and a service port. A separate authorized per-user peer can therefore use its own key/store and ordinary UDP bindings without assigning a new host interface address.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official specifications and versioned project documentation retrieved 2026-10-15; retained document hashes", "sources": [ "https://docs.gnunet.org/v0.20.x/users/configuration.html", "https://docs.gnunet.org/v0.20.x/about.html", "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [ "round240-sources.json" ], "qualification": "Credit per-user peer instances over already permitted UDP access. In a shared system-wide peer, ordinary CADET clients do not automatically obtain independent peer identities. Isolate configuration, keys and IPC/socket paths for separate instances. GNS egos and Messenger identities are excluded and are not evidence for this verdict. Optional privileged DNS/raw helpers are not added to the selected UDP composition. No new live GNUnet experiment is claimed." }, { "id": "D04-ND", "feature": "D04", "stack": "ND", "status": "Y", "reason": "ndn-cxx 0.9.0 provides per-user keychain configuration and ndnsec key-gen for additional identities, with ECDSA supported. The versioned producer example signs Data through KeyChain and explicitly supports selecting an identity/key/certificate independently of the Data name and network face. A producer on an already authorized local face and content prefix can use another locally controlled signing identity without adding host interface addresses or routes.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official API, protocol and configuration documentation; retained origin bytes or explicitly labelled web extractions, 2026-10-15", "sources": [ "https://docs.named-data.net/ndn-cxx/0.9.0/manpages/ndnsec-key-gen.html", "https://docs.named-data.net/ndn-cxx/0.9.0/manpages/ndn-client.conf.html", "https://raw.githubusercontent.com/named-data/ndn-cxx/ndn-cxx-0.9.0/examples/producer.cpp" ], "editorial_references": [ "round241-sources.json" ], "qualification": "Credit producer Data-signing identity, not authenticated consumer identity or a live endpoint session. Keep the selected ECDSA profile and preauthorized content prefix; this does not grant arbitrary prefix registration, namespace ownership or consumer trust. Key/certificate distribution and trust-anchor acceptance remain separate. No extra IP face, GNS-like naming layer or newly executed NFD test is credited." }, { "id": "D04-AX", "feature": "D04", "stack": "AX", "status": "N", "reason": "Linux v6.12 NET/ROM nr_bind requires an existing local NET/ROM device address. Selecting a distinct arbitrary user callsign requires CAP_NET_BIND_SERVICE; otherwise the socket inherits the configured UID callsign or the node address. The UID association add/delete ioctls require CAP_NET_ADMIN. Thus an ordinary user cannot create and use additional independent user callsigns through this documented native NET/ROM path without per-identity administrative provisioning.", "method": "Source inspection; no new runtime or radio test", "source_label": "Pinned implementation source retained with SHA-256, 2026-10-15", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/netrom/af_netrom.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ax25/ax25_uid.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/ax25/af_ax25.c" ], "editorial_references": [ "round242-sources.json" ], "qualification": "Scoped to the documented native Linux AX.25/NET/ROM path, not a theorem about every possible userspace radio implementation. AX.25-only permissive binding is not sufficient for the selected NET/ROM composition. Existing callsign use and socket creation are separate from new identity provisioning. No radio execution, regulatory conclusion or cryptographic-identity requirement is introduced." }, { "id": "D04-BA", "feature": "D04", "stack": "BA", "status": "N", "reason": "Linux 6.12 documentation defines batman-adv as an Ethernet-frame service behaving as a distributed virtual switch. Its configuration creates a batadv interface and attaches network interfaces. In the selected native L2 stack, locally administered MAC addresses identify interface/client forwarding endpoints; no additional user-controlled communication identity is defined independently of those addresses.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official specifications and versioned project documentation retrieved 2026-10-15; retained document hashes", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/networking/batman-adv.rst" ], "editorial_references": [ "round240-sources.json" ], "qualification": "Locally choosing a MAC is not the same as using another per-user protocol identity without interface/address administration. Delegated virtual interfaces, raw frame injection or an added authentication protocol are different capabilities and do not establish D04 here. The column remains native Ethernet without IP or an application security layer." }, { "id": "D04-BL", "feature": "D04", "stack": "BL", "status": "N", "reason": "RFC 8966 router identifiers distinguish routing sources and accompany advertised prefixes; they are not ordinary-user communication identities. The selected IPv6/ICMPv6 data plane still delivers using interface addresses. Babel supplies route discovery/selection rather than an additional independently controlled user identity over existing addresses.", "method": "Documentary selected-stack classification; no new network execution", "source_label": "Official specifications and versioned project documentation retrieved 2026-10-15; retained document hashes", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html", "https://www.rfc-editor.org/rfc/rfc4291.html#section-2.1" ], "editorial_references": [ "round240-sources.json" ], "qualification": "Choosing another router-id does not satisfy D04. Namespaces or delegated interface administration can isolate network configuration, but do not add the missing user-identity mechanism to this stack. No TLS, application authentication or Babel security extension is silently added. This No does not negate D01 ordinary endpoint use." }, { "id": "D04-RI", "feature": "D04", "stack": "RI", "status": "Y", "reason": "Over already provisioned IPv6/UDP access, the DTLS client can supply an additional locally generated external PSK and identity through per-object callbacks. These credentials are distinct from the host interface address and can belong to separate ordinary user processes without modifying shared routes or interfaces.", "method": "Source/API provenance and bounded documentary witness; no execution", "source_label": "Pinned wolfSSL source and DTLS 1.3 specification", "sources": [ "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/wolfssl/ssl.h", "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/ssl.c", "https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/tls13.c", "https://www.rfc-editor.org/rfc/rfc9147.html" ], "editorial_references": [ "round271-sources.json" ], "qualification": "The counterpart must explicitly provision and accept the new distinct pairwise credential; this is the peer-acceptance condition allowed by D04, not automatic trust. Use secure random secrets and user-owned stores. This credits credential creation/use above authorized transport, not privilege-free installation of 802.15.4/RPL or independence from the peer that shares the secret. No additional application authentication is introduced." }, { "id": "D04-HP", "feature": "D04", "stack": "HP", "status": "?", "reason": "RFC 6317 lets an application enumerate local HITs and select one with bind or source-HIT policy. It does not establish that an ordinary user can create and install a new independently controlled HI into the host HIP/IPsec subsystem without per-identity administration. Pinned OpenHIP hitgen implements local ECDSA key generation, accepts -file for identity XML output, and sets the output permissions to owner read/write. Before parsing arguments it checks SYSCONFDIR and tries to create it if absent. This identifies a candidate key-generation path and its filesystem precondition; it does not prove autonomous registration in a running HIP/IPsec endpoint.", "method": "Pinned candidate source trace and developer report; no execution", "source_label": "HIP API RFC and pinned CICN implementation source", "sources": [ "https://www.ida.liu.se/~TDDE21/info/hip_report_2024.pdf", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/util/hitgen.c", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/linux/hip_linux_umh.c", "https://bitbucket.org/openhip/openhip/src/52157e5e68a82a80fd252c6c9b63a6a77da24e27/src/include/hip/hip_proto.h" ], "editorial_references": [ "round428.html", "round272-sources.json", "round428-sources.json" ], "qualification": "Check the selected-profile daemon identity import, registration ACLs, per-user key custody and SA ownership. A writable output file and local key generation are insufficient to establish that ordinary users can independently activate identities. No executable or multi-user test performed." }, { "id": "D04-CX", "feature": "D04", "stack": "CX", "status": "Y", "reason": "The CCNx signing-key identifier is separate from the content name and forwarding attachment. LibPARC provides caller-selected key-store files and ECDSA key/signing operations. Together these support plausible user-owned additional producer identities over an already authorized face and prefix, without changing shared interface addresses or routes. The missing integrated codec witness is an implementation qualification task rather than an architectural requirement for administrator-issued identities.", "method": "Documentary plausibility of identity creation; explicit integration limitation", "source_label": "LibPARC user-owned key operations and CCNx identity/name separation", "sources": [ "https://raw.githubusercontent.com/FDio/cicn/98cf0757875093dc4c1a87f00052a443353e5fce/libparc/parc/security/parc_Pkcs12KeyStore.c", "https://raw.githubusercontent.com/FDio/cicn/98cf0757875093dc4c1a87f00052a443353e5fce/libparc/parc/security/parc_PublicKeySigner.c", "https://www.rfc-editor.org/rfc/rfc8569.html#section-8.4" ], "editorial_references": [ "round273-sources.json", "round303-sources.json" ], "qualification": "Architectural plausibility, not a qualified executable. Previously inspected schema-v1 code leaves SetSigner commented out in DictionaryEncode and lacks ECDSA in automatic suite conversion. Those integration gaps remain; this verdict does not assert that the pinned application works unchanged. No runtime, interoperability or security audit was performed. Limited to producer signing identities and a preauthorized namespace/transport. Consumer trust in a new key remains separately configured; no right to another content prefix, authenticated consumer identity or complete unprivileged endpoint is implied." }, { "id": "D04-LI", "feature": "D04", "stack": "LI", "status": "N", "reason": "The selected end-system identity is its host-configured IPv4 EID. Adding independent EIDs requires address provisioning and corresponding mapping/routing administration; opening a new UDP port does not create a new independently controlled network identity. Linux interface configuration is protected by CAP_NET_ADMIN.", "method": "Pinned source and documentation review", "source_label": "LISP RFC 9300; Linux socket/capability documentation; pinned lispers.net source as applicable", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html#section-3", "https://man7.org/linux/man-pages/man7/capabilities.7.html" ], "editorial_references": [], "qualification": "This does not deny creating application identities above LISP; that would add an unselected layer." }, { "id": "D04-IL", "feature": "D04", "stack": "IL", "status": "Y", "reason": "With eNIDs enabled on an administratively provisioned ILNP host, a client application obtains a fresh NID for each new socket flow through the ordinary resolution/socket/connect interface. NIDs are allocated to sockets and retired after use, rather than requiring the user to edit shared interface addresses or routes for each communication identity. The 2026 DNS-enabled FreeBSD demonstration shows successive nc TCP connections with distinct NIDs.", "method": "Documentary capability inference from per-socket allocation and ordinary application API", "source_label": "Haywood and Bhatti (2025), sections 3.2 and 3.4; FreeBSD 14.3 demonstration (2026)", "sources": [ "https://rke.abertay.ac.uk/ws/portalfiles/portal/86497231/Haywood_EphemeralNodeIdentifiers_Published_2025.pdf", "https://ilnp.cs.st-andrews.ac.uk/freebsd/20260718-ietf126_hackathon/", "https://www.rfc-editor.org/rfc/rfc6740.html#section-3.1" ], "editorial_references": [], "qualification": "Bounded client capability after privileged installation and eNID-policy provisioning. The OS generates and manages the values; this does not mean user-selected arbitrary NIDs, portable cryptographic keys, durable server identities or immunity to privileged host administrators. DAD and kernel pool/cache updates remain necessary but are not per-identity administrative interface reconfiguration. No two-user isolation or non-root execution test was performed; the conclusion is documentary plausibility, not runtime certification." }, { "id": "D04-TS", "feature": "D04", "stack": "TS", "status": "N", "reason": "The selected standard TUN client operates through the host daemon and its active network configuration. Switching logical nodes changes that shared client state; it is not independent per-user identity creation and use without host-network administration.", "method": "Official documentation and pinned source/declaration review; no runtime test", "source_label": "Tailscale identity documentation, LocalAPI and PATENTS grant", "sources": [ "https://tailscale.com/docs/concepts/tailscale-identity", "https://tailscale.com/docs/concepts/tailscale-identity", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/PATENTS", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/LICENSE", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/ipn/localapi/localapi.go", "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round588.html", "round588-sources.json" ], "qualification": "Scope is the selected standard Linux client. tsnet provides separately identified application nodes but is expressly excluded from this column. Multiple ordinary applications using one node identity do not establish this criterion." }, { "id": "D04-RA", "feature": "D04", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Trace identity generation, custody and protocol use for a second ordinary user. Identify any per-identity privileged operation, shared address/interface mutation or administrator allocation. Credit only identity mechanisms in the selected stack; an extra application authentication layer is not implicit. Separate this architectural capability from D01 full endpoint runtime privileges, F03 topology-dependent addressing and S02 external identity issuance. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "K01-PN", "feature": "K01", "stack": "PN", "status": "Y", "reason": "The selected protected adjacency and E2E suite is now 0x0202, the wire-v4 recommended general suite: X25519 + ML-KEM-1024 with ChaCha20-Poly1305. Section 12 concatenates both shared secrets and binds them, the signed transcript, suite, scope, direction and generation into BLAKE3 derive-key. HS2 selects one exact suite; M2 repeats it and no in-exchange fallback is permitted. This meets the documented post-quantum key-establishment criterion. Identity authentication is independent; this verdict does not certify resistance to active quantum impersonation, independent audit or integrated runtime maturity.", "method": "Normative selected-profile analysis; source inspection, no new execution", "source_label": "prp-spec 9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b, specifications/prp-wire-v4.md sections 10–12; session-suites-v4 registry", "sources": [ "https://csrc.nist.gov/pubs/fips/203/final" ], "editorial_references": [ "round202.html" ], "qualification": "" }, { "id": "K01-PI", "feature": "K01", "stack": "PI", "status": "Y", "reason": "The selected protected adjacency and E2E suite is now 0x0202, the wire-v4 recommended general suite: X25519 + ML-KEM-1024 with ChaCha20-Poly1305. Section 12 concatenates both shared secrets and binds them, the signed transcript, suite, scope, direction and generation into BLAKE3 derive-key. HS2 selects one exact suite; M2 repeats it and no in-exchange fallback is permitted. This meets the documented post-quantum key-establishment criterion. Identity authentication is independent; this verdict does not certify resistance to active quantum impersonation, independent audit or integrated runtime maturity.", "method": "Normative selected-profile analysis; source inspection, no new execution", "source_label": "prp-spec 9b515ce11cfee4fd9d9ec82a5aef9b13ecc7085b, specifications/prp-wire-v4.md sections 10–12; session-suites-v4 registry", "sources": [ "https://csrc.nist.gov/pubs/fips/203/final" ], "editorial_references": [ "round202.html" ], "qualification": "" }, { "id": "K01-IP", "feature": "K01", "stack": "IP", "status": "N", "reason": "Base IPv4/IPv6 and the selected routing controls do not establish encrypted endpoint traffic keys; IPsec is excluded. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8200.html" ], "editorial_references": [ "cells/F06-IP.html" ], "qualification": "" }, { "id": "K01-BP", "feature": "K01", "stack": "BP", "status": "N", "reason": "Selected BPSec uses pre-provisioned final-pair symmetric keys. RFC 9173 section 6.1 delegates key management outside the security contexts; no end-to-end PQ KEM or hybrid establishment is selected. K01 requires that establishment mechanism. This No does not claim quantum vulnerability of properly provisioned AES keys or remove the F06 confidentiality positive. Hop-local TLS is not final-pair key establishment.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html#section-6.1" ], "editorial_references": [], "qualification": "" }, { "id": "K01-CG", "feature": "K01", "stack": "CG", "status": "N", "reason": "Selected BPSec uses pre-provisioned final-pair symmetric keys. RFC 9173 section 6.1 delegates key management outside the security contexts; no end-to-end PQ KEM or hybrid establishment is selected. K01 requires that establishment mechanism. This No does not claim quantum vulnerability of properly provisioned AES keys or remove the F06 confidentiality positive. Hop-local TLS is not final-pair key establishment.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html#section-6.1" ], "editorial_references": [], "qualification": "" }, { "id": "K01-LT", "feature": "K01", "stack": "LT", "status": "N", "reason": "Selected BPSec uses pre-provisioned final-pair symmetric keys. RFC 9173 section 6.1 delegates key management outside the security contexts; no end-to-end PQ KEM or hybrid establishment is selected. K01 requires that establishment mechanism. This No does not claim quantum vulnerability of properly provisioned AES keys or remove the F06 confidentiality positive. Hop-local TLS is not final-pair key establishment.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc9173.html#section-6.1" ], "editorial_references": [], "qualification": "" }, { "id": "K01-LP", "feature": "K01", "stack": "LP", "status": "Y", "reason": "The previously unspecified end-to-end group now has an explicit versioned witness. Go 1.26.5 selects X25519MLKEM768 with both modern endpoints under the default preference list. Its pinned key schedule concatenates the ML-KEM shared secret followed by the X25519 secret and passes that result into the TLS 1.3 handshake-secret derivation; the client performs the matching decapsulation and concatenation. The official libp2p TLS identity component retains certificate-chain and expected-Peer-ID verification and disables session tickets. A local QUIC execution using that component negotiated group 4588 at both ends, authenticated both peer keys and exchanged 256 useful bytes in each direction without resumption. This is sufficient for the documented passive recorded-traffic confidentiality construction in K01, within the assumptions of X25519/ML-KEM and TLS 1.3.", "method": "Versioned configuration selection, source mapping and positive/negative execution", "source_label": "Pinned public libp2p/Go source plus local five-case QUIC/TLS component execution, 2026-10-22", "sources": [ "https://github.com/libp2p/go-libp2p/blob/3c2c902122cb6fae3897f729a3dbb9d4665ae90d/p2p/security/tls/crypto.go", "https://github.com/golang/go/blob/c19862e5f8415b4f24b189d065ed739517c548ba/src/crypto/tls/key_schedule.go" ], "editorial_references": [ "round421.html", "round421-runtime.json", "round421-sources.json", "round421-harness.go" ], "qualification": "Configuration-specific Yes, not a claim about every libp2p build or peer. The control run with a classical-only server succeeded using X25519 (29), proving that defaults do permit classical fallback. A component configuration limiting CurvePreferences to group 4588 succeeded against the hybrid peer and failed against the classical peer; this custom TLS configuration is not presented as a stock libp2p host CLI option. A wrong expected Peer ID also failed. Execution covers loopback IPv4/UDP/QUIC and the official libp2p TLS identity component, not a complete libp2p host, Identify, ConnectionGater revocation, migration or independent interoperability. Native QUIC transport source uses the same Identity.ConfigForPeer path without overriding the TLS group list; applicability to that path is a source inference. The matrix explicitly selects the versioned hybrid negotiation case. Peer ID and certificate signatures remain classical: no post-quantum active-attacker authentication, independent cryptographic audit or deployment guarantee. No extension of the F25 byte witness to this execution is inferred." }, { "id": "K01-TO", "feature": "K01", "stack": "TO", "status": "N", "reason": "The selected onion-v3 introduction/rendezvous hs-ntor construction uses Curve25519. No post-quantum KEM is part of this selected endpoint handshake. A successor proposal or a different relay-link handshake does not change this endpoint construction.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://spec.torproject.org/rend-spec/introduction-protocol.html" ], "editorial_references": [], "qualification": "" }, { "id": "K01-I2", "feature": "K01", "stack": "I2", "status": "Y", "reason": "Pinned i2pd 2.58.0 implements type-6 end-to-end ratchet establishment. NewSessionReplyMessage first mixes the X25519 ephemeral agreement, encapsulates to the received ML-KEM key, authenticates the ciphertext in the transcript and calls MixKey on the KEM secret. It then mixes the additional X25519 agreement before deriving directional ratchet keys and the reply payload key. HandleNewOutgoingSessionReply performs matching decapsulation and key derivation. Crypto.cpp implements MixKey using HKDF with the current chaining key and the 32-byte secret. This supports a documentary Yes for the selected hybrid key establishment against passive recorded-traffic decryption, subject to the component cryptographic assumptions. It is an endpoint ratchet construction, not an inference from adjacent-router NTCP2 protection.", "method": "Documentary source mapping with explicit hybrid profile and first-flight boundary", "source_label": "Pinned official i2pd 2.58.0 source and I2P hybrid specification, reviewed 2026-10-22", "sources": [ "https://github.com/PurpleI2P/i2pd/blob/e8d59c83754a0809b753ea7f59021160f755abad/libi2pd/ECIESX25519AEADRatchetSession.cpp", "https://github.com/PurpleI2P/i2pd/blob/e8d59c83754a0809b753ea7f59021160f755abad/libi2pd/Crypto.cpp", "https://github.com/PurpleI2P/i2pd/blob/e8d59c83754a0809b753ea7f59021160f755abad/libi2pd/Crypto.h", "https://github.com/PurpleI2P/i2pd/blob/e8d59c83754a0809b753ea7f59021160f755abad/libi2pd/Destination.cpp", "https://github.com/PurpleI2P/i2pd/blob/e8d59c83754a0809b753ea7f59021160f755abad/libi2pd/LeaseSet.cpp", "https://www.i2p.net/en/docs/specs/ecies-hybrid/" ], "editorial_references": [ "round422.html", "round422-sources.json" ], "qualification": "The initial New Session flight carries an ML-KEM public key but has not incorporated a KEM shared secret: its payload is outside this post-quantum confidentiality claim. WrapSingleMessage can include a payload in that flight; no automatic application-data deferral was established. Reply and subsequent hybrid-derived traffic are the positive witness. Destination.cpp accepts an explicit encryption-type list and uses its first nonzero type as a preference; PQ-enabled defaults also include classical types. LeaseSet.cpp chooses a supported preferred type, or a higher supported available type when that preference is absent. Preference is therefore not a universal minimum-security requirement. Builds below OpenSSL 3.5 skip PQ types; those builds and sessions selecting type 4 are excluded. Both endpoints and the actual selected type must match the witness. No PQ authentication, full-traffic PQ anonymity, independent audit, local handshake execution or interoperability result is claimed. Other cells keep their own configurations." }, { "id": "K01-YG", "feature": "K01", "stack": "YG", "status": "N", "reason": "Pinned Ironwood d50055b converts Ed25519 identity material to Curve25519 box keys and uses NaCl box shared-secret operations. This classical endpoint construction contains no selected PQ KEM/hybrid. Outer TLS peer links are not the end-to-end protection boundary.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/encrypted/crypto.go" ], "editorial_references": [], "qualification": "" }, { "id": "K01-CJ", "feature": "K01", "stack": "CJ", "status": "N", "reason": "Selected end-to-end CryptoAuth uses Curve25519-derived secrets. Neighbor peering passwords do not supply a post-quantum KEM between arbitrary final nodes. No PQ/hybrid endpoint construction is selected.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/master/doc/Whitepaper.md" ], "editorial_references": [], "qualification": "" }, { "id": "K01-MQ", "feature": "K01", "stack": "MQ", "status": "Y", "reason": "The previously unselected TLS group now has a pinned hybrid configuration and an executed witness. A local static OpenSSL 3.5.0 build provides X25519MLKEM768 to the pinned Picotls and picoquic sources. With the client restricted through picoquic_set_key_exchange to group 4588, the server completed the hybrid exchange and produced a 64-byte combined secret. The native QUIC simulator then delivered 256 useful bytes in each direction through the existing test callbacks. Picotls passes the combined KEM secret into its TLS 1.3 key schedule. OpenSSL mlx_kem.c places the ML-KEM and ECDH secrets in separate portions of the combined buffer and checks their lengths. This supports the bounded passive recorded-traffic confidentiality claim for the selected hybrid construction, under its cryptographic assumptions.", "method": "Explicit hybrid configuration, isolated provider build, native simulator positive/negative controls", "source_label": "Pinned official picoquic/Picotls/OpenSSL sources and local three-case execution, 2026-10-22", "sources": [ "https://github.com/private-octopus/picoquic/blob/c124cbe975f71b150ea929d325804335d2bdaa34/picoquic/tls_api.c", "https://github.com/h2o/picotls/blob/f06553b877ada93c860dd1db9002eabf7365292d/lib/openssl.c", "https://github.com/openssl/openssl/blob/openssl-3.5.0/providers/implementations/kem/mlx_kem.c" ], "editorial_references": [ "round423.html", "round423-runtime.json", "round423-sources.json", "round423-harness.patch" ], "qualification": "Default preferences are not a fail-closed PQ policy: a default client successfully exchanged the same data with a classical-only server using X25519 (29). The client restricted to group 4588 was instead rejected by that server with TLS handshake_failure (QUIC error 0x128), without reaching ready. The test changes make unsupported algorithms fail rather than silently skip, add group/secret-length observation, and add data and negative controls; they do not change the cryptographic implementation. The first negative assertion incorrectly expected a nonzero simulator-loop return; it was corrected to inspect the actual TLS error and connection state, retaining the original log. This is native code execution over simulated packet delivery, not two independent implementations, a live multipath run or a public deployment. Test certificate/SNI settings are the upstream fixture, not a revalidation of the column's complete mutual-authentication/no-SNI configuration. No PQ certificate authentication, security audit, throughput result or extension of earlier byte-budget witnesses is claimed. OpenSSL 3.5.0 is an isolated reproducibility pin, not a deployment recommendation." }, { "id": "K01-SC", "feature": "K01", "stack": "SC", "status": "N", "reason": "Selected SCION with application UDP has no endpoint payload-encryption layer. Forwarding/path authentication is not end-to-end key establishment. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://docs.scion.org/en/latest/protocols/scion-header.html" ], "editorial_references": [ "cells/F06-SC.html" ], "qualification": "" }, { "id": "K01-RT", "feature": "K01", "stack": "RT", "status": "N", "reason": "Reticulum 1.5.5 Link establishes per-link secrets with Curve25519 ECDH. AES payload protection and forward secrecy do not make this classical key agreement post-quantum; no PQ KEM or hybrid is selected.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://reticulum.network/manual/understanding.html", "https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/" ], "editorial_references": [], "qualification": "" }, { "id": "K01-NS", "feature": "K01", "stack": "NS", "status": "N", "reason": "Selected NIP-01 signs public events but does not establish author-to-reader encryption keys. WSS terminates at relays; NIP-17/44 are excluded. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/01.md" ], "editorial_references": [ "cells/F06-NS.html" ], "qualification": "" }, { "id": "K01-MT", "feature": "K01", "stack": "MT", "status": "N", "reason": "The pinned 8e6a88d direct-message implementation derives the shared secret using Curve25519, then protects messages with AES-CCM. There is no PQ KEM in that selected exchange. Symmetric channel PSKs and signed broadcasts are different mechanisms.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/CryptoEngine.cpp", "https://meshtastic.org/docs/overview/encryption/" ], "editorial_references": [], "qualification": "" }, { "id": "K01-GN", "feature": "K01", "stack": "GN", "status": "N", "reason": "The selected v0.20.x CADET documentation explicitly specifies Curve25519 ECDHE for endpoint key exchange, with AES-256/Twofish payload encryption. Symmetric cipher strength and forward secrecy do not convert that classical exchange into a PQ KEM.", "method": "Specification/source/dependency analysis; no new runtime execution", "source_label": "Primary documentation and explicitly selected composition; documentary review 2026-10-15", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/cadet/cadet.html" ], "editorial_references": [], "qualification": "" }, { "id": "K01-ND", "feature": "K01", "stack": "ND", "status": "N", "reason": "Selected NDN v0.3 signed Data has no content-encryption extension or endpoint key-establishment construction. Producer signatures alone cannot meet K01. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://docs.named-data.net/NDN-packet-spec/0.3/data.html" ], "editorial_references": [ "cells/F06-ND.html" ], "qualification": "" }, { "id": "K01-AX", "feature": "K01", "stack": "AX", "status": "N", "reason": "Selected classic AX.25/NET-ROM frame and circuit service has no cryptographic wrapper or endpoint key establishment. Error checking and flow control do not provide it. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://wiki.oarc.uk/_media/packet:thenetromprotocol.pdf" ], "editorial_references": [ "cells/F06-AX.html" ], "qualification": "" }, { "id": "K01-BA", "feature": "K01", "stack": "BA", "status": "N", "reason": "Selected Linux 6.12 batman-adv supplies Ethernet bridging without any selected end-to-end security layer. Its routing service does not establish endpoint encryption keys. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://www.kernel.org/doc/html/v6.12/networking/batman-adv.html" ], "editorial_references": [ "cells/F06-BA.html" ], "qualification": "" }, { "id": "K01-BL", "feature": "K01", "stack": "BL", "status": "N", "reason": "Selected IPv6/Babel has neither IPsec nor another endpoint security layer. Babel routing messages do not establish protected payload keys between final endpoints. This is absence of the requested mechanism in the selected composition, not an impossibility claim about adding another layer.", "method": "Documentary resolution; no new runtime, cryptographic attack or hardware test", "source_label": "Primary documentation and explicit selected-profile analysis, reviewed 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8966.html" ], "editorial_references": [ "cells/F06-BL.html" ], "qualification": "" }, { "id": "K01-RI", "feature": "K01", "stack": "RI", "status": "N", "reason": "The selected DTLS 1.3 profile explicitly uses external-PSK psk_ke, not a KEM or a hybrid exchange. RFC 8446 section 4.2.9 defines this as PSK-only establishment without a server key_share; RFC 9147 section 5 reuses that handshake construction. K01 expressly requires a suitable post-quantum KEM or justified hybrid. Therefore the selected composition lacks the requested mechanism, on the same basis as the pre-provisioned symmetric-key BP/CG/LT columns.", "method": "Specification-based absence of the requested mechanism; cross-column consistency", "source_label": "TLS 1.3 PSK modes and DTLS 1.3 handshake; existing K01 criterion and selected profile", "sources": [ "https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.9", "https://www.rfc-editor.org/rfc/rfc9147.html#section-5" ], "editorial_references": [ "cells/K01-BP.html", "cells/K01-LT.html", "round311-sources.json" ], "qualification": "This No does not assert that symmetric PSK traffic is quantum-breakable. Symmetric security depends on key entropy, provisioning, algorithms and the attacker model. Nor does this verdict add ephemeral forward secrecy to psk_ke. It evaluates the existing KEM-specific definition, not a broader criterion of quantum-resistant confidentiality. The approved profile, cipher suite, F06 verdict and all other cells remain unchanged; no new negotiation or cryptanalytic experiment was performed." }, { "id": "K01-HP", "feature": "K01", "stack": "HP", "status": "N", "reason": "The selected base exchange uses classical ECDH P-256. It contains no post-quantum KEM or hybrid key-establishment component; its selected ESP protection does not change that establishment property.", "method": "Documentary capability and suite review; no runtime execution", "source_label": "Primary HIP/CCNx specifications and unchanged selected profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc7401.html" ], "editorial_references": [ "round254-sources.json", "round246.html" ], "qualification": "This verdict concerns the explicitly selected suite, not every possible future HIP extension. Identity-signature agility is not evidence of post-quantum confidentiality." }, { "id": "K01-CX", "feature": "K01", "stack": "CX", "status": "N", "reason": "The selected CCNx composition signs Content Objects but includes neither encryption nor an end-to-end key-establishment extension. It therefore supplies no post-quantum key establishment or confidential channel.", "method": "Documentary capability and suite review; no runtime execution", "source_label": "Primary HIP/CCNx specifications and unchanged selected profiles", "sources": [ "https://www.rfc-editor.org/rfc/rfc8569.html" ], "editorial_references": [ "round254-sources.json", "round246.html" ], "qualification": "CCNxKE and encapsulating encryption are discussed as additional mechanisms, not selected components. A public-key signature alone does not provide confidentiality; no extension is silently added." }, { "id": "K01-LI", "feature": "K01", "stack": "LI", "status": "N", "reason": "There is no end-to-end confidentiality key establishment in this selected unencrypted LISP/UDP composition, and therefore no post-quantum confidentiality construction to credit.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc9300.html; rfc9301.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html" ], "editorial_references": [], "qualification": "" }, { "id": "K01-IL", "feature": "K01", "stack": "IL", "status": "N", "reason": "The selected ILNPv6/TCP profile has no end-to-end confidentiality key-establishment protocol. Nonces are not a post-quantum KEM or hybrid confidentiality construction.", "method": "Specification review of the unchanged selected composition", "source_label": "rfc6740.html; rfc6741.html; rfc6744.html", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "" }, { "id": "K01-TS", "feature": "K01", "stack": "TS", "status": "N", "reason": "The selected WireGuard key establishment uses Curve25519, without a post-quantum KEM or additional preshared secret. Tailnet Lock signatures do not change payload key establishment.", "method": "Primary documentation review; no runtime experiment", "source_label": "Tailscale documentation and WireGuard protocol description", "sources": [ "https://www.wireguard.com/protocol/" ], "editorial_references": [ "round583.html", "round583-sources.json" ], "qualification": "Documentary capability of the declared profile; no runtime, security or global-scale certification. Tailnet Lock limits key-admission trust but does not replace managed coordination." }, { "id": "K01-RA", "feature": "K01", "stack": "RA", "status": "N", "reason": "The explicitly selected authentication/key-establishment mode accepts EDH and computes its shared secret using classical finite-field Diffie-Hellman. RSA authentication and AES256 content encryption do not supply a post-quantum key-establishment component. No post-quantum or hybrid KEM is selected.", "method": "Pinned documentation and authentication source inspection with explicit policy selection; no execution or audit", "source_label": "IRATI SSH2-inspired authentication policy", "sources": [ "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/librina/src/security-manager.cc", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/README.md", "https://github.com/IRATI/stack/blob/726b535c908f8a74e8c68dd493cfbb1bd8726546/rinad/src/ipcp/plugins/sm-auth-psoc/sm-auth-psoc-plugin.cc" ], "editorial_references": [ "round665.html" ], "qualification": "No for this declared composition, not a limitation on future RINA policies. The code uses DH_generate_key and DH_compute_key; the README description of EDH as elliptic-curve is inconsistent with this pinned implementation. This decision does not resolve whether application-to-application content is protected end to end." }, { "id": "L01-PN", "feature": "L01", "stack": "PN", "status": "Y", "reason": "The public PRP rights notice explicitly permits implementation and commercial reuse of the author-owned normative and proposed-normative material under CC BY 4.0, including the selected working drafts. Attribution and change notices remain due; a modified implementation is not thereby compatible or approved.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/prp-protocol/specifications/blob/main/LICENSE", "https://github.com/prp-protocol/specifications/blob/main/DOCUMENT-RIGHTS.md", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Copyright/use permission only. No patent clearance, trademark permission, interoperability or standards-body acceptance follows; L02 remains Pending." }, { "id": "L01-PI", "feature": "L01", "stack": "PI", "status": "Y", "reason": "The public PRP rights notice explicitly permits implementation and commercial reuse of the author-owned normative and proposed-normative material under CC BY 4.0, including the selected working drafts. The IPv4/UDP carrier specifications use IETF implementation permissions. Attribution and change notices remain due; a modified implementation is not thereby compatible or approved.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/prp-protocol/specifications/blob/main/LICENSE", "https://github.com/prp-protocol/specifications/blob/main/DOCUMENT-RIGHTS.md", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Copyright/use permission only. No patent clearance, trademark permission, interoperability or standards-body acceptance follows; L02 remains Pending." }, { "id": "L01-IP", "feature": "L01", "stack": "IP", "status": "Y", "reason": "IPv4/IPv6, ICMP, BGP and multicast RFCs are publicly specified within the IETF rights framework for implementation and use. Code-component reuse permits modification; the constraints on republishing altered RFC prose do not prohibit implementing or using the protocol commercially.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Retain applicable notices and each document publication-era terms. No conformance endorsement or patent license is inferred; this answers the owner-clarified use criterion, not unrestricted alteration of official RFC text." }, { "id": "L01-BP", "feature": "L01", "stack": "BP", "status": "Y", "reason": "IPv4/TCP/TLS 1.3, TCPCLv4, BPv7/BPSec and private-use ipn RFCs are publicly specified within the IETF rights framework for implementation and use. Code-component reuse permits modification; the constraints on republishing altered RFC prose do not prohibit implementing or using the protocol commercially.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Retain applicable notices and each document publication-era terms. No conformance endorsement or patent license is inferred; this answers the owner-clarified use criterion, not unrestricted alteration of official RFC text." }, { "id": "L01-CG", "feature": "L01", "stack": "CG", "status": "?", "reason": "The CCSDS publication catalog supplies an actual general reproduction policy: reasonable reuse of publication material is allowed with attribution, and written reprint permission is available on request. SABR 734.3-B-1 is a public Recommended Standard intended for implementation; its voluntary endorsement and inter-agency service arrangements are distinct from copyright permission. The reproduction policy improves the evidence but does not explicitly establish the unrestricted use/implementation scope required by L01. The CGR column also requires the already identified IETF implementation permissions for IPv4/TCP/TLS/TCPCLv4/BPv7/BPSec.", "method": "Documentary review; no external consultation or legal clearance", "source_label": "Official CCSDS reproduction policy and SABR authority/intent pages, 2026-10-15", "sources": [ "https://ccsds.org/publications/bluebooks/entry/3042/#popmake-2003", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3" ], "editorial_references": [], "qualification": "Clarify whether the CCSDS policy covers independent implementation for any purpose without individual permission, and check any document-specific third-party exceptions across the selected composition. Do not interpret optional written reprint confirmation as a mandatory implementation approval. Public availability, interoperability intent and a software license alone do not settle the remaining scope." }, { "id": "L01-LT", "feature": "L01", "stack": "LT", "status": "?", "reason": "The CCSDS publication catalog supplies an actual general reproduction policy: reasonable reuse of publication material is allowed with attribution, and written reprint permission is available on request. SABR 734.3-B-1 is a public Recommended Standard intended for implementation; its voluntary endorsement and inter-agency service arrangements are distinct from copyright permission. The reproduction policy improves the evidence but does not explicitly establish the unrestricted use/implementation scope required by L01. The LTP column additionally requires coverage of CCSDS 734.1-B-1 Annex B, Encapsulation 133.1-B-3 and AOS 732.0-B-4, alongside the IETF BPv7/BPSec/LTP documents.", "method": "Documentary review; no external consultation or legal clearance", "source_label": "Official CCSDS reproduction policy and SABR authority/intent pages, 2026-10-15", "sources": [ "https://ccsds.org/publications/bluebooks/entry/3042/#popmake-2003", "https://ccsds.org/Pubs/734x3b1.pdf", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3" ], "editorial_references": [], "qualification": "Clarify whether the CCSDS policy covers independent implementation for any purpose without individual permission, and check any document-specific third-party exceptions across the selected composition. Do not interpret optional written reprint confirmation as a mandatory implementation approval. Public availability, interoperability intent and a software license alone do not settle the remaining scope." }, { "id": "L01-LP", "feature": "L01", "stack": "LP", "status": "Y", "reason": "A licensed source-defined protocol path closes the earlier specification-rights gap without assigning the portal license to the separate specs repository. The selected go-libp2p v0.50.0 witness supplies MIT-licensed TLS identity-extension schemas, signing and verification rules, Peer ID construction, public-key protobuf schema, QUIC integration and ConnectionGater interfaces. Its pinned multiformats dependencies supply MIT-licensed multistream-select framing and negotiation, multihash encoding and multiaddr encoding definitions. The protobuf wire-format implementation is BSD-3-Clause licensed. IETF implementation permissions cover IP, UDP, QUIC and TLS; the selected quic-go dependency is also MIT licensed. These embedded definitions provide a route to use and implement the selected interfaces for any purpose, including commercial use, under the stated notices. This is the same source-defined-definition approach accepted for other stacks, rather than treating software availability alone as permission to copy unrelated specifications.", "method": "Pinned embedded definitions and grant coverage; documentary inference", "source_label": "go-libp2p, selected multiformats and protobuf definitions; applicable grants", "sources": [ "https://github.com/libp2p/go-libp2p/blob/v0.50.0/LICENSE", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/p2p/security/tls/crypto.go", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/core/crypto/pb/crypto.proto", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/core/peer/peer.go", "https://github.com/libp2p/go-libp2p/blob/v0.50.0/go.mod", "https://github.com/multiformats/go-multistream/blob/v0.6.1/multistream.go", "https://github.com/protocolbuffers/protobuf-go/blob/v1.36.11/LICENSE", "https://trustee.ietf.org/documents/trust-legal-provisions/" ], "editorial_references": [ "round606.html", "round606-sources.json" ], "qualification": "Retain MIT/BSD notices and disclaimers in covered copies and respect the BSD non-endorsement clause. The separate modern specification repository and website prose are not relicensed by this finding. The witness retains native QUIC, known numeric peers and Peer IDs; it does not substitute pubsub, WebTransport or a hosted service. The v0.50.0 witness was already selected for K01; historical per-cell configurations are not silently requalified. No patent clearance, interoperability certification, universal downgrade resistance or new runtime result follows from L01." }, { "id": "L01-TO", "feature": "L01", "stack": "TO", "status": "?", "reason": "The authoritative Tor GitLab README and spec/back-matter.md confirm the canonical specification source and publication process. The back-matter establishes editorial status and build instructions, not an unrestricted-use grant. The missing GitHub mirror LICENSE is no longer the research endpoint; the rights question remains at the canonical source.", "method": "Documentary review; no new build or runtime experiment", "source_label": "Primary source and versioned dependency review, 2026-10-15", "sources": [ "https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/README.md", "https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/spec/back-matter.md" ], "editorial_references": [], "qualification": "Locate a canonical rights statement covering the selected Tor specification documents, including relevant proposal text. Public readability, build instructions and implementation intent alone are not a complete rights finding." }, { "id": "L01-I2", "feature": "L01", "stack": "I2", "status": "Y", "reason": "The I2P specification website grants CC BY-SA 4.0 unless otherwise marked. NTCP2 and common structures are public specifications; attribution/share-alike govern reuse of their text, without a noncommercial or field-of-use prohibition. The selected IP/TCP layers use IETF implementation permissions.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://i2p.net/en/docs/development/licenses/", "https://i2p.net/en/docs/specs/ntcp2/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Do not transfer software-component licenses to specification prose. Copyright/use finding only; referenced cryptographic algorithms do not become patent-cleared." }, { "id": "L01-YG", "feature": "L01", "stack": "YG", "status": "Y", "reason": "A licensed source-defined path covers the selected Yggdrasil/Ironwood protocol interfaces. Pinned Yggdrasil version.go specifies the metadata fields, framing, serialization and signature checks; link.go and link_tls.go specify peer establishment and TLS transport integration. Pinned Ironwood network/wire.go specifies message discriminants, integer and path encodings; network/router.go and network/pathfinder.go specify forwarding and discovery exchanges; encrypted/session.go specifies session initiation, acknowledgments and encrypted traffic framing. Yggdrasil grants LGPLv3 rights with an additional linking permission, while Ironwood grants MPL-2.0 rights. These grants cover the embedded definitions and permit use and adaptation without a field-of-use restriction, including commercial use. IETF implementation permissions cover the selected IP, TCP, TLS and UDP layers. This supplies an alternative to reusing separately published website prose, using the same source-defined protocol approach accepted elsewhere in the matrix.", "method": "Pinned embedded definitions and license-scope review; documentary inference", "source_label": "Yggdrasil and Ironwood pinned source grants and protocol definitions", "sources": [ "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/LICENSE", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/LICENSE", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/version.go", "https://github.com/yggdrasil-network/yggdrasil-go/blob/422836eeb21a99790caa286aa63d493bbc4766d7/src/core/link.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/wire.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go", "https://github.com/Arceliar/ironwood/blob/d50055b11f5ec5b56ee4e56ba9a75261461821dc/encrypted/session.go", "https://trustee.ietf.org/documents/trust-legal-provisions/" ], "editorial_references": [ "round605.html", "round605-sources.json" ], "qualification": "Retain applicable notices and comply with LGPL/MPL source and redistribution obligations for covered material; the Yggdrasil linking exception does not waive all LGPL obligations. The website prose and icon licenses are not extended to other documents. This is a rights path for the selected interfaces, not an interoperability or completeness certification for every product feature. No patent clearance, proprietary service entitlement, performance result or new runtime test is inferred. Numeric peers, selected TLS 1.3 and pinned Ironwood remain the comparison scope; support for other TLS versions in source does not expand that profile." }, { "id": "L01-CJ", "feature": "L01", "stack": "CJ", "status": "Y", "reason": "The pinned cjdns doc/contributing.md explicitly licenses the contained documents under CC BY 4.0 unless otherwise noted and describes their import into cjdns/doc. Thus the documentation grant is distinct from the root GPLv3 code license. For the selected route-server component, the pinned README identifies cargo doc as its documentation path; cjdns-ann/src/lib.rs describes announcement headers, entities and signing, and the ann/core/hdr/snode manifests declare GPL-3.0-or-later. These grants permit use and implementation without commercial or field-of-use restrictions. Required IP/UDP/TCP/HTTP/WebSocket specification layers use IETF implementation permissions.", "method": "Documentary rights and component-scope review; no execution or legal clearance", "source_label": "Version-pinned cjdns documentation notice and route-server documentation/manifests, 2026-10-15", "sources": [ "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/doc/contributing.md", "https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/doc/Whitepaper.md", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/README.md", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-ann/src/lib.rs", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-ann/Cargo.toml", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-core/Cargo.toml", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-hdr/Cargo.toml", "https://github.com/CJDNS-Development-Team/CJDNS/blob/46c9c1b6828f746f00733c10d8e82c5295107514/cjdns-snode/Cargo.toml", "https://creativecommons.org/licenses/by/4.0/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3" ], "editorial_references": [], "qualification": "Apply attribution, license links and change notices to CC material; meet GPL source/copyleft obligations for covered derivatives. The guide uses the historical label Unported but links to the official CC BY 4.0 license. Do not extend the grant to externally linked papers or infer proprietary relicensing. This rights finding does not close E03-CJ client/server composition qualification, establish interoperability, or resolve L02 patent commitments." }, { "id": "L01-MQ", "feature": "L01", "stack": "MQ", "status": "Y", "reason": "IPv4/IPv6/UDP, QUIC/TLS 1.3 and multipath-21 are publicly specified within the IETF rights framework for implementation and use. Code-component reuse permits modification; the constraints on republishing altered RFC prose do not prohibit implementing or using the protocol commercially.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [], "qualification": "Retain applicable notices and each document publication-era terms. No conformance endorsement or patent license is inferred; this answers the owner-clarified use criterion, not unrestricted alteration of official RFC text." }, { "id": "L01-SC", "feature": "L01", "stack": "SC", "status": "Y", "reason": "The v0.12.0 repository distributes its SCION header, control-plane and cryptographic documentation together with the root Apache-2.0 LICENSE. The pinned recursive tree contains no separate license or overriding legal notice in doc/. Apache section 1 explicitly includes documentation source and generated documentation; sections 2 and 4 allow reuse and derivative distribution without a commercial or field-of-use restriction. Applying the repository license to these included specification sources is the documentary basis for Yes, rather than transferring a license from an unrelated implementation. IPv4/UDP specifications in the selected underlay are covered by IETF implementation permissions.", "method": "Documentary license-scope review; no legal clearance or runtime experiment", "source_label": "Pinned SCION repository, recursive tree and IETF rights documentation, 2026-10-15", "sources": [ "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/LICENSE", "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/doc/protocols/scion-header.rst", "https://github.com/scionproto/scion/blob/e6b0576682c73845a185f14ea68e8b0923374874/doc/cryptography/certificates.rst", "https://docs.scion.org/en/v0.12.0/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Retain required license and attribution notices and identify distributed modifications. This applies to the pinned repository documentation, not every SCION book, paper, logo or external specification. Copyright/use permission does not establish conformance, endorsement or freedom from patent claims; L02 is separate." }, { "id": "L01-RT", "feature": "L01", "stack": "RT", "status": "Y", "reason": "Reticulum 1.5.5 explicitly distinguishes protocol rights from the reference implementation license. The versioned manual identifies the reference implementation and manual as authoritative, and states that the protocol was dedicated to the public domain in 2016. Its Public Domain Protocol section expressly permits independent implementation, improvement and adaptation, including uses excluded by the reference-code license when implemented from scratch. This meets the use/implementation criterion for the selected native serial/Link profile without treating the Python distribution as unrestricted.", "method": "Documentary rights-scope review; no runtime or legal clearance", "source_label": "Version-pinned primary repositories and official manuals, 2026-10-15", "sources": [ "https://github.com/markqvist/Reticulum/blob/7f2b3b9b524c9386316379af1313b43a5e4f7a5d/docs/source/whatis.rst", "https://github.com/markqvist/Reticulum/blob/7f2b3b9b524c9386316379af1313b43a5e4f7a5d/docs/source/zen.rst", "https://github.com/markqvist/Reticulum/blob/7f2b3b9b524c9386316379af1313b43a5e4f7a5d/LICENSE" ], "editorial_references": [], "qualification": "This credits the author-declared permission to implement the protocol, not unrestricted copying of protected code or manual prose. The reference license covers associated documentation and includes use restrictions and notice requirements; those are not erased by the protocol dedication. Compatibility is a separate claim. E03 remains Pending for an OSI-licensed complete implementation; L02 patent commitments remain separately unestablished." }, { "id": "L01-NS", "feature": "L01", "stack": "NS", "status": "Y", "reason": "The NIPs repository explicitly dedicates all NIPs to the public domain. NIP-01 uses the separately published BIP-340 signature specification, whose BSD-2-Clause terms permit implementation use. The WSS/TLS/TCP/IP and DNS layers use the applicable IETF framework.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://github.com/nostr-protocol/nips/blob/master/README.md", "https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Public-domain dedication and BSD notice obligations are distinct. No permission to claim compatibility or patent clearance is inferred. Additional NIPs are not silently included." }, { "id": "L01-MT", "feature": "L01", "stack": "MT", "status": "Y", "reason": "The Meshtastic documentation repository at d68f524cb1ef08fbd3cc256db50af357fca19b45 includes a root GPLv3 LICENSE and the technical descriptions of encryption, signatures, packet overhead and protocol behavior. The selected firmware commit 8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c binds its protobufs submodule to 8f97d66a63ce10cfb12f94203e361691647f5ad3, which also contains a GPLv3 LICENSE covering the message-schema repository. The grants have no commercial or field-of-use restriction. This establishes permissions over actual documentation and schema sources, rather than inferring them solely from firmware licensing.", "method": "Documentary license and submodule review; no runtime or legal clearance", "source_label": "Pinned primary repositories and official protocol documentation, 2026-10-15", "sources": [ "https://github.com/meshtastic/meshtastic/blob/d68f524cb1ef08fbd3cc256db50af357fca19b45/LICENSE", "https://github.com/meshtastic/meshtastic/blob/d68f524cb1ef08fbd3cc256db50af357fca19b45/docs/development/reference/encryption-technical.mdx", "https://github.com/meshtastic/protobufs/blob/8f97d66a63ce10cfb12f94203e361691647f5ad3/LICENSE", "https://github.com/meshtastic/firmware/tree/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/protobufs" ], "editorial_references": [], "qualification": "Retain notices and satisfy GPLv3 copyleft/source obligations when distributing covered copies or derivatives. This does not promise proprietary relicensing, trademark use, radio authorization or patent clearance. The finding concerns the Meshtastic protocol above its provisioned radio carrier, not permission to manufacture a LoRa physical-layer implementation. Documentation rights do not certify that every current behavior is present in the pinned Alpha firmware; technical verdicts retain their existing version-specific evidence." }, { "id": "L01-GN", "feature": "L01", "stack": "GN", "status": "Y", "reason": "The selected v0.20.x handbook contribution policy expressly covers documentation, translations and other content: contributors grant publication under GPL and/or GFDL, and GNUnet e.V. states that accepted contributions are published under AGPLv3 or later, with possible additional licenses. The handbook includes the GFDL text. Read together, these project publication terms support use and implementation without a commercial or field-of-use restriction for the documented TRANSPORT/CORE/CADET/R5N composition. This finding uses the documentation policy itself, not an automatic transfer from the executable code license. IPv4/UDP underlay specifications have IETF implementation permissions.", "method": "Documentary scope review; no legal clearance or runtime experiment", "source_label": "Versioned official documentation and Linux v6.12 files, 2026-10-15", "sources": [ "https://docs.gnunet.org/v0.20.x/developers/contributing.html", "https://docs.gnunet.org/v0.20.x/_sources/developers/contributing.rst.txt", "https://docs.gnunet.org/v0.20.x/developers/tutorial.html#gnu-free-documentation-license", "https://www.gnu.org/licenses/agpl-3.0.html", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3" ], "editorial_references": [], "qualification": "This is a documentary interpretation of the stated project publication policy, not an audit of every contributor assignment. Retain notices and satisfy the applicable GPL/AGPL/GFDL redistribution and source obligations when reusing protected material; no proprietary-relicensing permission is inferred. External papers and optional services are not included. L02 patent coverage and E03 implementation availability remain separate." }, { "id": "L01-ND", "feature": "L01", "stack": "ND", "status": "Y", "reason": "The selected NDN/NFD composition has a licensed source-defined protocol path. ndn-cxx 0.9.0 embeds Interest/Data interfaces, TLV type and signature identifiers, NDNLP field definitions, NFD management parameter serialization and signature-verification interfaces under LGPL-3.0-or-later. NFD 24.07 supplies GPL-3.0-or-later link-service processing, direct Ethernet framing and forwarding definitions. These identified grants cover the embedded definitions and permit use and adaptation, including commercial use, subject to their distribution conditions. The path therefore does not require assigning a website footer or a future-facing policy to the separately maintained packet-specification repository. This uses the same source-embedded-definition approach accepted for other stacks. Known names, configured local trust anchors and direct Ethernet remain the selected composition.", "method": "Pinned embedded protocol definitions and file-level license coverage; documentary inference", "source_label": "ndn-cxx 0.9.0 and NFD 24.07 source definitions and notices", "sources": [ "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/COPYING.lesser", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/COPYING.md", "https://github.com/named-data/NFD/blob/NFD-24.07/COPYING.md", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/ndn-cxx/encoding/tlv.hpp", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/ndn-cxx/lp/fields.hpp", "https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.9.0/ndn-cxx/mgmt/nfd/control-parameters.cpp", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/face/generic-link-service.cpp", "https://github.com/named-data/NFD/blob/NFD-24.07/daemon/face/ethernet-transport.cpp" ], "editorial_references": [ "round607.html", "round607-sources.json" ], "qualification": "Preserve GPL/LGPL notices, modification notices and applicable corresponding-source, copyleft and combined-work obligations. NFD is GPL-3.0-or-later; ndn-cxx is LGPL-3.0-or-later, with GPL text incorporated by that license. This does not relicense separate specification prose, IEEE publications or hardware designs. The verdict concerns the selected protocol interfaces and does not add NLSR, public testbed enrollment, IP faces or application synchronization. No new interoperability, runtime, patent-clearance or legal certification follows. The separate specification repositories retain the earlier documented grant-mapping uncertainty, but are no longer required for this alternative licensed definition path." }, { "id": "L01-AX", "feature": "L01", "stack": "AX", "status": "?", "reason": "The historical NET/ROM 1.3 manual now supplies a concrete rights notice: Software 2000 attributes the document and software separately, and conditions use/copying of its software on a license or nondisclosure agreement. That software restriction does not establish a prohibition on independent implementation of the described protocol. The AX.25 2.2 revision dated 11 November 1997, retrieved from TAPR, attributes copyright to TAPR and ARRL but supplies no general implementation grant in the inspected rights notice. This is an additional historical candidate, not a silent replacement of the selected AX.25 v2 profile. Neither document closes L01; the cell remains Pending rather than being marked No from the proprietary NET/ROM product notice.", "method": "Documentary rights-scope review; no holder consultation or legal clearance", "source_label": "Historical Software 2000 manual and TAPR-hosted AX.25 document, reviewed 2026-10-22", "sources": [ "https://hamgate.ampr.org/docs/1987_netrom_version_1_3.pdf", "https://files.tapr.org/tech_docs/AX25/AX25.2.2.1997.pdf" ], "editorial_references": [ "round424.html", "round424-sources.json" ], "qualification": "Locate an attributable implementation/use permission for the exact AX.25 v2 and classic NET/ROM specification path, or a complete alternative licensed description of that same profile. The AX.25 2.2 notice cannot automatically license earlier editions. The NET/ROM scan is publisher material retained by an archival host; no publisher signature was verified. Linux implementation licensing, RF licensing, copyright permission and patent commitments remain separate questions. Failed HTTP requests and searches are not evidence that permission does not exist." }, { "id": "L01-BA", "feature": "L01", "stack": "BA", "status": "Y", "reason": "The selected BATMAN_IV/native Ethernet profile has a licensed source-defined protocol path in Linux v6.12. batadv_packet.h documents packet types, fields and translation-table containers; bat_iv_ogm.c defines originator processing and route selection; translation-table.c defines client announcements and table exchanges; routing.c and send.c define forwarding and bonding; soft-interface.c defines local Ethernet attachment. These definitions and their explanatory comments are covered by GPL-2.0, with Linux-syscall-note on the UAPI headers. if_ether.h supplies the licensed Ethernet frame interface definitions. This closes the earlier gap without requiring reuse of complementary wiki prose. GPL permits use and adaptation, including commercial use, subject to its redistribution terms. The finding uses the same source-embedded-definition route accepted for other stacks, rather than inferring specification rights merely from the existence of an open implementation.", "method": "Pinned source-defined protocol coverage and licensing notices; documentary inference", "source_label": "Linux v6.12 protocol definitions and GPL notices", "sources": [ "https://github.com/torvalds/linux/blob/v6.12/include/uapi/linux/batadv_packet.h", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/bat_iv_ogm.c", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/translation-table.c", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/routing.c", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/send.c", "https://github.com/torvalds/linux/blob/v6.12/net/batman-adv/soft-interface.c", "https://github.com/torvalds/linux/blob/v6.12/include/uapi/linux/if_ether.h", "https://github.com/torvalds/linux/blob/v6.12/LICENSES/preferred/GPL-2.0", "https://github.com/torvalds/linux/blob/v6.12/LICENSES/exceptions/Linux-syscall-note" ], "editorial_references": [ "round604.html", "round604-sources.json" ], "qualification": "GPL notices, modification notices, applicable copyleft and corresponding-source obligations remain required when distributing covered or derivative material. The syscall exception is limited to its stated scope; it does not license unrelated wiki text. This is a protocol-interface definition path, not a grant over IEEE publications, hardware designs or every optional batman-adv feature. The selected BATMAN_IV profile, bonding and native Ethernet boundary remain unchanged. No proprietary redistribution entitlement, patent clearance (L02), interoperability certification or runtime result is inferred. L02-BA remains Pending." }, { "id": "L01-BL", "feature": "L01", "stack": "BL", "status": "Y", "reason": "IPv6/ICMP and Babel RFC 8966 are publicly specified within the IETF rights framework for implementation and use. Code-component reuse permits modification; the constraints on republishing altered RFC prose do not prohibit implementing or using the protocol commercially.", "method": "Documentary classification; no new runtime, interoperability or security experiment", "source_label": "Primary documents, published reports and versioned source review, 2026-10-15", "sources": [ "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf" ], "editorial_references": [], "qualification": "Retain applicable notices and each document publication-era terms. No conformance endorsement or patent license is inferred; this answers the owner-clarified use criterion, not unrestricted alteration of official RFC text." }, { "id": "L01-RI", "feature": "L01", "stack": "RI", "status": "?", "reason": "The selected IPv6, 6LoWPAN, RPL, UDP and DTLS RFC portions have identifiable IETF publication/use terms. The profile also explicitly binds IEEE 802.15.4, whose specification-use permissions have not been traced in this review.", "method": "Documentary rights-scope interpretation; no patent clearance", "source_label": "IETF Trust TLP, publication-era guidance and RFC stream notices", "sources": [ "https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/documents/trust-legal-provisions/copyright-policy-and-tlp-faq/" ], "editorial_references": [ "round267-sources.json" ], "qualification": "Obtain the authoritative rights terms covering the required IEEE link specification before closing the complete-stack cell. Public availability of RFCs or use of a purchased radio does not by itself settle all specification permissions. Patent licensing remains a separate L02 question." }, { "id": "L01-HP", "feature": "L01", "stack": "HP", "status": "Y", "reason": "The selected IPv4/IPv6/UDP, HIPv2, ESP and HIP mobility RFCs fall within the IETF publication and implementation-rights framework. Their public specifications permit implementation and use without a commercial or field-of-use restriction. Applicable code-component grants permit reuse and modification.", "method": "Documentary rights-scope interpretation; no patent clearance", "source_label": "IETF Trust TLP, publication-era guidance and RFC stream notices", "sources": [ "https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/documents/trust-legal-provisions/copyright-policy-and-tlp-faq/", "https://www.rfc-editor.org/rfc/rfc4291.html", "https://www.rfc-editor.org/rfc/rfc4760.html" ], "editorial_references": [ "round267-sources.json" ], "qualification": "Preserve required notices and publication-era terms; restrictions on altered official prose are distinct from implementation. This documentary finding does not license patents, establish conformance, or determine implementation-code availability." }, { "id": "L01-CX", "feature": "L01", "stack": "CX", "status": "Y", "reason": "CCNx RFCs 8569 and 8609 use the IRTF alternate-stream copyright notice. TLP sections 8.c and 8.g apply the section 3.a grant without restricting it to the IETF standards process. Together with the IPv4/UDP rights framework, this supports implementation and use of the selected composition without individual permission or a field-of-use restriction.", "method": "Documentary rights-scope interpretation; no patent clearance", "source_label": "IETF Trust TLP, publication-era guidance and RFC stream notices", "sources": [ "https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3", "https://trustee.ietf.org/documents/trust-legal-provisions/copyright-policy-and-tlp-faq/" ], "editorial_references": [ "round267-sources.json" ], "qualification": "Do not label the IRTF grant as the section 4 BSD code-component license: section 8.g expressly excludes that section. Retain applicable notices and attribution. Copyright permission does not establish patent clearance or project endorsement." }, { "id": "L01-LI", "feature": "L01", "stack": "LI", "status": "Y", "reason": "The selected IPv4/UDP and LISP RFC 9300/9301 specifications are publicly available under the IETF publication/implementation-rights framework, without a commercial or field-of-use restriction on protocol implementation. Constraints on altered official RFC prose are distinct from the owner-defined implementation/use criterion.", "method": "Documentary scope review", "source_label": "Primary RFCs and IETF Trust provisions", "sources": [ "https://www.rfc-editor.org/rfc/rfc9300.html", "https://www.rfc-editor.org/rfc/rfc9301.html", "https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/", "https://www.rfc-editor.org/rfc/rfc8721.html#section-4.3" ], "editorial_references": [], "qualification": "Retain applicable notices and publication-era terms for each layer and reused code component. This does not grant patent rights, endorse compatibility or establish implementation-code completeness." }, { "id": "L01-IL", "feature": "L01", "stack": "IL", "status": "?", "reason": "The actual publication-era Trust Legal Provisions, effective 28 December 2009, were recovered. Sections 8.c and 8.g explicitly cover the IRTF stream, while excluding the section-4 code-component grant; section 6.c.i describes the no-derivatives notice used by ILNP. This resolves the historical-policy lookup, but does not itself establish the requested unrestricted implementation permission.", "method": "Publication-era primary policy review", "source_label": "IETF Trust Legal Provisions, version 4, sections 6.c and 8", "sources": [ "https://trustee.ietf.org/wp-content/uploads/IETF-TLP-4.pdf", "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc5743.html" ], "editorial_references": [ "round390-sources.json" ], "qualification": "The remaining issue is implementation/use permission distinct from copying or modifying specification prose and extracted code. Do not interpret the document restriction as a protocol-use prohibition, or the general IETF code grant as applicable to these IRTF documents. Patent commitments remain separate under L02; no holder contact was made." }, { "id": "L01-TS", "feature": "L01", "stack": "TS", "status": "Y", "reason": "A licensed protocol-definition path is available in the pinned sources, rather than relying on permission to reuse website prose. BSD-3-Clause notices cover tailcfg registration/map schemas, controlclient registration and map exchanges, controlhttp/controlbase transport and handshake definitions, discovery framing, DERP frames and flow, and Tailnet Lock authority updates, signatures, synchronization and RPC schemas in tka and tailcfg/tka.go. These embedded definitions can be used and adapted commercially with the stated notices. The selected WireGuard dependency is pinned by go.mod and provides its message/handshake definitions under MIT; Noise section 16 dedicates its specification to the public domain. IP, UDP, TCP, HTTP, TLS, JSON and CBOR use IETF implementation permissions. Enrollment exposes an AuthURL/follow-up boundary: the external identity provider remains external, rather than requiring reproduction of its private business logic. OpenID Connect separately grants implementation use in Appendix C; it is not asserted to be the only provider supported. This establishes L01 at the documented protocol-interface level using the same source-embedded-definition approach accepted elsewhere in the matrix.", "method": "Pinned embedded protocol definitions and applicable grants; documentary inference", "source_label": "Tailscale BSD definitions, selected WireGuard MIT source, Noise IPR, IETF TLP and OpenID notices", "sources": [ "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/LICENSE", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/tailcfg/tka.go", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/control/controlclient/direct.go", "https://github.com/tailscale/tailscale/blob/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/go.mod", "https://github.com/tailscale/wireguard-go/blob/e61b6b78110b/LICENSE", "https://noiseprotocol.org/noise.html#ipr", "https://trustee.ietf.org/documents/trust-legal-provisions/", "https://openid.net/specs/openid-connect-core-1_0.html#Notices" ], "editorial_references": [ "round602.html", "round602-sources.json" ], "qualification": "Preserve BSD copyright, conditions and disclaimer; retain MIT notices in covered copies; follow applicable IETF/OpenID attribution and code-component notices. No endorsement or compatibility follows from modification. This finding does not license separately published website prose, disclose the proprietary managed coordinator, grant access to any hosted service or IdP, or establish patent clearance (L02). The selected managed-control/Tailnet-Lock profile is unchanged; Headscale is not substituted. Source definitions establish a rights path, not a completeness/interoperability certification for every managed-product feature. No account, runtime test or service benchmark was used. Documentary classification, not legal clearance." }, { "id": "L01-RA", "feature": "L01", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Verify authoritative use/implementation permissions across the selected specification layers; distinguish notices and compatibility claims from restrictions on use. Assess patent grants separately in L02. Evaluate only the declared stack; record architectural and executable evidence separately." }, { "id": "L02-PN", "feature": "L02", "stack": "PN", "status": "Y", "reason": "The PRP owner expressly confirms a royalty-free policy and instructs that this commitment be treated as declared. The owner also states that no patent applications have been filed and that development is public. Credit the recorded owner declaration for claims under that owner's control; publication of the formal statement is planned for subsequent disclosures.", "method": "Attributable holder policy declaration; publication status disclosed separately", "source_label": "Direct PRP owner declaration, editorial conversation, 2026-10-16", "sources": [], "editorial_references": [ "round356-review.json", "round356-review.json" ], "qualification": "Owner-declared policy, not an already published patent license, registered IETF disclosure or legal enforceability opinion. No third-party rights are waived or cleared, including rights in dependencies or the IP/UDP layers. No claim that a patent exists. Final public wording and covered specification versions remain documentation tasks; the declared policy itself is decided. The revised L02 evidence rule applies equally to all projects." }, { "id": "L02-PI", "feature": "L02", "stack": "PI", "status": "Y", "reason": "The PRP owner expressly confirms a royalty-free policy and instructs that this commitment be treated as declared. The owner also states that no patent applications have been filed and that development is public. Credit the recorded owner declaration for claims under that owner's control; publication of the formal statement is planned for subsequent disclosures.", "method": "Attributable holder policy declaration; publication status disclosed separately", "source_label": "Direct PRP owner declaration, editorial conversation, 2026-10-16", "sources": [], "editorial_references": [ "round356-review.json", "round356-review.json" ], "qualification": "Owner-declared policy, not an already published patent license, registered IETF disclosure or legal enforceability opinion. No third-party rights are waived or cleared, including rights in dependencies or the IP/UDP layers. No claim that a patent exists. Final public wording and covered specification versions remain documentation tasks; the declared policy itself is decided. The revised L02 evidence rule applies equally to all projects." }, { "id": "L02-IP", "feature": "L02", "stack": "IP", "status": "Y", "reason": "The pinned gVisor netstack IPv4 and IPv6 source files explicitly carry Apache-2.0 notices attributed to The gVisor Authors. Section 3 of the attached license grants royalty-free patent rights for contributor-controlled claims necessarily infringed by their contributions alone or with the licensed Work. This is a concrete implementation-bound declaration for IP code under the same bounded-holder rule used for PRP and other L02 positives. The evidence is the express patent clause and its attachment to the IP implementations, not simply public code or the absence of IETF disclosures.", "method": "Documentary patent-declaration scope review; no runtime or legal clearance", "source_label": "Pinned public license clauses and source/package attribution, reviewed 2026-10-22", "sources": [ "https://raw.githubusercontent.com/google/gvisor/c5ab48fa9b2d23e861cc3fd17be01b3b4338be14/LICENSE", "https://raw.githubusercontent.com/google/gvisor/c5ab48fa9b2d23e861cc3fd17be01b3b4338be14/pkg/tcpip/network/ipv4/ipv4.go", "https://raw.githubusercontent.com/google/gvisor/c5ab48fa9b2d23e861cc3fd17be01b3b4338be14/pkg/tcpip/network/ipv6/ipv6.go", "https://gvisor.dev/docs/architecture_guide/networking/" ], "editorial_references": [ "round413-sources.json" ], "qualification": "Published grant limited to the Apache-licensed gVisor contributions and Work, with patent-litigation termination and other license conditions. The root file also lists MIT/BSD components; those are not silently assigned the Apache patent grant. No rights are asserted for Linux, BGP/PIM implementations, dependencies, independent reimplementations or other holders. This is not clearance of the complete IP composition or a finding that any patent exists. gVisor is an additional licensing witness, not a substitution for the comparison deployment or evidence of its complete feature set." }, { "id": "L02-BP", "feature": "L02", "stack": "BP", "status": "Y", "reason": "DTN7-RS supplies a published patent-grant witness for the BPv7 layer common to this composition. At the pinned commit, package dtn7 0.22.0 identifies RFC 9171 and offers MIT OR Apache-2.0; COPYRIGHT attributes the project to Lars Baumgaertner. Selecting Apache-2.0 invokes section 3, an express royalty-free grant for contributor-controlled claims necessarily infringed by contributions alone or with the licensed Work. The README applies the dual-license terms to intentional contributions unless expressly stated otherwise. This meets the existing holder-bounded, implementation-bound L02 rule. These three cells share one BP-layer witness; they are not three independent grants or a complete-stack patent clearance.", "method": "Common-layer, holder-bounded patent-declaration review; no runtime or legal clearance", "source_label": "Pinned DTN7-RS license, attribution, package metadata and BP code; 2026-10-22", "sources": [ "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/LICENSE-APACHE", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/COPYRIGHT", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/README.md", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/core/dtn7/Cargo.toml", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/core/dtn7/src/core/bundlepack.rs" ], "editorial_references": [ "round414-sources.json" ], "qualification": "Credit only covered DTN7-RS contributions and the licensed Work under the Apache option, with patent-litigation termination and other conditions. No grant is attributed to NASA/JPL/Caltech ION, CCSDS, TCPCL/TLS, CGR/SABR, LTP, Encapsulation/AOS, dependencies or unrelated patent holders. No promise covers every independently written BP implementation. The new witness does not replace the selected deployment or demonstrate its complete security, routing or carrier composition; E03 and other technical cells remain unchanged. License selection is not a finding of patent existence, validity, infringement or legal enforceability." }, { "id": "L02-CG", "feature": "L02", "stack": "CG", "status": "Y", "reason": "DTN7-RS supplies a published patent-grant witness for the BPv7 layer common to this composition. At the pinned commit, package dtn7 0.22.0 identifies RFC 9171 and offers MIT OR Apache-2.0; COPYRIGHT attributes the project to Lars Baumgaertner. Selecting Apache-2.0 invokes section 3, an express royalty-free grant for contributor-controlled claims necessarily infringed by contributions alone or with the licensed Work. The README applies the dual-license terms to intentional contributions unless expressly stated otherwise. This meets the existing holder-bounded, implementation-bound L02 rule. These three cells share one BP-layer witness; they are not three independent grants or a complete-stack patent clearance.", "method": "Common-layer, holder-bounded patent-declaration review; no runtime or legal clearance", "source_label": "Pinned DTN7-RS license, attribution, package metadata and BP code; 2026-10-22", "sources": [ "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/LICENSE-APACHE", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/COPYRIGHT", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/README.md", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/core/dtn7/Cargo.toml", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/core/dtn7/src/core/bundlepack.rs" ], "editorial_references": [ "round414-sources.json" ], "qualification": "Credit only covered DTN7-RS contributions and the licensed Work under the Apache option, with patent-litigation termination and other conditions. No grant is attributed to NASA/JPL/Caltech ION, CCSDS, TCPCL/TLS, CGR/SABR, LTP, Encapsulation/AOS, dependencies or unrelated patent holders. No promise covers every independently written BP implementation. The new witness does not replace the selected deployment or demonstrate its complete security, routing or carrier composition; E03 and other technical cells remain unchanged. License selection is not a finding of patent existence, validity, infringement or legal enforceability." }, { "id": "L02-LT", "feature": "L02", "stack": "LT", "status": "Y", "reason": "DTN7-RS supplies a published patent-grant witness for the BPv7 layer common to this composition. At the pinned commit, package dtn7 0.22.0 identifies RFC 9171 and offers MIT OR Apache-2.0; COPYRIGHT attributes the project to Lars Baumgaertner. Selecting Apache-2.0 invokes section 3, an express royalty-free grant for contributor-controlled claims necessarily infringed by contributions alone or with the licensed Work. The README applies the dual-license terms to intentional contributions unless expressly stated otherwise. This meets the existing holder-bounded, implementation-bound L02 rule. These three cells share one BP-layer witness; they are not three independent grants or a complete-stack patent clearance.", "method": "Common-layer, holder-bounded patent-declaration review; no runtime or legal clearance", "source_label": "Pinned DTN7-RS license, attribution, package metadata and BP code; 2026-10-22", "sources": [ "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/LICENSE-APACHE", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/COPYRIGHT", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/README.md", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/core/dtn7/Cargo.toml", "https://raw.githubusercontent.com/dtn7/dtn7-rs/dc26e2adcb506227d3c205bb25aa1a003d6688fd/core/dtn7/src/core/bundlepack.rs" ], "editorial_references": [ "round414-sources.json" ], "qualification": "Credit only covered DTN7-RS contributions and the licensed Work under the Apache option, with patent-litigation termination and other conditions. No grant is attributed to NASA/JPL/Caltech ION, CCSDS, TCPCL/TLS, CGR/SABR, LTP, Encapsulation/AOS, dependencies or unrelated patent holders. No promise covers every independently written BP implementation. The new witness does not replace the selected deployment or demonstrate its complete security, routing or carrier composition; E03 and other technical cells remain unchanged. License selection is not a finding of patent existence, validity, infringement or legal enforceability." }, { "id": "L02-LP", "feature": "L02", "stack": "LP", "status": "Y", "reason": "The official py-libp2p implementation at the pinned commit declares MIT AND Apache-2.0 in pyproject.toml and includes a LICENSE-APACHE notice attributed to Zixuan Zhang. Its QUIC transport implements RFC 9000 configuration and integrates the libp2p private key and Peer ID with TLS security. Apache-2.0 section 3 supplies an express royalty-free contributor patent grant within the licensed Work. This additional implementation-bound witness meets L02 without treating the MIT-only go-libp2p license as an express patent grant.", "method": "Express patent-clause applicability review; no new runtime or legal clearance", "source_label": "Official pinned py-libp2p license, package metadata and native QUIC source; reviewed 2026-10-17", "sources": [ "https://github.com/libp2p/py-libp2p/blob/79985430f45a64b605cfc233d42f41103dedeb04/LICENSE-APACHE", "https://github.com/libp2p/py-libp2p/blob/79985430f45a64b605cfc233d42f41103dedeb04/pyproject.toml", "https://github.com/libp2p/py-libp2p/blob/79985430f45a64b605cfc233d42f41103dedeb04/libp2p/transport/quic/transport.py", "https://github.com/libp2p/py-libp2p/blob/79985430f45a64b605cfc233d42f41103dedeb04/README.md", "https://www.apache.org/licenses/LICENSE-2.0" ], "editorial_references": [ "round377-sources.json" ], "qualification": "The package metadata says AND, not OR: preserve both license obligations rather than inventing a choice. Credit only contributor-controlled claims necessarily infringed by contributions alone or with this Work; patent-litigation termination applies. This is not a grant for go-libp2p, independent reimplementations, all protocol claims or third-party dependencies. The Python code is an additional documentary license witness, not a replacement for existing Go runtime evidence or proof of all selected migration and policy behavior. No profile, interoperability, performance or other-cell verdict changes." }, { "id": "L02-TO", "feature": "L02", "stack": "TO", "status": "Y", "reason": "The already examined Arti commit explicitly offers MIT OR Apache-2.0, including the tor-hsservice onion-service provider crate. Choosing Apache-2.0 supplies section 3: an express royalty-free patent grant from contributors for licensable claims necessarily infringed by their contributions alone or together with the Work. README contribution terms apply the dual-license policy to intentional submissions unless explicitly stated otherwise. This meets the same implementation-bound, holder-scoped declaration rule as the other L02 positives.", "method": "Express patent grant and implementation attribution; no legal clearance or runtime test", "source_label": "Pinned official Arti repository, README and onion-service crate license metadata; reviewed 2026-10-17", "sources": [ "https://gitlab.torproject.org/tpo/core/arti/-/blob/3adfc4b052b6520c12f6193c593c5557fa5f3771/LICENSE-APACHE", "https://gitlab.torproject.org/tpo/core/arti/-/blob/3adfc4b052b6520c12f6193c593c5557fa5f3771/README.md", "https://gitlab.torproject.org/tpo/core/arti/-/blob/3adfc4b052b6520c12f6193c593c5557fa5f3771/crates/tor-hsservice/Cargo.toml" ], "editorial_references": [ "round376-sources.json" ], "qualification": "Credit the Apache option and covered Arti contributions, not the MIT option alone, C Tor, third-party patents or every independently written Tor implementation. Patent litigation alleging infringement by the Work or incorporated contributions terminates the grant; other license conditions remain. Optional differently licensed components retain their own terms. This does not assert that all selected Conflux linking/resumption mechanisms exist in executable form: E03-TO remains No for the complete selected composition. No protocol profile, maturity, interoperability or patent-validity verdict changes." }, { "id": "L02-I2", "feature": "L02", "stack": "I2", "status": "?", "reason": "i2pd 2.58.0 LICENSE attributes the code to the PurpleI2P Project and grants BSD-3-Clause permissions. It contains no express patent grant or non-assertion clause. This is a specific checked source, not an inference from a missing search result. Additional candidate checked: The root Apache license file belongs to optional Google Material Icons according to the README. The workspace declares MIT for the I2P implementation. The presence of LICENSE-APACHE therefore does not supply an express patent grant for the router.", "method": "Documentary byte accounting and source-role/lifecycle analysis; no runtime or legal clearance", "source_label": "Primary RFCs and pinned implementation sources; reviewed 2026-10-22", "sources": [ "https://raw.githubusercontent.com/eepnet/emissary/9b43484a21d5a1291c4881cdae62a36c527f8c0f/README.md", "https://raw.githubusercontent.com/PurpleI2P/i2pd/2.58.0/LICENSE", "https://raw.githubusercontent.com/eepnet/emissary/9b43484a21d5a1291c4881cdae62a36c527f8c0f/LICENSE", "https://raw.githubusercontent.com/eepnet/emissary/9b43484a21d5a1291c4881cdae62a36c527f8c0f/Cargo.toml" ], "editorial_references": [ "round418-sources.json", "round418-budget.json" ], "qualification": "The examined material does not establish the required express holder commitment. Locate a separate patent-specific declaration or an applicable implementation grant with identified scope and conditions. Do not repeat this root-license check without a changed version or new document. No patent existence, infringement, royalty obligation, lack of implied rights or universal freedom-to-operate conclusion follows. No holder contact was made. This new candidate is also insufficient; do not infer patent rights from an unrelated bundled license." }, { "id": "L02-YG", "feature": "L02", "stack": "YG", "status": "Y", "reason": "The pinned Yggdrasil license expressly applies LGPLv3, which incorporates GPLv3 terms. GPLv3 section 11 expressly grants a non-exclusive worldwide royalty-free patent license for each contributor's essential patent claims to make, use, sell, offer for sale, import, run, modify and propagate that contributor version. Essential claims exclude claims infringed only by further modifications. Its static-linking exception changes specified combined-work obligations, not this patent clause. The selected Ironwood dependency also publishes MPL-2.0 section 2.1(b), a contributor patent grant for contributions/contributor versions.", "method": "Express patent-clause and applicability review under the common holder-bounded L02 rule", "source_label": "Version-pinned project licenses and attributable source notices; documentary review 2026-10-17", "sources": [ "https://raw.githubusercontent.com/yggdrasil-network/yggdrasil-go/422836eeb21a99790caa286aa63d493bbc4766d7/LICENSE", "https://www.gnu.org/licenses/gpl-3.0.txt", "https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/LICENSE" ], "editorial_references": [ "round373-sources.json" ], "qualification": "Respect LGPL and exception conditions. Ironwood MPL exclusions and patent-litigation termination remain; this is not a protocol-wide grant by every possible rights holder. Published implementation-bound grant, not a blanket royalty-free promise for arbitrary independent reimplementations. Credit only claims controlled by the declaring contributors within the grant; no third-party, dependency or underlying-layer clearance is inferred. License compliance remains required. No finding that a patent exists, is valid or is infringed, and no legal-enforceability opinion." }, { "id": "L02-CJ", "feature": "L02", "stack": "CJ", "status": "Y", "reason": "The pinned cjdns repository publishes GPLv3 and its SwitchPinger source expressly applies version 3 or later. GPLv3 section 11 expressly grants a non-exclusive worldwide royalty-free patent license for each contributor's essential patent claims to make, use, sell, offer for sale, import, run, modify and propagate that contributor version. Essential claims exclude claims infringed only by further modifications.", "method": "Express patent-clause and applicability review under the common holder-bounded L02 rule", "source_label": "Version-pinned project licenses and attributable source notices; documentary review 2026-10-17", "sources": [ "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/LICENSE", "https://raw.githubusercontent.com/cjdelisle/cjdns/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SwitchPinger.c", "https://www.gnu.org/licenses/gpl-3.0.txt" ], "editorial_references": [ "round373-sources.json" ], "qualification": "GPL compliance and termination provisions apply; the finding is for the licensed contributor versions, not every possible cjdns-compatible implementation. Published implementation-bound grant, not a blanket royalty-free promise for arbitrary independent reimplementations. Credit only claims controlled by the declaring contributors within the grant; no third-party, dependency or underlying-layer clearance is inferred. License compliance remains required. No finding that a patent exists, is valid or is infringed, and no legal-enforceability opinion." }, { "id": "L02-MQ", "feature": "L02", "stack": "MQ", "status": "Y", "reason": "Noq supplies an implementation-scoped express patent commitment for native IETF QUIC and multipath code. Its pinned README identifies RFC 9000/9001/9002 and the QUIC multipath extension, and offers MIT OR Apache-2.0; noq-proto inherits that workspace license. Selecting Apache-2.0 invokes section 3 for contributor-controlled claims necessarily infringed by contributions alone or with the Work. Production paths.rs implements multipath PathId and per-path packet-number state; transport_parameters.rs encodes and parses initial_max_path_id. This binds the grant to relevant QUIC/multipath code rather than the unrelated 2014 Google QUIC disclosure or a cryptographic dependency.", "method": "Primary pinned implementation licensing and source-scope review; no runtime or patent clearance", "source_label": "Noq pinned README, workspace/crate manifests, production path/transport-parameter code; Apache-2.0 section 3", "sources": [ "https://raw.githubusercontent.com/n0-computer/noq/a78daf871419d9ebec591d40ba5a08aff1eba854/LICENSE-APACHE", "https://raw.githubusercontent.com/n0-computer/noq/a78daf871419d9ebec591d40ba5a08aff1eba854/README.md", "https://raw.githubusercontent.com/n0-computer/noq/a78daf871419d9ebec591d40ba5a08aff1eba854/Cargo.toml", "https://raw.githubusercontent.com/n0-computer/noq/a78daf871419d9ebec591d40ba5a08aff1eba854/noq-proto/Cargo.toml", "https://raw.githubusercontent.com/n0-computer/noq/a78daf871419d9ebec591d40ba5a08aff1eba854/noq-proto/src/connection/paths.rs", "https://raw.githubusercontent.com/n0-computer/noq/a78daf871419d9ebec591d40ba5a08aff1eba854/noq-proto/src/transport_parameters.rs", "https://www.apache.org/licenses/LICENSE-2.0" ], "editorial_references": [ "round442-sources.json", "round442.html" ], "qualification": "Yes records the Apache-licensed Noq contributor Work, not a specification-wide patent promise for every implementation of multipath draft-21. Shared path-ID, packet-number-space and initial_max_path_id mechanisms establish relevance; exact draft-21 wire compatibility and complete feature conformance were not tested or inferred. Apache section 3 scope and patent-litigation termination remain applicable. No license from picoquic authors, whole UDP/IP/TLS dependency clearance, third-party patent clearance or performance result follows. Noq is an additional licensing witness, not a replacement for the selected transport profile or runtime evidence." }, { "id": "L02-SC", "feature": "L02", "stack": "SC", "status": "Y", "reason": "The pinned SCION implementation publishes Apache-2.0. Section 3 expressly grants royalty-free patent rights from contributors for claims licensable by them necessarily infringed by their contributions alone or with the Work. This bounded public commitment meets the same holder-scoped L02 rule used for PRP.", "method": "Express patent-clause and applicability review under the common holder-bounded L02 rule", "source_label": "Version-pinned project licenses and attributable source notices; documentary review 2026-10-17", "sources": [ "https://raw.githubusercontent.com/scionproto/scion/e6b0576682c73845a185f14ea68e8b0923374874/LICENSE", "https://raw.githubusercontent.com/scionproto/scion/e6b0576682c73845a185f14ea68e8b0923374874/README.md" ], "editorial_references": [ "round373-sources.json" ], "qualification": "Patent litigation alleging infringement by the Work or incorporated contributions terminates the section 3 grant. Published implementation-bound grant, not a blanket royalty-free promise for arbitrary independent reimplementations. Credit only claims controlled by the declaring contributors within the grant; no third-party, dependency or underlying-layer clearance is inferred. License compliance remains required. No finding that a patent exists, is valid or is infringed, and no legal-enforceability opinion." }, { "id": "L02-RT", "feature": "L02", "stack": "RT", "status": "Y", "reason": "The previously identified independent Reticulum implementation Leviculum declares AGPL-3.0-or-later in its workspace, attributed to Lew Palm, and its core crate inherits that license. The pinned LICENSE contains AGPLv3 section 11, expressly granting royalty-free rights under each contributor's essential patent claims for its contributor version. This qualifies as a published, implementation-bound declaration. It does not derive a patent promise from the Python reference license or the protocol public-domain statement.", "method": "Documentary patent-declaration scope review; no runtime or legal clearance", "source_label": "Pinned public license clauses and source/package attribution, reviewed 2026-10-22", "sources": [ "https://codeberg.org/Lew_Palm/leviculum/raw/commit/5035bac7d80ae8baf2481d11d6af2acb7cede123/LICENSE", "https://codeberg.org/Lew_Palm/leviculum/raw/commit/5035bac7d80ae8baf2481d11d6af2acb7cede123/Cargo.toml", "https://codeberg.org/Lew_Palm/leviculum/raw/commit/5035bac7d80ae8baf2481d11d6af2acb7cede123/leviculum-core/Cargo.toml", "https://codeberg.org/Lew_Palm/leviculum/raw/commit/5035bac7d80ae8baf2481d11d6af2acb7cede123/README.md" ], "editorial_references": [ "round336-sources.json", "round413-sources.json" ], "qualification": "Credit contributor-controlled essential claims within the licensed Leviculum contributor versions only; claims arising solely from further modifications are excluded by the definition. License compliance, including applicable source and network-interaction obligations, remains required. This is not a declaration by Mark Qvist, a waiver of dependency/third-party rights or a promise for all Reticulum reimplementations. E03-RT remains Pending: the previous selected-1.5.5 coverage and dependency gaps are not resolved by a patent clause. The same distinction already applies to the Arti L02 witness with incomplete selected implementation coverage. No interoperability, maturity, performance or legal-enforceability finding is made." }, { "id": "L02-NS", "feature": "L02", "stack": "NS", "status": "Y", "reason": "The public Nostrmo and nostr_sdk repositories maintained by haorendashu publish GPLv3 license texts. The pinned application selects the inspected SDK commit through its packages/nostr_sdk gitlink and local package dependency. The SDK Event class explicitly implements NIP-01 event serialization, SHA-256 identifiers and Schnorr signing/verification calls. GPLv3 section 11 supplies an express royalty-free patent grant under each contributor's essential claims for its contributor version. This additional client/SDK witness satisfies the existing holder-bounded L02 rule without inferring a patent grant from nostr-rs-relay's MIT license.", "method": "Documentary patent-grant and source-role mapping; no runtime or legal clearance", "source_label": "Pinned Nostrmo and SDK license, gitlink and NIP-01 source; reviewed 2026-10-22", "sources": [ "https://raw.githubusercontent.com/haorendashu/nostr_sdk/94209a87b42f275199842751f052be1b8ed94b0f/LICENSE", "https://raw.githubusercontent.com/haorendashu/nostrmo/5f3166cea733de60d318ea00a4401dd07bf62df2/LICENSE", "https://raw.githubusercontent.com/haorendashu/nostrmo/5f3166cea733de60d318ea00a4401dd07bf62df2/.gitmodules", "https://raw.githubusercontent.com/haorendashu/nostrmo/5f3166cea733de60d318ea00a4401dd07bf62df2/pubspec.yaml", "https://raw.githubusercontent.com/haorendashu/nostr_sdk/94209a87b42f275199842751f052be1b8ed94b0f/lib/event.dart" ], "editorial_references": [ "round416-sources.json" ], "qualification": "Published implementation-bound grant, limited to the covered contributor versions and claims controlled by their contributors; the repository maintainer identity is haorendashu, not an independently verified civil identity. Claims arising only from further modifications are excluded by the license definition. License compliance remains required. No grant is attributed to NIP authors generally, nostr-rs-relay, crypto dependencies, other submodules or independent implementations. This does not replace the selected relay or establish TLS configuration, two-relay publication, memory-only retention or complete dependency coverage. Optional NIPs in the application are not added to Basic Nostr. No runtime, interoperability or legal-enforceability conclusion." }, { "id": "L02-MT", "feature": "L02", "stack": "MT", "status": "Y", "reason": "The selected Meshtastic firmware repository publishes GPLv3 as its root license. GPLv3 section 11 expressly grants a non-exclusive worldwide royalty-free patent license for each contributor's essential patent claims to make, use, sell, offer for sale, import, run, modify and propagate that contributor version. Essential claims exclude claims infringed only by further modifications.", "method": "Express patent-clause and applicability review under the common holder-bounded L02 rule", "source_label": "Version-pinned project licenses and attributable source notices; documentary review 2026-10-17", "sources": [ "https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/LICENSE", "https://www.gnu.org/licenses/gpl-3.0.txt" ], "editorial_references": [ "round373-sources.json" ], "qualification": "Do not extend firmware contributor grants to radio-chip patents, hardware, proprietary vendor code or all external dependencies. Published implementation-bound grant, not a blanket royalty-free promise for arbitrary independent reimplementations. Credit only claims controlled by the declaring contributors within the grant; no third-party, dependency or underlying-layer clearance is inferred. License compliance remains required. No finding that a patent exists, is valid or is infringed, and no legal-enforceability opinion." }, { "id": "L02-GN", "feature": "L02", "stack": "GN", "status": "Y", "reason": "GNUnet 0.20.0 COPYING contains AGPLv3 and the transport source expressly applies AGPLv3 or later with GNUnet e.V. copyright attribution. AGPLv3 section 11 expressly grants a worldwide royalty-free license from contributors for essential claims covering their contributor versions.", "method": "Express patent-clause and applicability review under the common holder-bounded L02 rule", "source_label": "Version-pinned project licenses and attributable source notices; documentary review 2026-10-17", "sources": [ "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz", "https://ftp.gnu.org/gnu/gnunet/gnunet-0.20.0.tar.gz", "https://www.gnu.org/licenses/agpl-3.0.txt" ], "editorial_references": [ "round373-sources.json" ], "qualification": "AGPL network-source and other compliance conditions remain. The FSF authorship of the license text is not a grant of patents held by unrelated parties. Published implementation-bound grant, not a blanket royalty-free promise for arbitrary independent reimplementations. Credit only claims controlled by the declaring contributors within the grant; no third-party, dependency or underlying-layer clearance is inferred. License compliance remains required. No finding that a patent exists, is valid or is infringed, and no legal-enforceability opinion." }, { "id": "L02-ND", "feature": "L02", "stack": "ND", "status": "Y", "reason": "NFD 24.07 and ndn-cxx 0.9.0 publish GPLv3. GPLv3 section 11 expressly grants a non-exclusive worldwide royalty-free patent license for each contributor's essential patent claims to make, use, sell, offer for sale, import, run, modify and propagate that contributor version. Essential claims exclude claims infringed only by further modifications. The official NDN policy explicitly chooses GPLv3 as its core implementation patent-protection strategy.", "method": "Express patent-clause and applicability review under the common holder-bounded L02 rule", "source_label": "Version-pinned project licenses and attributable source notices; documentary review 2026-10-17", "sources": [ "https://raw.githubusercontent.com/named-data/NFD/NFD-24.07/COPYING.md", "https://raw.githubusercontent.com/named-data/ndn-cxx/ndn-cxx-0.9.0/COPYING.md", "https://www.gnu.org/licenses/gpl-3.0.txt", "https://named-data.net/project/ndn-copyright-and-patents/" ], "editorial_references": [ "round373-sources.json" ], "qualification": "NDN consortium membership is not a patent license; institutional claims outside the licensed contributor versions remain outside this finding. Published implementation-bound grant, not a blanket royalty-free promise for arbitrary independent reimplementations. Credit only claims controlled by the declaring contributors within the grant; no third-party, dependency or underlying-layer clearance is inferred. License compliance remains required. No finding that a patent exists, is valid or is infringed, and no legal-enforceability opinion." }, { "id": "L02-AX", "feature": "L02", "stack": "AX", "status": "Y", "reason": "LinBPQ L2Code.c, L3Code.c and L4Code.c at the pinned commit carry copyright notices attributed to John Wiseman G8BPQ and explicitly license LinBPQ/BPQ32 under GPL version 3 or later. The inspected files contain AX.25 frame handling, NET/ROM node/routing messages and NET/ROM transport connection handling. GPLv3 section 11 supplies an express royalty-free patent grant for each contributor version under that contributor's essential patent claims. This is an additional implementation-bound witness under the existing L02 rule, separate from the previously inconclusive Linux kernel GPLv2 composition.", "method": "Documentary patent-grant and code-role mapping; no runtime or legal clearance", "source_label": "Pinned LinBPQ source notices and official GPLv3 section 11, reviewed 2026-10-22", "sources": [ "https://raw.githubusercontent.com/g8bpq/linbpq/228047d76f410e13a564fb00787516f69b96ff44/L3Code.c", "https://raw.githubusercontent.com/g8bpq/linbpq/228047d76f410e13a564fb00787516f69b96ff44/L2Code.c", "https://raw.githubusercontent.com/g8bpq/linbpq/228047d76f410e13a564fb00787516f69b96ff44/L4Code.c", "https://www.gnu.org/licenses/gpl-3.0.txt" ], "editorial_references": [ "round415-sources.json" ], "qualification": "Credit only the covered LinBPQ contributor versions and controlled essential claims; claims arising solely from further modifications are excluded by the license definition. License compliance remains required. The repository has no root LICENSE/COPYING in the inspected tree; attribution rests on explicit source notices referring to the GPL and the official GPLv3 text, not a repository badge. No grant is inferred for Linux, original NET/ROM vendors, third-party libraries or independent implementations. This does not audit all repository files or qualify a complete executable profile. Optional TCP transport, INP3 and BBS behavior present in LinBPQ are not added to the selected direct-radio/serial composition. No runtime, radio operation or legal enforceability finding; all other cells remain unchanged." }, { "id": "L02-BA", "feature": "L02", "stack": "BA", "status": "?", "reason": "Linux 6.12 batman-adv main.c declares GPL-2.0. Kernel COPYING explicitly selects GPL version 2 only with a syscall exception. GPLv2 section 7 constrains distribution under conflicting patent obligations; it is not the express contributor patent grant found in GPLv3 section 11. Do not import the latter into this source.", "method": "Documentary negative-evidence boundary; Pending retained, not a No finding", "source_label": "Pinned implementation licenses and source notices, reviewed 2026-10-17", "sources": [ "https://raw.githubusercontent.com/torvalds/linux/v6.12/net/batman-adv/main.c", "https://raw.githubusercontent.com/torvalds/linux/v6.12/COPYING", "https://raw.githubusercontent.com/torvalds/linux/v6.12/LICENSES/preferred/GPL-2.0" ], "editorial_references": [ "round378-sources.json" ], "qualification": "The examined material does not establish the required express holder commitment. Locate a separate patent-specific declaration or an applicable implementation grant with identified scope and conditions. Do not repeat this root-license check without a changed version or new document. No patent existence, infringement, royalty obligation, lack of implied rights or universal freedom-to-operate conclusion follows. No holder contact was made." }, { "id": "L02-BL", "feature": "L02", "stack": "BL", "status": "Y", "reason": "BIRD v2.17.1 provides a new implementation-scoped licensing witness. Its README offers GPL version 2 or, at the recipient's option, any later version. Selecting GPLv3 invokes section 11's express royalty-free grant of each contributor's essential patent claims, within that contributor version. The pinned proto/babel/babel.c implements Babel routing and explicitly identifies RFC 8966 among supported standards. Its notices identify Toke Hoiland-Jorgensen, Ondrej Zajicek and CZ.NIC. This is a grant attached to relevant routing code, sufficient for L02's holder-bounded implementation route.", "method": "Primary pinned implementation licensing and source-scope review; no runtime or patent clearance", "source_label": "BIRD v2.17.1 README and proto/babel/babel.c; GNU GPLv3 sections 11 and 14", "sources": [ "https://raw.githubusercontent.com/CZ-NIC/bird/7ef70b27ef907bba7479989a5376842c893b12bb/README", "https://raw.githubusercontent.com/CZ-NIC/bird/7ef70b27ef907bba7479989a5376842c893b12bb/proto/babel/babel.c", "https://www.gnu.org/licenses/gpl-3.0.txt" ], "editorial_references": [ "round442-sources.json", "round442.html" ], "qualification": "The licensing witness is BIRD under the GPLv3 option, not a claim that GPLv2 alone contains the same express grant. The scope is covered contributor versions and controlled essential claims, subject to the license conditions. No grant from babeld or babel-rs authors is inferred, and no patent search, enforceability opinion, all-holder clearance or right to every independent reimplementation is established. BIRD is not substituted for the implementation used in other matrix experiments; no routing, interoperability or scale verdict changes." }, { "id": "L02-RI", "feature": "L02", "stack": "RI", "status": "Y", "reason": "Cisco disclosure 1270, submitted on 23 February 2010, promises non-assertion of its controlled patents for compliant implementations when the disclosed RPL technology is included in an IETF-adopted standard. RFC 6550 is the adopted successor of draft-ietf-roll-rpl. This is an attributable patent-specific commitment, not an inference from open copyright terms or IETF participation. Credit the declared policy for the covered RPL technology within this IPv6 IoT composition.", "method": "Documentary holder-policy and standard-lineage review; no legal clearance", "source_label": "Cisco IPR disclosure 1270 and adopted RPL RFC 6550; reviewed 2026-10-17", "sources": [ "https://datatracker.ietf.org/ipr/1270/", "https://datatracker.ietf.org/doc/rfc6550/", "https://www.rfc-editor.org/rfc/rfc6550.txt" ], "editorial_references": [ "round375-sources.json" ], "qualification": "The disclosure was posted at draft revision 06 and does not specify a revision limit; its express adoption clause binds the included technology. Do not infer coverage of unrelated later additions. Reciprocity permits defensive assertion, including past royalties, against a party asserting standard-essential claims against Cisco, affiliates or their standard implementations. Nonessential product portions are excluded. This is a holder-bounded policy finding, not clearance of all RPL holders, IPv6, 6LoWPAN, DTLS, hardware or dependencies. Patent validity, expiration and legal enforceability were not audited. No runtime or implementation-availability verdict changes." }, { "id": "L02-HP", "feature": "L02", "stack": "HP", "status": "Y", "reason": "Certicom disclosure 1541, submitted in April 2011 for the HIPv2 rfc5201-bis work, declares non-assertion of its controlled patent claims against compliant implementation if the standard is adopted. The Datatracker identifies RFC 7401 as the adopted successor of that draft. This is an attributable holder commitment satisfying the holder-bounded L02 rule; it is not merely a copyright license or IETF participation. Credit the declared non-assertion policy for its covered HIPv2 material, not an unlimited license to the entire stack.", "method": "Documentary commitment review; no patent clearance or runtime experiment", "source_label": "Primary holder disclosures and pinned implementation license, reviewed 2026-10-17", "sources": [ "https://datatracker.ietf.org/ipr/1541/", "https://www.ietf.org/ietf-ftp/ietf/IPR/certicom-ipr-draft-ietf-hip-rfc5201-bis-05.pdf", "https://datatracker.ietf.org/doc/rfc7401/" ], "editorial_references": [ "round374-sources.json" ], "qualification": "The attached declaration identifies draft revision 05. Do not extend it automatically to later added mechanisms or separate ESP/mobility specifications. Conditions include compliance, seller notice, reciprocal licensing and broad defensive withdrawal, including possible past royalties after patent assertions against the holder, affiliates or their products. Optional royalty-bearing licenses do not erase the conditional non-assertion route. This records the published policy, not current patent validity, expiration, enforceability, third-party clearance or a legal finding that every RFC 7401 implementation is covered." }, { "id": "L02-CX", "feature": "L02", "stack": "CX", "status": "Y", "reason": "Cisco disclosure 3627, submitted 11 July 2019, explicitly identifies RFC 8569 and RFC 8609. It declares a conditional non-assertion policy for necessary Cisco-controlled patent claims when implementing the specified technology. This is a concrete holder commitment, beyond the older Distillery copyright notice and general FRAND language. L02 evaluates a declared policy rather than an effective license; the attributable conditional commitment therefore qualifies as Yes, with its activation condition and scope recorded explicitly.", "method": "Documentary policy review under the common holder-bounded L02 rule; activation distinguished from declaration", "source_label": "Cisco holder declaration in IETF Datatracker and RFC status notices; reviewed 2026-10-22", "sources": [ "https://datatracker.ietf.org/ipr/3627/", "https://www.rfc-editor.org/rfc/rfc8569.html", "https://www.rfc-editor.org/rfc/rfc8609.html" ], "editorial_references": [ "round429-sources.json", "round270-sources.json" ], "qualification": "The declaration conditions the non-assertion route on adoption as an IETF standard. RFC 8569 and RFC 8609 are Experimental IRTF documents; their publication does not establish fulfillment of that condition. No presently effective royalty-free license is asserted. Other terms include compliance and reciprocity, defensive assertion (including past royalties) after specified patent litigation, and exclusion of product portions unnecessary for compliance. A royalty-bearing option also exists. Credit only the declared Cisco-controlled scope; no third-party clearance, patent-validity or enforceability conclusion." }, { "id": "L02-LI", "feature": "L02", "stack": "LI", "status": "Y", "reason": "The pinned lispers.net source is offered under Apache License 2.0. Section 3 grants a royalty-free patent license for necessarily infringed claims licensable by each Contributor, within its Contribution/Work scope, with patent-litigation termination. This meets the same holder-bounded commitment criterion used for other implementations.", "method": "Pinned source and documentation review", "source_label": "LISP RFC 9300; Linux socket/capability documentation; pinned lispers.net source as applicable", "sources": [ "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/LICENSE", "https://github.com/farinacci/lispers.net/blob/a61c30bfdf628f9728cf072dbd2417d07d62d70b/README.md" ], "editorial_references": [], "qualification": "Published implementation-scoped contributor commitment only. Not third-party patent clearance, a guarantee for every independent LISP implementation, or a legal enforceability finding." }, { "id": "L02-IL", "feature": "L02", "stack": "IL", "status": "?", "reason": "ILNPv6 has been admitted with an explicit composition; this criterion still requires its own evidence assessment.", "method": "Documentary evidence with explicit scope", "source_label": "ILNP experimental RFCs 6740–6744", "sources": [ "https://www.rfc-editor.org/rfc/rfc6740.html", "https://www.rfc-editor.org/rfc/rfc6741.html", "https://www.rfc-editor.org/rfc/rfc6744.html" ], "editorial_references": [], "qualification": "For the declared ILNPv6/TCP profile: Locate the actual patent grant/non-assertion commitment and relevant disclosures for required layers. Verify applicability and conditions; lack of a located commitment remains Pending until absence is established. Distinguish ILNP identifiers/locators from ordinary IPv6 address semantics and optional security or multipath extensions." }, { "id": "L02-TS", "feature": "L02", "stack": "TS", "status": "Y", "reason": "Tailscale Inc. publishes an explicit royalty-free patent grant for necessarily infringed claims under its control in its distributed implementation.", "method": "Official documentation and pinned source/declaration review; no runtime test", "source_label": "Tailscale identity documentation, LocalAPI and PATENTS grant", "sources": [ "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/PATENTS", "https://tailscale.com/docs/concepts/tailscale-identity", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/PATENTS", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/LICENSE", "https://raw.githubusercontent.com/tailscale/tailscale/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225/ipn/localapi/localapi.go", "https://tailscale.com/docs/install/linux" ], "editorial_references": [ "round588.html", "round588-sources.json" ], "qualification": "Holder-bounded implementation grant, admitted by the same L02 rule as other implementation grants. It excludes claims arising only from further modification and terminates upon specified patent litigation. It does not cover arbitrary independent reimplementations, unpublished service code, third-party patents, or service subscription charges; no enforceability or patent-clearance opinion." }, { "id": "L02-RA", "feature": "L02", "stack": "RA", "status": "?", "reason": "Not yet assessed under this criterion for the selected composition. No inference from a neighboring criterion or protocol label is made.", "method": "Primary evidence for the selected composition; identify mechanism, scope and implementation limits", "source_label": "RINA project architectural documentation", "sources": [ "https://pouzinsociety.org/research-results-highlights/", "https://irati.github.io/stack/", "https://csr.bu.edu/rina/about.html", "https://pouzinsociety.org/research-results-highlights/" ], "editorial_references": [ "round645.html" ], "qualification": "Obtain a dated attributable holder declaration or applicable public grant; identify scope, conditions and publication status. Do not infer a commitment solely from open development, copyright licensing or IETF participation. Evaluate only the declared stack; record architectural and executable evidence separately." } ], "marks": [ { "file": "logos/hipv2.svg", "source": "Original editorial typography, 2026-10-15", "sha256": "d836317b845bf765811c594420841ae5c1d4e480bc20c5d07b2774917e66174e", "bytes": 328, "note": "Neutral typographic label for the selected composition, not an official project logo or endorsement.", "rights": "Original editorial label using generic sans-serif; no third-party artwork." }, { "file": "logos/ccnx.jpg", "source": "https://avatars.githubusercontent.com/u/128038?v=4", "project_url": "https://github.com/ProjectCCNx", "sha256": "5833201d23b8e161facb733564198018a8d53a8a463a234bb7751f9f7d85e106", "bytes": 16952, "note": "CCNx project mark from the ProjectCCNx GitHub account avatar, supplied by the user. GitHub public user API identifies account 128038 as ProjectCCNx (Content Centric Networking). Retrieved and visually inspected on 2026-10-15; original 460 by 460 JPEG bytes preserved.", "rights": "Project mark used for referential identification; no endorsement or unrestricted trademark license inferred. Logo-specific reuse terms not established." }, { "file": "logos/iot-rpl.svg", "source": "Editorial typographic label, 2026-10-15", "sha256": "fff20dd148fd75e85bddfe45c8766dadc94afa56040ed4c7dac5ef2837548bae", "bytes": 330, "note": "Neutral label for the selected IPv6 IoT / RPL composition; not an official logo or endorsement.", "rights": "Original editorial typography using generic sans-serif; no third-party project artwork." }, { "file": "logos/batman-adv.png", "source": "https://www.open-mesh.org/images/logo.png", "sha256": "41ffccf96733288d79dff9bc117688823599165f973735f751ec59ce87074cb2", "bytes": 3148, "note": "B.A.T.M.A.N. project mark used to identify batman-adv. User supplied the original 125 × 50 PNG on 2026-10-14 after identifying this official source URL. Attachment hash verified and image visually inspected; bytes unchanged. Direct retrieval from the source was blocked by Anubis; HTTP provenance was not independently verified.", "rights": "Project mark used for referential identification; no endorsement or trademark license inferred. Logo-specific reuse terms not established." }, { "file": "logos/babel.svg", "source": "https://commons.wikimedia.org/wiki/File:Babel_logo_black.svg", "url": "https://upload.wikimedia.org/wikipedia/commons/8/86/Babel_logo_black.svg", "sha256": "5d5a70d7a5d9e2c18501f2e5b8158b7b465db448bf20111c2f7faa8966b4b83b", "bytes": 28422, "note": "Babel logo, black version, by Err404 (2010), from Wikimedia Commons and used on Wikipedia's Babel protocol article. Original SVG acquired on 2026-10-14; artwork unchanged.", "rights": "Err404 — Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0), as declared on the file page. No endorsement implied.", "license_url": "https://creativecommons.org/licenses/by-sa/3.0/" }, { "file": "logos/libp2p.png", "url": "https://raw.githubusercontent.com/libp2p/website/master/static/img/logo_small.png", "source": "https://github.com/libp2p/website", "note": "Project website asset", "sha256": "b69daaf981821e5d5025d2a780c636ba221ad8aa84e828d5987005721c5ef2aa", "bytes": 3976, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/tor.png", "url": "https://www.torproject.org/static/images/tor-logo@2x.png", "source": "https://www.torproject.org", "note": "Project website asset", "sha256": "bf2f8769c8b582e1b0304dc532a51dcaebbaefdcd220b130ca6ab4bae05a9a74", "bytes": 3693, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/i2p.svg", "url": "https://raw.githubusercontent.com/i2p/i2p.www/master/i2p2www/static/images/i2plogo.svg", "source": "https://github.com/i2p/i2p.www", "note": "Project website asset", "sha256": "1c07c8076b1a921314ef0ba089cb06efc1c4e8299e26c1f7ee3d83e6afa50edb", "bytes": 3360, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/yggdrasil.svg", "url": "https://yggdrasil-network.github.io/assets/images/logo.svg", "source": "https://yggdrasil-network.github.io", "note": "Project website asset", "sha256": "329870708c6d27474bedb2feba0a270be78ee8337d1b060387be82e3f9d2cb35", "bytes": 14477, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/reticulum.png", "url": "https://reticulum.network/gfx/reticulum_logo_512.png", "source": "https://reticulum.network", "note": "Project website asset", "sha256": "035f499a1619cfb6d2da2ca99539e9e9d122bb18addf2ab83d3413592e7662f9", "bytes": 86758, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/nostr.png", "url": "https://raw.githubusercontent.com/mbarulli/nostr-logo/main/PNG/nostr-logo-purple-transparent-928x363.png", "source": "https://github.com/mbarulli/nostr-logo", "note": "Community design by mbarulli, CC0; not a single official Nostr mark", "sha256": "0209e3dc9e700c0e4556e37ab12187a4d5044563bb1b9b1c54d0cc03f1712df0", "bytes": 12697, "rights": "CC0 1.0, https://github.com/mbarulli/nostr-logo/blob/main/LICENSE" }, { "file": "logos/quic.png", "url": "https://avatars.githubusercontent.com/u/22631371?v=4", "source": "https://github.com/quicwg", "note": "QUIC working-group avatar; represents the QUIC family, not a separate Multipath logo", "sha256": "9dd3578b7114737c70625461bf3013a368910811f7c9adc9efe4a50483120796", "bytes": 20243, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/scion.png", "url": "https://avatars.githubusercontent.com/u/34136243?v=4", "source": "https://github.com/scionproto", "note": "SCION project organization avatar", "sha256": "56a288bf52ee7f5f3b9076835febc9f3fda820ea70737f34406002a9c2aca05d", "bytes": 56974, "rights": "Specific logo license not established; referential identification only, no endorsement implied." }, { "file": "logos/prp.svg", "source": "audiovisual/003-many-contexts/assets/prp-logo-official.svg", "note": "Existing official PRP project asset", "sha256": "b2593dd1313f0cab5845618b624b4817dd88249b1af651051e7a431700bc40a7", "bytes": 29331, "rights": "Existing project asset" }, { "file": "logos/cjdns.svg", "url": "https://prism-break.org/assets/logos/cjdns.svg", "source": "https://prism-break.org/en/projects/cjdns/", "note": "cjdns identifier from PRISM Break catalog; official project authorship not independently established", "rights": "Specific asset license not established", "sha256": "67e08c148d0a928950dae9d772f4cf845396408f6f9de9ec39ffd29bbb4ff45a", "bytes": 2539 }, { "file": "logos/dtn.png", "source": "https://ntrs.nasa.gov/citations/20260000898", "url": "https://ntrs.nasa.gov/api/citations/20260000898/downloads/450_2-DTN-DIG-L6-Preliminary%20Release_3%2020260128.pdf", "note": "NASA DTN family logo; extracted unchanged from embedded image on PDF page 1 using pdfimages; not a BPv7/BPSec certification", "rights": "NASA source; logo-specific reuse terms not established; referential identification only", "sha256": "541f840fdeff503c00f0e1bdf47a7b4c48617c4301db13246ff2f2b3d606c04b", "bytes": 105334 }, { "file": "logos/meshtastic.svg", "source": "https://raw.githubusercontent.com/meshtastic/design/ad551eaac6965ef8e3b7a81728a10c7b0534c66b/logo/svg/Mesh_Logo_Black.svg", "sha256": "f2aa1aa091c8c71f066ac63c2a216ce92d9fb4e7efb640f06cad957dfa27c3e8", "note": "Official Meshtastic project mark from the project design repository; unchanged artwork.", "rights": "Project trademark retained; identification in an independent comparison, no endorsement." }, { "file": "logos/ndn.png", "source": "https://named-data.net/", "url": "https://named-data.net/wp-content/uploads/cropped-20130722_Logo2.png", "sha256": "4611229dc64212dbebdd55141081a8fea36bb88628376eff086963fed2f7446b", "bytes": 12115, "note": "Unmodified header logo retrieved from the official Named Data Networking website on 2026-10-14.", "rights": "Project mark used for referential identification; no endorsement or trademark license inferred." }, { "file": "logos/gnunet.svg", "source": "https://www.gnunet.org/images/gnunet-logo.svg", "sha256": "39c21b52409ebe9b2b09ff5a0b106d458a60a474bbe62e42c17c399340f8570e", "note": "Unmodified project logo from the official GNUnet website.", "rights": "Project mark used to identify the compared project; no endorsement or trademark license inferred." }, { "file": "logos/tailscale-label.svg", "source": "Editorial neutral typographic label", "note": "Tailscale name rendered as an editorial label; not the official project mark.", "rights": "Original editorial SVG; project name identifies the compared stack, without endorsement.", "sha256": "a9d823feab3750a98031ad2417aaf53a120eb227e8ce8fd4f875f1920464db89" }, { "file": "logos/rina-label.svg", "source": "Editorial neutral typographic label", "note": "RINA name rendered as an editorial label; not an official project mark.", "rights": "Original editorial SVG; project name identifies the compared architecture without endorsement.", "sha256": "b3af092c28a8044d7e0598397f0ad284341185eb7deceaeb21b8fb9957af736f" } ] }