Skip to content
Tech HistoryDeep Dive Published Updated 5 min readViews unavailable

From IPng to IPv6: How the Internet's Next Protocol Became a Standard

Trace the open IETF IPng selection process from address-growth concerns through RFC 1883, RFC 2460, and today's RFC 8200.

IPv6 is often introduced as “IPv4 with more addresses,” but the standards record tells a richer story. In the early 1990s, the IETF had to choose a successor protocol under pressure from address-space projections, routing scalability concerns, and the practical requirement that a global network could not be upgraded all at once. The chosen design was not simply announced by a vendor or invented in one RFC; it emerged from an open proposal and criteria process, then evolved through several generations of technical specifications.

Reading that lineage is useful for a practical reason: an RFC’s publication date does not tell you whether its rules are current. IPv6 specifications have been obsoleted and refined, and engineers who cite the first RFC they find can unknowingly implement an old version of the protocol.

The IPng decision was a process

The IETF began evaluating a successor to IPv4 in the early 1990s. Multiple proposals explored larger addresses and new functionality. The IPng work formed an area and directorate to publish decision criteria, evaluate candidates, and recommend a path. RFC 1726 captured technical criteria such as scale, transition, media independence, routing flexibility, operational robustness, extensibility, and access to standards.

In January 1995, RFC 1752 documented the IPng Area Directors’ recommendation. It selected the revised 128-bit version of Simple Internet Protocol Plus (SIPP) as the basis for IPng and recommended forming a working group to finish the protocol suite. The important historical detail is that the choice was tied to stated requirements and an explicit standards process; it was not just a contest for the largest address field.

RFC 1752 also makes the transition problem visible. The Internet already depended on heterogeneous routers, hosts, and applications. A successor had to coexist with IPv4 through operational transition mechanisms. Compatibility and deployment strategy were part of the design constraint from the beginning, not details added after the packet format was complete.

The first IPv6 specification

RFC 1883, published in December 1995, specified Internet Protocol version 6. Its introduction grouped the redesign around expanded addressing, a simplified header, more extensible options, flow labeling, authentication, and privacy support. The 128-bit address size addressed scale, while the header and extension model attempted to make common forwarding more efficient and future protocol evolution less rigid.

The RFC series then expanded beyond one base specification. Addressing architecture, Neighbor Discovery, ICMPv6, DNS records, and link-layer mappings each received their own documents. That division is a reminder that “IPv6 support” is not a single code path: a functioning deployment depends on related control protocols and operational behavior as well as the base header.

Why two later RFCs matter

RFC 2460 replaced RFC 1883 in December 1998. It revised the specification as implementations and working-group experience exposed details that needed clarification. Its status in the RFC record changed over time, and it was itself updated by several later documents.

In July 2017, RFC 8200 obsoleted RFC 2460 and became the current IPv6 base specification. Its change history records the updates and errata it incorporated. An engineer reading an old RFC should follow its “Obsoleted by” and “Updated by” relationships in the Datatracker before treating its text as the active standard.

The chain is therefore:

RFC 1752 (1995): recommendation and IPng selection process
        |
RFC 1883 (1995): first IPv6 base specification
        |
RFC 2460 (1998): revised base specification
        |
RFC 8200 (2017): current base specification, obsoleting RFC 2460

This is a standards lineage, not a claim that every IPv6 mechanism stayed unchanged. Specific behaviors may be defined or updated by separate RFCs, and implementers must follow the current normative references for the feature they are building.

The deployment story remained longer than the design cycle

IPv6 has a much larger address field than IPv4, but the existence of a standard did not instantly replace the installed network. Dual-stack systems, tunnels, translation, DNS, router support, firewalls, and application assumptions all affected adoption. That long coexistence helps explain why IPv6 engineering is as much about operational completeness as address notation.

An IPv6-capable host can still fail in several distinct ways: it may have an address but no usable route, resolve AAAA records while outbound policy blocks IPv6, or expose a service on IPv4 but not IPv6. These are deployment questions rather than contradictions in the protocol history. A standards document defines behavior; network operators must still implement and test the path.

How to cite the standard accurately

For historical context, RFC 1752 explains why the IETF selected an IPng direction. For the original protocol design, RFC 1883 is a primary source but is obsolete. RFC 2460 is an intermediate specification and is also obsolete. RFC 8200 is the current base specification in the RFC record as of this article’s review date.

When writing implementation guidance, cite the current RFC and any relevant updates rather than using historical text as normative instructions. When writing history, retain the older RFCs because their “obsoleted by” relationships are evidence of how the protocol evolved. Keeping those two citation purposes separate prevents a historical milestone from being mistaken for the current engineering requirement.

Related:

Sources:

Comments