Summary

  • RFC 1287 is a December 1991 Informational RFC. It reports IAB/IESG architectural discussions, identifies four assumptions for the next five to ten years and names five areas for possible architectural evolution: routing/addressing, multi-protocol architecture, security, traffic control/state and advanced applications.
  • The RFC makes plans and disagreements inspectable. It discusses aggregation, address-format choices, migration, partial connectivity and application interoperability, yet it does not specify an Internet standard or prove that one proposal was adopted, deployed, reachable, authorized or successful.

An architecture agenda was not an architecture selection

The title of RFC 1287 reaches toward the future, but its status paragraph keeps its jurisdiction narrow. The document discusses important directions for possible evolution and suggests steps toward desired goals. It was offered to the community for discussion and comment. It provides information; it does not specify an Internet standard.

That distinction is not ceremonial. A standard can define a common technical obligation. A deployed system can show that particular parties built and operated something. A measurement can describe an observed condition. RFC 1287 does something different. It records how a group of architects framed problems, which assumptions they could share at that moment, where they saw research and engineering work, and which choices remained unresolved. The record is historically powerful precisely because its limits are visible.

The setting mattered. The RFC describes growing strain on the existing architecture and a January 1991 joint IAB/IESG discussion. A later June Architecture Retreat brought together IAB, IESG, IRSG members and guests; reports from its working groups were assembled into the document and presented at an IETF meeting. That sequence tells us that deliberation occurred. It does not make the retreat a protocol-selection ceremony, and it does not make every sentence in its report a decision carried into the network.

Consensus assumptions were a planning frame, not a forecast contract

The January discussion reached four basic assumptions about the following five to ten years. TCP/IP and OSI would coexist for a long time. The Internet would include diverse networks and services rather than one network technology. Commercial and private networks would join the picture without an expectation that common carriers would supply the entire service. And the architecture needed to be capable of scaling to 10**9 networks.

The fourth item is often the easiest to misread. RFC 1287 calls the exponent fuzzy and says estimates varied from 7 to 10. Its claim is not that the Internet had reached that scale, would definitely reach precisely that scale, or had solved the engineering problem. The group used a deliberately severe planning case to test whether a future architecture could cope. A planning bound is a reason to investigate; it is not an observation, a prediction guarantee or a deployment target already met.

The same is true of coexistence. Saying TCP/IP and OSI would both remain relevant did not declare that every network could interoperate, that every application had a gateway, or that every user could cross a protocol boundary. It made heterogeneity an architectural condition to confront rather than a fact to hide.

Five priorities organized work without completing it

RFC 1287 names routing and addressing as the most urgent problem, then lists multi-protocol architecture, security architecture, traffic control and state, and advanced applications. This is an agenda, not a finished design. Within routing, the document discusses address aggregation through Autonomous Systems or Administrative Domains, special routes, address-space choices and a migration path that may require header rewriting and state in conversion elements.

It is unusually direct about what had not been settled. There was not full agreement on how Administrative Domains should aggregate or how routing protocols should be organized around aggregation boundaries. The document proposes building estimates and a development/deployment timeline, exploring address formats and prototype mapping gateways, and studying routing on aggregates. To propose a timeline or a prototype is to announce work still needed. It cannot retrospectively certify the chosen format, the exact migration, a route table, or the result of any experiment.

This is where an old architectural report is most useful to a later reader. It can show that a problem was recognized, that certain levers were being considered, and that uncertainty was expressly preserved. It cannot skip the intervening evidence needed to show what was standardized, implemented, operated or experienced by users.

Coexistence was not the same thing as interoperability

The multi-protocol section makes the boundary even sharper. Rather than prescribing a predetermined multi-protocol Internet, RFC 1287 proposes a process-oriented model. It asks how the Internet should be defined, how multiple suites might be accommodated, whether partial or filtered connectivity belongs in the architecture, and how application gateways should be treated.

Its three-part account separates a TCP/IP core from link sharing and application interoperability. Link sharing lets different protocol suites share physical resources while remaining non-interacting — the document calls this “ships in the night.” Application relays or user agents may carry essential semantics across otherwise disjoint communities. But the RFC also says these additions introduce complexity and cost and usually involve a loss of functionality.

Those are carefully bounded propositions. Shared media is not an end-to-end connection. An application relay is not proof that every function survives translation. A name-based or directory-based organizing concept is not a proof of reachable service, permitted access or successful human use. The report gives a vocabulary for studying partial connectivity; it does not erase the intermediate technical and institutional stages.

A proposal could make responsibility visible without assigning it

The document’s suggested actions distribute work among research, engineering and IETF processes. That is a control surface: estimates, format exploration, routing aggregation, policy complexity and gateway state can each be examined by an appropriate group. Yet the existence of a proposed action does not answer who later approved a design, who bore deployment cost, which operator implemented it, or whether a particular network delivered the intended service.

RFC 1287 therefore belongs in Internet history as an argument for keeping stages separate. A community can name pressure, make assumptions explicit and decide where to look next. That is already consequential. It is not the same as completing the engineering, settling authority, or proving the world after the discussion matched the world the report imagined.

Sources and evidence limits

This article uses RFC 1287 — Towards the Future Internet Architecture. It supports the RFC’s Informational status, 1991 IAB/IESG discussions, four planning assumptions, five work areas, routing/addressing proposals and disagreement, process-oriented multi-protocol model, coexistence/interoperability distinction and suggested actions. It does not establish a selected successor architecture, a standard, deployment, present Internet condition, route, address allocation, current authorization, reachable service or user-visible outcome.