IPv8 Hacker News Discussion
The IPv8 draft was discussed on Hacker News in the thread Internet Protocol Version 8 (IPv8). At the time reviewed for this wiki, the thread was flagged and showed 125 points with 107 comments.
This page summarizes the discussion as community reaction, not as a formal technical review.
Overall Tone
Section titled “Overall Tone”The dominant reaction was skeptical. Many commenters treated the draft as unserious, joke-like, or possibly assisted by an LLM. A recurring point was that anyone can publish an Internet-Draft, so the document should not be read as IETF endorsement.
There were also a few more charitable comments. Some readers thought the IPv4-like 64-bit address notation was easier to discuss than IPv6 notation, and one commenter said the proposal looked workable at first glance except for mandatory NIC-enforced security. Others argued that the draft should be judged on its contents rather than on the author’s location or the fact that it is only an Internet-Draft.
Main Technical Criticism
Section titled “Main Technical Criticism”| Topic | Summary of comments |
|---|---|
| Internet-Draft status | Several commenters emphasized that Internet-Drafts can be submitted by anyone and have no formal IETF standing. |
| OAuth at L3 | Many readers objected to putting OAuth2/JWT concepts into an IP-layer proposal. They questioned trust establishment, bootstrap behavior, and whether authentication belongs at this layer. |
| Backward compatibility | A detailed critique argued that a new IP version field and different wire format cannot be fully backward compatible with existing IPv4 routers, NICs, host stacks, and firewalls. |
| New required machinery | Commenters noted that the draft depends on many new pieces: AF_INET8, A8, ARP8, ICMPv8, BGP8, OSPF8, IS-IS8, certified NIC firmware, Zone Servers, and companion drafts. |
| Version-number history | One commenter pointed to historical use of IP version 8 by PIP and noted that IPv9 had also appeared in earlier proposals. |
| ASN-based addressing | Critics argued that binding routing prefixes to ASNs conflates identity, topology, and location, and could make multihoming and provider changes harder. |
| Cost Factor | Some commenters objected to cross-AS path metrics because independent ASes generally do not trust each other’s internal or policy metrics. |
| Zone Server centralization | The Zone Server was described by critics as combining too many unrelated functions into one highly trusted control point. |
| PVRST mandate | A commenter objected to requiring a Cisco-associated spanning tree variant in a Standards Track draft. |
| Local networking | The draft’s east-west isolation language led some readers to ask how ordinary local workflows, such as printing or network drives, would work. |
Policy And Privacy Concerns
Section titled “Policy And Privacy Concerns”Several comments framed IPv8 as friendly to surveillance or censorship because the draft emphasizes authentication, DNS-dependent egress, route validation, and centralized policy enforcement. These comments were often speculative, but they show that readers viewed identity and access-control features as politically sensitive, not only technical.
More Constructive Threads
Section titled “More Constructive Threads”Some parts of the discussion compared IPv8 to IPv6 adoption problems:
- A few readers liked the idea of a larger address space with a familiar dotted notation.
- Others said 8to4-like tunneling is not new, because IPv6 already had 6to4-style transition mechanisms.
- Several comments noted that IPv6 does not require changes to IPv4-only devices either, but those devices still cannot directly reach IPv6-only hosts.
- Some readers argued that address memorability is not the real IPv6 issue because DNS and address management should handle most use cases.
Neutral Takeaway
Section titled “Neutral Takeaway”The HN discussion is useful mainly as an early public reaction map. It highlights the areas most likely to attract technical scrutiny:
- Whether the compatibility claims match the proposed wire format.
- Whether authentication and policy belong in the network layer.
- Whether the Zone Server design creates too much operational concentration.
- Whether ASN-based addressing fits existing routing economics and multihoming practice.
- Whether the proposal can separate a simple address-space idea from a much broader management architecture.
For the primary source text, read Original Draft -02.