C06-I2: Yes
Rationale
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.
Assessment method
Primary specification and pinned code review; no runtime experiment
Source context
I2P tunnel processing and GNUnet 0.20.0 CADET forwarding
Outstanding 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.
Public sources
- https://i2p.net/en/docs/specs/tunnel-implementation/
- https://i2p.net/en/docs/overview/tunnel-routing/
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round502.html
- round502-sources.json