Summary

  • RFC 2126 kept TPKT version 3 to protect the RFC 1006 installed base, but the unchanged version byte no longer proved that peers agreed on Class 0, Class 2 or any expedited-data option.
  • A valid-looking connection confirmation, a negotiated second channel and a normal disconnect reason each stopped short of the next claim: accepted class, synchronized delivery and delivery to the remote user required separate receipts.

The most consequential byte in RFC 2126 was the one it chose not to change.

Published in March 1997, RFC 2126 revised the mapping of ISO Transport over TCP for IPv4 and IPv6. The RFC Editor record classifies it as a Proposed Standard that updates RFC 1006. Its goal was conservative: minimise changes, improve performance, extend applicability and protect an installed base that already expected TPKT version 3.

That compatibility bargain preserved a wire identity while expanding what the connection might mean. Class 0 remained the refined RFC 1006 service. Class 2 added explicit transport disconnection and options for expedited traffic, including a separate TCP channel. The version field could still say “3” on both sides even when only one side understood the richer service.

The old number became a weaker receipt

RFC 1006 had made version 3 part of its TPKT record boundary. Its official record now points to RFC 2126 as an update. RFC 2126 deliberately retained that number because changing it would prevent interoperability with implementations that insisted on version 3.

The decision did not mean that all version-3 implementations were equivalent. RFC 2126 introduced Class 2 over TCP while recognising that some RFC 1006 peers could not perform class negotiation. A Class 2 Connect Request with no alternative could receive a Class 0 Connect Confirm. The response could be syntactically valid and arrive on a functioning TCP connection; the initiator nevertheless had to reject it under ISO 8073.

That is the article’s historical hinge. Version identified a compatible envelope. It did not prove a shared capability set. The CR recorded what the initiator wanted; the CC recorded what the responder selected; the initiator’s acceptance or rejection recorded whether that selection satisfied the request. Collapsing those records into “connected” erased the very disagreement the protocol exposed.

The same restraint applied to the TPKT reserved field. RFC 2126 assigned a value but told implementations not to interpret reserved input and to ignore it for RFC 1006 interoperability. A reserved byte was not a hidden capability advertisement.

Independence was not synchronization

Class 2’s expedited-data design made the evidence ladder longer. The service could keep expedited TPDUs in-band on the normal TCP connection. Or the peers could negotiate a Forward or Reverse procedure and use a separate expedited TCP connection. RFC 1859 had already described a Class 2 extension over TCP; RFC 2126 incorporated and expanded that operational space.

A separate connection protected expedited traffic from a busy normal channel. It had to run between the same pair of hosts, belong to only one Transport Connection and remain until that transport connection ended. Those constraints were meaningful. They still did not prove that the second connection had been established in time, that data on the two channels would be delivered in one order, or that the application had received anything.

RFC 2126 treated independence and synchronization as separate requirements. Forward or Reverse connection procedures supplied independence. Expedited Data Acknowledgement or Non-blocking Expedited Data could supply the ordering discipline required for synchronization. Independence without synchronization explicitly relaxed the ISO Transport Service definition and was inconsistent with ISO 8072.

The distinction prevents a common operational mistake. Two healthy TCP sockets do not automatically create one ordered service. A channel binding proves scope. A synchronization mechanism proves a different property. The RFC even left the timing of a Forward-procedure expedited connection to the implementation. Negotiation was permission to use the mechanism, not a timestamped receipt that the mechanism already existed.

One reason code, two delivery contracts

Connection release exposed the same problem at the other end of the lifecycle. Class 0 based Transport Disconnection on the underlying TCP disconnection, so release was disruptive. Class 2 offered explicit release with DR and DC TPDUs and distinguished two modes.

In a disruptive disconnect, TPDUs still at the source did not have to be sent before closure. The DR reason was normal, 80 hexadecimal. In a non-disruptive disconnect, every TPDU already handed to the local transport-service provider had to reach the remote transport-service user before closure. Its DR reason was also normal; an Additional Information value of 80 hexadecimal carried the extra distinction.

The words “normal disconnect” therefore did not settle the delivery question. The mode and additional information mattered. So did the custody boundary: “given to the local provider” was not the same event as “delivered to the remote user.” One receipt marked acceptance into a local obligation; another had to evidence completion at the far side.

Registration and security stayed bounded

RFC 2126 reserved TCP port 102 but did not require every connection to use it. The current IANA service-name registry lists iso-tsap at port 102 and describes Class 0. That row proves coordination of a number, not a live listener, a negotiated class or a successful exchange.

The security section was equally plain: security issues were not specifically addressed, and ITOT was no more or less secure than TCP and ISO 8073. An open socket, valid TPKT, accepted class or bound expedited channel did not authenticate an organisation, authorize an operation, protect confidentiality or prove application outcome.

Lu Heng’s Running-Code Primacy provides a disclosed modern lens: the claim should be no larger than the state a running system makes observable. Minimum Initial Specification explains why compatibility should preserve room for later choices without pretending they are already coordinated. Reality Layers sharpens the final lesson: a symbol such as a version number is not the executable result it names.

RFC 2126’s history is therefore not a story of a versioning mistake. It is a story of a successful compatibility choice whose cost had to be paid in more precise evidence. Version, proposed class, selected class, second-channel establishment, synchronization, provider acceptance and remote delivery were seven different facts. The old byte could remain only if operators stopped asking it to prove all seven.

Sources

  • RFC 2126 — ISO Transport Service on top of TCP (ITOT)
  • RFC Editor — RFC 2126 record
  • RFC 1006 — ISO Transport Service on top of TCP, Version 3
  • RFC Editor — RFC 1006 record
  • RFC 1859 — ISO Transport Class 2 over TCP extension
  • IANA — Service Name and Transport Protocol Port Number Registry
  • Lu Heng — Running-Code Primacy
  • Lu Heng — Minimum Initial Specification
  • Lu Heng — On Reality Layers