Summary

  • The IPng review did not simply crown an unchanged SIPP proposal. Operational objections to its transition plan and disagreement over 64-bit addressing prompted a substantial revision.
  • RFC 1752 recommended revised, fixed 128-bit SIPP as the basis for IPng. It records a majority compromise on address length, not unanimity, immediate standardization, or proof that IPv6 deployment was inevitable.

The winner was still a draft that could be changed

A protocol-selection story often gets told backward. Once a successor has a familiar name and a successful history, the earlier candidates can look like a parade leading to the obvious choice. The record in RFC 1752 is less tidy. The Internet Engineering Task Force began looking for an IPv4 successor in late 1990; it formed an IPng Area in late 1993 to compare proposals against technical criteria. The area examined CATNIP, SIPP and TUBA. Its recommendation says all three had shortcomings. CATNIP was too incomplete; SIPP and TUBA each appeared workable in some respects but needed repairs. RFC 1752, §§1, 7–8

SIPP had already emerged from mergers among earlier efforts. Its appeal was not mysterious: it kept a recognizable IP architecture, altered the header, and proposed more address space without requiring a wholesale replacement of the transport protocols above it. But the 1993 white paper described a 64-bit address, with a mechanism for extending addresses through routing options. That was a design proposition, not yet the 128-bit IPv6 familiar today. RFC 1710

The review found two different kinds of trouble. The first concerned transition. SIPP’s IPAE plan tried to bridge IPv4 and the new protocol, but reviewers judged its complexity and operational reliability harshly. RFC 1752 records the prevailing view that IPAE could not be made to work reliably in an operational Internet. The second issue was less categorical: reviewers disagreed about whether 64 bits could support the hierarchy and routing inefficiency of a future global network. Many believed it could not. Some also questioned using extended addressing and loose source routing to compensate for the smaller base address. RFC 1752, §8.2

That distinction matters. The record does not show that everyone agreed the 64-bit proposal was technically impossible. It shows that reviewers were being asked to commit a long-lived global protocol to assumptions they could not confidently validate—and that the proposed extension mechanism made some of them uncomfortable. The question was not only “How many addresses fit?” but “How much structure can the architecture preserve without asking routers and operators to rely on an unfamiliar escape hatch?”

The retreat turned objections into design work

After a two-day IPng retreat near Chicago on 19–20 May 1994, SIPP co-chairs Steve Deering and Paul Francis proposed changes. The core move was direct: replace eight-byte addresses with fixed sixteen-byte ones. They also proposed optional serverless autoconfiguration using an IEEE 802 address in the low-order part, use of all sixteen bytes in higher-layer connection identifiers, and dropping the Route Header as a way to extend addressing. RFC 1752, §9

The revision was more than adding another eight bytes. It changed which future costs the protocol would carry. A fixed length made packets and implementations easier to reason about than a variable-size scheme, while the additional space gave the design more room for hierarchy and internal network structure. It also moved away from relying on source-routing machinery to make a smaller address space stretch. Those benefits came with a cost: larger addresses occupy more bits in headers and state, which is particularly visible on constrained links and in systems that process packets at scale.

RFC 1752’s later discussion of address length preserves that counterargument rather than pretending the choice was cost-free.

The new proposal also was not an isolated SIPP package. The recommendation describes a synthesis: the basic protocol came largely from SIPP; autoconfiguration and transition drew influence from TUBA; the addressing structure reflected CIDR work; and the routing header evolved from SDRP deliberations. The IPng decision therefore selected a revised direction while incorporating work from other efforts. RFC 1752, §9

A recommendation is a boundary, not a deployment date

RFC 1752 says the address-length debate did not reach unanimity. It reports a clear majority for fixed sixteen-byte addresses as the best compromise among efficiency, functionality, flexibility and global applicability. That is a carefully bounded conclusion: a majority view among the IPng process participants, as recorded by the recommendation’s authors. It is not a referendum of every network operator, and the document supplies no vote count that would justify calling it unanimous. RFC 1752, §10.2

In January 1995, the IPng Area Directors recommended the 128-bit SIPP specification as the basis for IPng and urged the IETF to concentrate its work on one effort. The wording matters: “basis for” points to a program of standards work, not a finished protocol already deployed across the Internet. RFC 1883, published in December 1995 as the IPv6 specification, marks a later step in that process. RFC 1752, §11 RFC 1883

This is also where the earlier RFC 1550 story ends and this one begins. RFC 1550 solicited requirements before candidate evaluation; it asked what future users would need. The SIPP revision concerns a later question: when a candidate had been examined against criteria, which objections were serious enough to change its architecture? Keeping those phases separate prevents one article from absorbing the whole selection process. RFC 1550

What the record can—and cannot—say about incentives

A design choice that adds address space also redistributes future operating conditions: it affects routing plans, device requirements, address administration and the cost of coexistence with IPv4. A technical recommendation cannot, by itself, settle who benefits from those later conditions. Nor can the 1995 RFC establish what incentives its participants privately held.

A 2026 note by Heng Lu interprets IPv6 promotion through the later political economy of address scarcity, registry authority and equipment markets. That is a relevant challenge to claims that IPv6 was a neutral inevitability, but it is a later argument, not evidence of the motives behind the 1994 SIPP revision. The contemporaneous RFC records engineering concerns, an open disagreement about address length, and the rationale for a majority compromise. The historical account should keep those kinds of evidence distinct. Heng Lu, “Why IPv6 Was Pushed, and Who It Actually Serves”

The useful lesson is narrower than either triumphalism or a claim of hidden coordination. IPng review changed the candidate. It converted doubts about routing hierarchy and transition feasibility into explicit design changes, then made a recommendation under disagreement. That process did not prove that sixteen bytes would be cheaper for every operator, or that deployment would follow smoothly. It did give the next standards phase a defined architecture—and left later institutions and operators to bear the consequences.

Sources