Summary

  • RFC 1086 let a TCP/IP host ask a bridge either to call an X.25 address or to listen on an X.25 subaddress and forward incoming calls to a nominated IP address and TCP port.
  • The listening claim lasted only while a dedicated TCP registration connection remained open. Its closure released the limited subaddress, but its presence did not authenticate or authorize the claimant.
  • A successful call still rested on two separate network connections—X.25 on one side and TCP on the other. The bridge relayed TP0 packets; it did not prove peer identity, application acceptance or an end-to-end outcome.

A scarce address needed a way back

In 1988, an IP host and an X.25 host could both run ISO transport class 0 and still lack a direct way to find each other. RFC 1006 had already put TP0 over TCP/IP. X.25 networks had their own mapping. RFC 1086 proposed a bridge that knew both sides.

The memo was careful about its ambition. It was an experiment, not a “magic bullet” for DDN/ISO interoperability. Both endpoints already had to speak higher-layer ISO protocols. The bridge did not convert an arbitrary TCP application into an X.25 one. It connected two carriers beneath the same TP0 exchange.

That left an address problem. An X.25 caller needed a subaddress to call, while the actual service lived at an IP address and TCP port. A bridge operator owned only a limited X.25 address space. A permanent allocation for every occasional IP host would waste it; a claim with no reliable end would strand it.

RFC 1086’s answer was a registration whose lifetime could be observed through a connection.

Two functions met at the registration gate

The registering host opened TCP port 146 on the bridge and sent one function octet. Value 1 meant: call a particular X.25 address. Value 2 meant: listen for incoming calls on a particular X.25 address. Zero was illegal; the remaining values were reserved.

Function 1 was the short path. The host supplied an X.25 address, and the bridge attempted the call. If the X.25 call failed, the bridge closed the TCP connection. The protocol did not invent a rich gateway error language to explain the carrier’s internal failure.

Function 2 created a continuing obligation. The host supplied an X.25 address that should be a subaddress of the bridge’s address. It then supplied the IP address and TCP port that would serve incoming calls. The bridge listened on the X.25 side. When a call arrived, it attempted a new TCP connection to that callback endpoint. If the TCP open failed, the incoming X.25 call was refused.

This was neither directory publication nor permanent delegation. It was an operational binding inside one bridge: for as long as the registration remained valid, calls for this subaddress should be paired with that callback.

The heartbeat marked a lifetime, not a principal

RFC 1086 called the original registration connection a “heartbeat” connection. The name can mislead a modern reader. The memo did not define heartbeat messages, active probes, application checks or a health score. The signal was simpler: the TCP connection still existed.

When that connection closed, the bridge assumed that the listening function had ended. It stopped listening on the indicated subaddress. The authors stated the reason plainly: without such a facility, the address could not be recovered for reuse.

The mechanism therefore answered a temporal question. Is the remote host still maintaining this registration connection? It did not answer an identity question. It did not prove which person or organisation controlled the host, whether the callback application was still useful, or whether a network path could carry the next call.

Connection state was useful because the bridge itself could observe it and perform cleanup. Its weakness was equally clear: a live but unauthorized client could keep a scarce slot occupied, while a brief carrier failure could withdraw a legitimate registration. Lifetime and entitlement were different facts.

Two carriers sat beneath one TP0 exchange

Once setup succeeded, the bridge held two network connections. TP0 ran over X.25 on one side and over TCP on the other. During transfer, the bridge read a TPDU from one connection and wrote it to the other. During release, a disconnect on one side caused a disconnect on the other; simultaneous closes required no extra action.

The distinction matters because a higher layer could see one transport conversation while the bridge still managed two lower failure domains. The X.25 call could succeed and the TCP callback fail. The registration connection could survive while an individual data connection broke. A successful TCP open could establish the carrier without authenticating the application above it.

RFC 905 supplies the TP0 and TPDU vocabulary. RFC 793 supplies the historical TCP open, data and close substrate. RFC 1006 supplies the TP0-over-TCP mapping and TPKT framing. RFC 1086’s contribution was the bridge’s setup and registration seam, not a new meaning for every packet.

Transparency came from refusing a new error language

RFC 1086 tried to keep gateway-specific behavior inside connection establishment. It added no error reports beyond those TP0 already carried. Recoverable network errors were ignored; other failures led to disconnection. After setup, the circuit was intended to look like an RFC 1006 implementation.

That design reduced what endpoints had to understand, but it also bounded the evidence available to them. A closed connection could show that the bridge had stopped the exchange. It could not always say whether the cause was an X.25 refusal, a TCP failure, local policy or bridge resource pressure. Transparency at one interface can require better private telemetry at the operator boundary.

Security was explicitly local

The memo did not quietly omit a complete trust model. It said authentication and authorization were outside the protocol and presumed local. It also named the consequence: unrestricted access would let any TCP/IP host claim part of the bridge’s limited X.25 address space.

That warning separates syntax from admission. A well-formed function-2 request tells the bridge which subaddress and callback endpoint the requester wants. It does not establish a right to either. An IP address is a routing coordinate, not a person. A TCP connection is a stateful channel, not a credential. An unused X.25 subaddress is capacity, not an invitation.

The bridge operator therefore carried authority the wire format did not describe: authenticate a principal if required, decide which subaddresses that principal may claim, limit concurrent and long-lived registrations, resolve collisions, and preserve evidence of the decision.

Address records were operational, not identity records

RFC 1086 fixed an X.25 address record at 68 octets and included fields for the X.121 address, protocol identifier, call user data and facilities, each with meaningful lengths. It also defined a fixed TCP/IP callback record containing an address type, TCP port, IPv4 address and padding.

The authors called these structures ad hoc and specific to UNIX. They expected experience to change them. That candour is important. A record can be exact enough to operate a bridge without being a timeless identity scheme. Parsing the address proves only that bytes satisfy the chosen grammar.

The current IANA Service Name and Transport Protocol Port Number Registry lists iso-tp0 at port 146. IANA also warns that a registered port is not an endorsement and that observed traffic need not be the assigned service. The registry contains TCP and UDP rows; RFC 1086’s procedure is over TCP. Registry continuity cannot manufacture a UDP variant, a deployment count or a trustworthy endpoint.

Five records are better than one status

An accountable implementation would preserve the request, the local admission decision, the registration connection’s lifetime, each paired X.25/TCP data connection and the TP0 or application result. These records answer different questions.

A row labelled active cannot safely stand for all of them. It might mean the control connection is open while the callback is unreachable. A successful callback might coexist with an unauthorized claim. A TP0 response might arrive even though the user’s intended work failed later.

RFC 1086’s small bridge exposes a durable design lesson. Reclaimable state is valuable, but expiry is not identity. A gateway can make two networks interoperable at one protocol seam while leaving admission, attribution and outcome deliberately outside that seam.

Sources and limits

The mechanism comes from RFC 1086; RFC 1006 and RFC 905 define the neighboring TP0 surfaces; RFC 793 supplies the TCP model; IANA records the service name and current port rows. These sources establish protocol text and registry state. They do not establish present deployment, a named implementation, real X.25 ownership, authenticated principals, successful calls, user outcomes or direct ancestry to modern lease and service-mesh systems.