Summary

  • RFC 877 standardized a narrow bridge between IP and X.25: one protocol marker, complete datagram packet sequences and room for sites to negotiate facilities.
  • The X.25 circuit was opened on demand and timed out according to local open-circuit cost; it did not track a TCP connection one for one.

Analysis

The circuit had a price before it had a packet

In September 1983, J. T. Korb’s RFC 877 described a way to carry Internet Protocol datagrams over X.25-based public data networks. The opening sentence did not present this as a laboratory curiosity: it said CSNET, the VAN Gateway and other organizations had adopted the standard. That is a claim about named adopters, not a census of every network.

The design had to join two different operating models. IP supplied datagrams; X.25 supplied virtual circuits across a public data network. RFC 877 did not try to make the carrier’s circuit behave like an application conversation. It gave the two sides a small common interface and left important operating choices with the connected sites.

A small marker carried a large boundary

The first octet of the X.25 Call User Data field identified the network protocol. The value 0xCC meant Internet Protocol. Once the call had been identified, each IP datagram was sent as a complete X.25 packet sequence: it began at a packet boundary, and the More bit marked continuation when the datagram needed more than one packet. RFC 877 added no further header to the data packets.

The default size was also explicit but not absolute. Unless the sites negotiated larger X.25 packets, an IP datagram could be no more than 576 octets. The RFC gave 1,024 octets as an example of a larger negotiated size. Window and packet-size facilities could vary by agreement; they were not turned into one universal network profile.

This is the part that had to be common for a receiving interface to identify and reconstruct an IP datagram. The size and window choices could remain local so long as the sites negotiated them.

A TCP session did not reserve a circuit

The circuit’s lifetime followed another clock. RFC 877 says a virtual circuit opened on demand when a datagram arrived for transmission. After inactivity, it could close; the length of that interval depended on the cost of keeping an open circuit. An interface could also close a circuit when it ran out of available circuits. Either site could close one.

The specification then draws its sharpest line: TCP and other protocols above IP do not affect this standard. In particular, the interface does not open one X.25 virtual circuit for each TCP connection. A long-lived TCP connection therefore carried no promise that one carrier circuit would remain dedicated to it. The IP/X.25 adapter managed a network resource; TCP’s connection state lived above that boundary.

The operational consequence was bounded. If a circuit closed or reset while a datagram was being transmitted, RFC 877 says that datagram was lost. It does not quantify how often that happened or say what an application later observed. A transport or application could have its own response, but that is outside this RFC’s evidence.

A recommendation was not a deployment count

The 1984 official protocol status report, RFC 924, listed “Internet Protocol on X.25 Networks” as Recommended and pointed to RFC 877. In that report, Recommended meant hosts were encouraged to implement a protocol; it did not mean every host had done so. Eight years later, RFC 1356 described RFC 877’s method as having wide use and said it replaced the earlier specification to address ambiguities and changed requirements, including datagram and packet size, circuit management and multiprotocol interconnection.

Together, these records show both a bounded beginning and later revision. RFC 877 identifies CSNET and the VAN Gateway as adopters; RFC 924 records a recommendation; RFC 1356 offers a later account of wide use. None supplies a site-by-site deployment count, a tariff schedule or a numeric inactivity timer.

What Note 64 adds as a later lens

Heng Lu’s Note 64 proposes a design discipline: specify the minimum common rules needed for interoperability, then leave future choices with the participants operating the system. Read as an editorial lens, that helps explain RFC 877’s shape. The 0xCC marker and packet boundaries are common; the open-circuit interval and negotiable facilities are not prescribed as one global setting.

That comparison is retrospective. RFC 877 does not cite Note 64, and the note is not evidence of Korb’s intent. The document is notable on its own terms: it made IP recognizable across a public X.25 service without requiring TCP sessions, network tariffs or every negotiable facility to share one lifecycle.

Sources