Summary

  • RFC 1006’s TPKT adds a four-octet header—version, reserved field and total packet length—before an ISO Transport TPDU, so a receiver can delimit that TPDU in TCP’s otherwise boundary-free byte stream.
  • The header restores a record boundary. It does not prove identity, integrity, application acceptance, service ownership, current deployment or the existence of an ISO network beneath TCP.

The recurrent mistake with TCP is to call it a message protocol because a program wrote a message before calling send. TCP makes a different promise. RFC 793 describes a continuous stream of octets in each direction. Segments are TCP’s delivery machinery, not a public envelope for the receiving application. One read can contain part of a sender’s write, several writes, or an amount selected by buffering and timing.

That was a concrete interoperability problem for the ISO Transport service that RFC 1006 sought to carry over TCP in 1987. Transport Protocol Data Units—TPDUs—were discrete protocol objects. The TCP substrate deliberately offered no corresponding edge. The specification’s answer was not to ask TCP to remember an application boundary it never promised. It placed a small, explicit record grammar above the stream.

Count first, then read the TPDU

RFC 1006 calls the record a TPKT. It consists of a constant packet header followed by a TPDU. The header is four octets: an 8-bit protocol version, an 8-bit reserved field, and a 16-bit packet length. In version 3, the version value is always 3. The length is the entire TPKT in octets, including that header; RFC 1006 gives a range of 7 through 65,535. A receiver that has accumulated the header learns exactly how many more octets belong to this record before it begins the next one.

This is a framing rule, not an assertion about TCP segment boundaries. The first two header octets could arrive in one read and the rest much later; several complete TPKTs can arrive together. The correct receiver buffers the stream, waits for its declared count, hands the resulting TPDU to the ISO Transport logic, and repeats. The four-byte drawing in the RFC is also not a requirement that every TPKT be a multiple of four bytes. The drawing is presentation; the length field is the rule.

The payload deserves its own name. For the RFC 1006 class-0 discussion, the relevant discrete network-service object is identical to a TPDU. The TPDU has a defined ISO Transport role; it is not evidence that a whole business transaction, human message, login or database write has happened. Framing gives a program a bounded sequence of bytes to parse. Meaning still belongs to the protocol and application layers above it.

A transport mapping, not an OSI replacement

RFC 1006 was STD 35, obsoleted RFC 983, specified version 3 and reserved TCP port 102 for hosts implementing the standard. Its ambition was carefully located: offer the ISO Transport service over TCP/IP so higher ISO layers could operate without knowing that their lower carrier was TCP/IP. That is why the four-byte header matters. It made a particular service interface plausible across a mismatch in lower-layer delivery shape.

It did not cause the Internet to acquire an ISO network layer. It did not make a port number proof that a named organisation operated a service. It did not authenticate a peer, encrypt a TPDU, bind an address to an owner, or say that the recipient accepted the semantic content. A length field is excellent at telling a parser where to stop. It is silent about who supplied the bytes and whether the action represented by those bytes should occur.

RFC 2126, published in 1997, updated RFC 1006. It retained TPKT’s version/reserved/total-length shape, refined class 0 for the RFC 1006 installed base and added a class-2-over-TCP variant. Its security section is unusually helpful as a boundary: the protocol is no more or less secure than TCP and ISO 8073. The update records an evolution of the mapping, not an evidence warrant for today’s prevalence or a claim that a parsed TPKT is trustworthy.

What the boundary changes operationally

The control point is mundane but durable: stateful framing must be observed separately from transport delivery and higher-level results. A trace may show a TCP connection, a port, a version-3 TPKT header, its declared length, and a syntactically parsed TPDU. Those facts support a narrow account of the transport exchange. They do not establish the identity of a user, authority of a request, the ownership of a network endpoint or a completed operation.

That distinction is more useful than a nostalgic account of “old OSI.” A decoder needs limits for buffered bytes, sane handling of an impossible length, record-level error reporting and logs that distinguish stream receipt from TPDU parsing. A service owner needs separate evidence for authentication and business outcomes. The 1987 design keeps those jobs separate because the header cannot do them by implication.

Sources and limits of the record

The RFCs below establish the historical status, stream/record mismatch, TPKT grammar and 1997 update described here. They do not establish a current deployment share, an implementation on a named host, a security property beyond the cited protocols, user identity, payload integrity or application success.