Summary

  • RFC 1613 required a separate TCP connection for every X.25 virtual circuit. The enclosed Logical Channel Number was arbitrary on XOT and could not distinguish two same-numbered calls arriving on different streams.
  • The XOT layer had to pass stream identity to the X.25 engine, which then selected the channel number appropriate to the outgoing local interface. Circuit identity was therefore a mapping across interfaces, not a portable property of one header field.
  • Explicit flow-control facilities, locally scoped packet types and a separate PVC setup exchange show the same discipline: preserve only the state that can cross the boundary, and verify local compatibility where the next action occurs.

Two calls, one visible number

Imagine a gateway receiving two X.25 calls. One arrives from device A, the other from device B. Both X.25 headers display the same Logical Channel Number. An implementation that indexes calls only by that number sees a collision. It may attach a packet to the wrong state machine, clear the wrong call or make two independent conversations appear to be one.

The number is not malformed. Each sender may have used it correctly on its own interface. The mistake occurs at the receiving gateway, where local values from two different interfaces have been put into one namespace.

That is the concrete example in RFC 1613, cisco Systems X.25 over TCP (XOT). The RFC Editor record dates it to May 1994 and classifies it as Informational. The status notice is explicit: the memo provides information to the Internet community and does not specify an Internet standard. It documents a method, not a universal mandate or a deployment census.

The design's answer was equally explicit. A separate TCP connection had to be used for each X.25 virtual circuit. The Logical Channel Number inside the X.25 header had no significance on the XOT connection and could contain arbitrary values. When the RFC's devices A and B both called device C with the same number, C's X.25 engine had to know that the packets came from different logical XOT interfaces. The LCN could not supply that fact. The XOT layer had to communicate stream identification to the X.25 layer.

The narrow lesson is stronger than “use a bigger key.” It says that a local identifier acquires meaning from the interface and state machine in which it is interpreted. Copying the bits does not export that context.

The stream carried the missing namespace

XOT established the TCP connection before establishing the X.25 virtual circuit. It required connections to TCP port 1998 and prohibited XOT data in the TCP SYN. The current IANA service-name and port-number registry lists x25-svc-port on 1998 for TCP and UDP. That registry is a coordination record, not an observation of an open service. RFC 1613 itself defines the method over TCP.

One TCP connection per virtual circuit made the stream part of the lookup key. The TCP endpoints and connection lifetime separated traffic that an inner LCN could not. But the stream was not, by itself, an authenticated customer, an authorized call or a completed application exchange. It supplied a technical namespace and carrier state. Local policy and X.25 state still had work to do.

TCP also supplied an ordered octet stream rather than X.25 packet boundaries. The historical RFC 793 describes that stream service. RFC 1613 inserted a four-byte XOT header: a 16-bit Version followed by a 16-bit X.25-packet Length. Version had to be zero; a different value or an illegal packet length required the TCP connection to close.

This framing is necessary context, but it is not the story's new mechanism. RFC 1006 had already used a different four-octet header to recover TPDU records over TCP, and BTW has covered that boundary separately. Here the complete packet can be perfectly framed and still be attached to the wrong circuit if the implementation discards its stream/interface context.

The outgoing interface wrote its own number

When an XOT implementation received an X.25 packet from TCP and sent it through a local X.25 interface, RFC 1613 required it to set the Logical Channel Number used on that outgoing interface. That rule is an unusually clear rebuke to field-as-identity thinking. The number can change at the handoff while the intended virtual circuit continues.

A defensible receipt therefore joins at least four facts: which TCP connection delivered the framed packet; which logical XOT interface the implementation assigned to that stream; which incoming LCN appeared in the enclosed header; and which local LCN was selected for the outgoing interface. A log that preserves only the inner number is precise-looking but ambiguous. A log that preserves only TCP endpoints misses the local X.25 allocation. A green “forwarded” flag proves neither the mapping nor the result beyond the next boundary.

This is where running code matters. Heng Lu's Running-Code Primacy places weight on locally verifiable execution rather than symbolic authority. In this case the claim can be narrow and testable: this implementation, at this time, mapped a complete packet from this stream and logical interface to this outgoing channel state. The RFC supplies the interoperability rule. Configuration, state transitions and packet observations supply the instance.

Defaults stopped at the internetwork edge

The same boundary appears in call setup. Ordinary X.25 networks could have default packet and window sizes. RFC 1613's authors judged that diverse sites connected through a TCP/IP network could not safely assume one common network default. Every Call therefore had to state Packet Size and Window Size facilities explicitly.

If a received Call omitted one of them, acceptance remained a local matter. An implementation that accepted the Call had to put the effective value in Call Confirm. This was not vagueness. It divided responsibility: the exchange carried the minimum facts needed for interoperability, while the local system decided whether its own limits permitted the call.

Flow control could also be end to end or local. A local implementation might fragment or combine data packets and maintain different packet sequence numbers at the two interfaces. Mixed modulo-128 and modulo-8 operation required translation; a window too large for the modulo-8 side had to be reduced or the connection refused. An RNR sent across TCP could not be assumed to stop DATA travelling in the other direction.

The evidence consequence is important. “TCP is reliable” does not settle X.25 window agreement, packet-number translation, receiver readiness or application completion. Each is a different state owned by a different layer.

Some packet meanings could travel; others had to stop

RFC 1613 retained the end-to-end nature of Interrupt and Reset, so those packets and their confirmations crossed the TCP connection. Restart, DTE Reject, Diagnostic and Registration packets had only local DTE/DCE-interface significance. They were not to cross XOT; if received from TCP, they were silently discarded.

Encapsulation did not make every inner control message portable. The implementation needed a classification rule for which meaning survived the new boundary. That distinction is more valuable operationally than a generic promise to “tunnel X.25 transparently.” Transparency was conditional.

Permanent virtual circuits made the limit even clearer. An X.25 PVC normally existed because a network provider had provisioned it; there were no Call and Clear packets to negotiate it dynamically. XOT therefore needed a non-standard PVC setup exchange immediately after TCP establishment. The message carried interface names, local LCNs and flow-control values so the responder could test whether both configurations matched.

The status space distinguished a missing or down interface, a non-X.25 interface, a nonexistent PVC, configuration mismatch, incompatible flow control and setup-protocol error. Success status zero was followed by a Reset on each local interface. Closing TCP broke the XOT PVC. If simultaneous setup produced two TCP connections, traffic could not be sent over both; the implementation had to select one or retry after a randomized interval.

These statuses are operationally useful, but none is a social identity or business outcome. “Connected” is a state in one implementation's setup machine. It does not identify the contractual user, prove safe configuration or show that useful data arrived.

Evidence boundary

RFC 1613's security section says that security issues are not discussed. Silence is not assurance. The sources do not establish peer authentication, encryption, authorization, exposure policy or resistance to injection and misbinding. A port number, valid Version, legal Length, matching LCN or successful PVC status cannot be promoted into any of those properties.

No XOT implementation, Cisco release, operator network or captured session was tested for this report. The 1994 statement that existing implementations used end-to-end flow control is a period claim in the memo, not a present support matrix. The IANA rows do not prove listening services. The RFC does not establish current deployment, prevalence, incident history, application completion or direct ancestry to a modern overlay.

The established conclusion is deliberately smaller. A field may be valid and still lack enough scope to identify the thing an operator cares about. RFC 1613 kept the common wire rule narrow, carried stream identity across the implementation seam and allowed each local interface to assign the number it could actually honor. The circuit survived because the system preserved the boundary the field could not contain.

Sources