要約

  • TPKT はバージョン、予約、全長からなる四オクテットのヘッダーの後に TPDU を置き、TCP の流れから一件を切り出せるようにした。
  • その切り出しは、相手の本人性、完全性、許可、業務上の成立を保証しない。

RFC 793 の TCP は連続したオクテットのストリームである。TCP セグメントをアプリケーションのレコード境界に使うことはできない。一度の読み出しが半分の TPDU である場合も、複数の TPKT を含む場合もある。

RFC 1006 は 1987 年、この差を ISO Transport class 0 と TCP/IP の接点で処理した。TPKT は固定ヘッダーと TPDU からなる可変長のパケットである。ヘッダーは 8 ビットの version、8 ビットの reserved、16 ビットの packet length。version 3 では version は常に 3、長さはヘッダーを含む全 TPKT で、7 から 65,535 オクテットである。

実装が信頼してよいのはこの手順だけだ。四オクテットをため、宣言された全長を読み、足りなければ待ち、そろって初めて TPDU を渡す。RFC の四オクテット幅の図は、パケット長が四の倍数であるという意味ではない。境界を決めるのは長さである。

RFC 1006 は STD 35 で RFC 983 を置き換え、実装ホスト用に TCP port 102 を予約した。狙いは TCP/IP を下位の担体として ISO の上位層へ Transport Service を提供することだった。それは ISO のネットワーク層を TCP の下に復元する主張ではない。port 102 の観測はサービス所有者の証明にならず、整形された TPKT は暗号化も認証もしていない。

1997 年の RFC 2126 はこの仕様を更新し、TPKT の version/reserved/length を保ち、既存基盤向け class 0 を洗練し、class 2 over TCP を加えた。安全性については TCP と ISO 8073 以上でも以下でもない、と明記する。TPDU を読めたことと、ユーザーやアプリケーションの意思が確定したことは別の記録である。

出典と限界