Privacy and Safety Concerns: draft-thain-ipv8-00 (IPv8)

wolfy <[email protected]> Thu, 16 Apr 2026 15:32:16 +0000

Newsgroups	gmane.ietf.general
Message-ID	<Y8fAEzuj9epGKqhjOcXLJokbYsdKFtQZbl-vJooC9u9KY97_1h_CjV8baOExpi0LacsNnLhpLLX4kau5cHxObmFNckKopLt99Lpneo8S08o=@shitwolfymakes.com>

Hello,

I've published an analysis of draft-thain-ipv8-00 (Internet Protocol Version 8) that I believe warrants community attention, particularly regarding the draft's compliance with RFC 7258 and RFC 6973.

Full analysis: https://shitwolfymakes.substack.com/p/we-need-to-talk-about-the-ipv8-draft

The short version: the draft contains genuinely good ideas (the backward compatibility model, Cost Factor routing metric, and internal zone prefix architecture are all sound contributions), but the mandatory management layer introduces surveillance and safety-critical concerns that are not addressed anywhere in the specification.

The key issues:

1. RFC 7258 compliance. The IETF declared pervasive monitoring an attack. IPv8 makes pervasive monitoring the default architecture. OAuth8 hardware identity binding, mandatory NetLog8 telemetry, DNS8 egress validation, and centralized Zone Server control create a comprehensive, identity-correlated surveillance capability at every network scale. The Security Considerations section (§18) contains no privacy analysis.

2. RFC 6973 compliance. The draft has no privacy considerations. No discussion of data minimization, identifier unlinkability, user consent, or data retention. The protocol mandates MUST-level data collection (NetLog8, OAuth8, DNS8 logging) without addressing storage, retention, lifecycle, or legal compliance obligations.

3. Safety-critical system incompatibility. NIC firmware rate limits (§17.5) enforce a fail-closed architecture: 10 pps unauthenticated, 100 pps authenticated, with the Zone Server as sole authority for elevation. This introduces non-deterministic dependencies incompatible with RTOS certification under DO-178C, IEC 62304, and ISO 26262. The draft makes no exception for safety-critical systems, no priority class, no fail-open mode.

4. Censorship architecture at every scale. The DNS8 + WHOIS8 egress validation mechanism (§1.4) that blocks malware C2 channels is structurally identical to a censorship gate. The draft specifies home routers can operate as local OAuth2 authorities (§1.3), meaning the same surveillance and control toolkit deploys from national ISPs down to individual households, with no architectural constraint on operator intent.

5. Circumvention tool breakage. Tor, I2P, and all IP-literal connection tools are broken by design (not policy) by the DNS8 requirement. No DNS lookup = no XLATE8 state table entry = connection blocked.

The addressing and routing contributions in this draft are worth preserving. The management layer, as specified, is not. I'd welcome discussion on whether these concerns can be resolved within the current architecture or whether the management layer needs fundamental redesign.

V/r,
wolfy

publickey - [email protected] - 0x55F74778.asc (application/pgp-keys, 1.7 KB)

signature.asc (application/pgp-signature, 603 B)