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

>
> I've published an analysis of draft-thain-ipv8-00 (Internet Protocol
> Version 8) that I believe warrants community attention,


Respectfully disagree the draft warrants any attention at all.



On Thu, Apr 16, 2026 at 8:42 AM wolfy <wolfy=
[email protected]> wrote:

>
> 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
>
>
>
>
>