IPv8 - historical and contemporary proposals. From RFC 1621 (Pip) to draft-thain-ipv8
IPv8 - two protocol proposals under the same name. The historical Pip (RFC 1621, 1994) and the contemporary draft-thain-ipv8-00 (2026). What they propose and why.
In the IANA “Internet Protocol Version Numbers” registry, number 8 has been assigned twice in the history of the Internet - once formally and once in a new proposal. Each of these attempts tried to solve a different problem: the first, a mid-1990s competition for an IPv4 successor; the second, the current debate about the future path of addressing, initiated in April 2026.
This article describes both proposals, places them in the context of the IETF standardisation process, and compares them with the alternatives. There is currently no officially approved “IPv8” standard - the version number in the IANA registry remains “Unassigned” (the previous assignment was withdrawn).
IP numbering - where do the sequence gaps come from
The IANA IP Version Numbers registry contains the following assignments:
| Version | Status | Protocol | RFC |
|---|---|---|---|
| 0 | Reserved | - | - |
| 1-3 | Unassigned | - | - |
| 4 | Standard | IPv4 | RFC 791 |
| 5 | Deprecated | Stream Protocol (ST, ST-II) | RFC 1819 |
| 6 | Standard | IPv6 | RFC 8200 |
| 7 | Historic | TP/IX “The Next Internet” | RFC 1475 |
| 8 | Historic / Unassigned | Pip (historical), draft-thain-ipv8 (current) | RFC 1621 |
| 9 | Historic | TUBA + RFC 1606 (April Fools) | RFC 1347, RFC 1606 |
| 10-15 | Unassigned | - | - |
The jump from IPv4 to IPv6 in the official line comes from the fact that number 5 was already taken by the experimental ST Protocol, and numbers 7, 8 and 9 were assigned to competing proposals in the IPng (IP Next Generation) process of the first half of the 1990s.
IPv8 in 1994 - Pip Near-term Architecture
Context
In the early 1990s the IAB (Internet Architecture Board) concluded that IPv4 would be exhausted in the foreseeable future. In 1992 the IPng process was announced - a competition for a successor. Several proposals were submitted:
- CATNIP (Common Architecture for Next Generation IP) - integration of IP, CLNP and IPX
- SIP (Simple Internet Protocol) - a minimalistic extension of IPv4 addressing
- Pip (P Internet Protocol) - hierarchical, provider-oriented addressing
- TUBA (TCP and UDP with Bigger Addresses) - using ISO CLNP as the network layer
Each proposal received the IP version number it would have taken after approval:
- TP/IX -> IPv7
- Pip -> IPv8
- TUBA -> IPv9
Pip specification
Pip was developed by Paul Francis at Bellcore (later Telcordia) during 1992-1993. The specification appeared as RFC 1621 “Pip Near-term Architecture” in May 1994 (status: Informational / Historic).
Key Pip design principles:
| Feature | Description |
|---|---|
| Identifier size (Pip ID) | 64 bits - host or process identifier |
| Address | Hierarchical, provider-rooted |
| Header | Split into Initial Part, Transit Part (routing), Options Part |
| Source routing | Built-in mechanism - Forwarding Table Index Fields (FTIF) |
| Separation of ID from routing | Separate Pip ID (identity) and Pip Address (location) |
| Multicast | Class D unicast, CBT (Core-Based Trees), anycast |
The key innovation was separating the host identifier from its routing address - an idea that returned in subsequent decades in protocols such as LISP (Locator/ID Separation Protocol) and HIP (Host Identity Protocol).
Why Pip disappeared
In mid-1993 the IAB consolidated the proposals. Pip and SIP were merged into SIPP (SIP Plus). SIPP, through further modifications, became the foundation of IPv6 - RFC 1883 (1995), RFC 2460 (1998), and now RFC 8200 (2017).
General principles made it from Pip to IPv6 (a 128-bit address, larger than Pip’s proposed 64 bits; hierarchical provider addressing), but specific solutions did not - FTIF source routing, Pip ID as a separate identifier, the header structure with a Transit Part. RFC 1621 itself comments: “the major aspects of Pip…were preserved, many of the ideas…were not”.
Status: Historic. Version number 8 in the IANA registry was returned to “unassigned” once the IPng process ended with the selection of IPv6.
IPv8 in 2026 - draft-thain-ipv8-00
Context
In April 2026 Jamie Thain (One Limited) published an Internet-Draft titled “Internet Protocol Version 8 (IPv8)”. The document has Internet-Draft status (not RFC - these are two different IETF statuses) and expires after six months unless refreshed.
The proposal appears in a context where IPv6 has reached around 45-48% of global traffic adoption per Google statistics, but full deployment remains slow. The author proposes an alternative path of IPv4 evolution instead of migration to IPv6.
draft-thain-ipv8-00 specification
| Feature | Description |
|---|---|
| Address length | 64 bits (32-bit ASN routing prefix + 32-bit host address) |
| Notation format | ”r.r.r.r.n.n.n.n” - dotted decimal notation |
| IPv4 compatibility | ”IPv4 is a proper subset of IPv8” - an IPv8 address with prefix = 0 is an IPv4 address |
| Header size | IPv4 header + additional 8 bytes (extended addresses) |
| Internal networks | Reserved prefix 127.x.x.x for internal zones |
| Peering | Prefix 100.0.0.0/8 for inter-ASN peering |
| Management services | ”Zone Server” consolidating DHCP8, DNS8, NTP8, authentication |
| Routing table constraint | /16 minimum prefix - bounds the global routing table to roughly one entry per ASN |
| DNS | New record type A8 |
| Migration | No forced change - IPv4 devices and applications work without modification |
Community reactions
The draft met with substantial criticism from the technical community. The main objections:
- The “IPv4 as a subset” claim - mathematically true (an address with prefix 0 is possible), but in practice it requires changes in host network stacks to support 64-bit addresses
- Duplication of IPv6 mechanisms - the proposal resembles solutions IPv6 already provides, without justifying a second parallel standard
- Service consolidation (Zone Server) - DHCP/DNS/NTP/auth in a single management layer violates separation of responsibilities
- Prefix 127.x.x.x - collides with its existing use as loopback
- Single-author draft - in IETF tradition, serious proposals are backed by a working group; a single-author draft from a small company has low standardisation odds
Current status
An Internet-Draft without refresh expires after six months. draft-thain-ipv8-00 is an informational document - it does not commit the IETF to anything. For the proposal to become an RFC it would have to:
- Be adopted by a Working Group
- Go through the IETF consensus process
- Gain IESG (Internet Engineering Steering Group) approval
- Be published by the RFC Editor
Most Internet-Drafts never even reach the first step.
TIP
The difference between an Internet-Draft and an RFC is crucial. An Internet-Draft is a working document - anyone can publish one, it is not subject to formal consensus, and it expires after 6 months. An RFC is an approved IETF document - it passes review and consensus and becomes a permanent, referenceable document. A strictly-speaking “IPv8 RFC” does not exist today.
Relevance for a network engineer
Neither IPv8 proposal - historical nor current - has any practical deployment today. For a security engineer, familiarity with the topic has three uses:
Beware of Chinese “IPv9” - unrelated to the IETF. In 2004 a “Decimal Network” system called “IPv9”, with 256-bit decimal addresses, was proposed in China. The project was never deployed beyond limited academic experiments and is unrelated to RFC 1347.
Beware of “IPv8” in another context - there is a TU Delft IPv8 project (jwik.me/ipv8), an overlay network for decentralised applications (blockchain, Tribler, Trustchain). It is not a layer 3 protocol - it is a Python library running over UDP. The name is misleading, but the project is academically legitimate.
History teaches humility - Pip, SIP, TUBA, CATNIP, TP/IX - all these proposals had technical merit and partial community support. The choice of IPv6 was a process decision, not a purely technical victory. Further “IPv6 successor” proposals will most likely appear in the decades ahead.
Summary
IPv8 does not exist as a standard. The name has appeared twice in IETF history - in the 1990s as Pip (RFC 1621, Historic status) and in 2026 as a single-author draft (draft-thain-ipv8-00, Internet-Draft status). For productive network engineering work, layer 3 protocols remain IPv4 and IPv6.
Related articles: IPv4 (RFC 791), IPv6 (RFC 8200).
Sources
- RFC 1621 - Pip Near-term Architecture - historical Pip specification
- draft-thain-ipv8-00 - Internet Protocol Version 8 (IPv8) - current Internet-Draft
- IANA IP Version Numbers Registry - official registry of assigned version numbers
- RFC 1752 - The Recommendation for the IP Next Generation Protocol - IPng recommendation that chose IPv6
- RFC 1475 - TP/IX: The Next Internet - competing proposal (historical IPv7)
- RFC 1347 - TCP and UDP with Bigger Addresses (TUBA) - TUBA (historical IPv9)
- RFC 1606 - A Historical Perspective On The Usage Of IP Version 9 - April Fools RFC from 1994
- ARIN - Other IP Version Numbers - historical background
Need help in this area?
Our experts will help you assess the risk and plan next steps.