要約

  • RFC 2126はRFC 1006のinstalled baseを守るためTPKT version 3を残したが、同じversionはClass 0、Class 2、expedited optionの一致を意味しなくなった。
  • Class選択、二本目のchannel、channel間の順序、non-disruptive disconnectでの遠端deliveryは、それぞれ別のreceiptを必要とした。

RFC 2126は、互換性を捨てて新機能を導入した文書ではない。外側の識別子を維持し、その内側でserviceの意味を増やした文書である。

1997年3月、RFC 2126はIPv4またはIPv6上のTCPでISO Transportを扱い、Class 0とClass 2を定義した。RFC 1006実装の中にはversion 3を必須とするものがあったため、TPKT versionは変えなかった。

その判断で旧peerとの入口は残った。しかしversionのreceiptは弱くなった。同じ3でも、一方はClass 0しか知らず、他方は明示的なdisconnectと独立したexpedited channelを扱える可能性があった。

正しい形式のCCを拒否する

Class negotiationを実装していないRFC 1006 peerも想定された。initiatorがalternativeなしのClass 2 CRを送り、古いpeerがClass 0 CCを返すことがある。TCPはopenで、CCはparseできる。それでもinitiatorはISO 8073に従って拒否すべきだった。

versionは外枠、CRは要求、CCは選択、accept/rejectは適合判断である。一つの“connected” stateにまとめれば、要求と選択の不一致が消える。reserved fieldもinputでは解釈せず、RFC 1006互換のため無視するよう求められた。予約領域は暗黙のcapability bitではない。

別channelは順序保証ではない

Class 2のED TPDUはnormal channel内でも送れる。ForwardまたはReverse procedureを交渉すれば、別のTCP connectionをexpedited dataに使える。normal channelが混雑してもexpedited側を塞がないことが目的だった。

二本目は同じhost pairを結び、一つのTransport Connectionだけに属し、その終了まで維持される。このbindingは重要だが、開設時刻を証明しない。特にForward procedureでは、いつexpedited TCP connectionを作るかをRFCはimplementation choiceにした。

さらにindependenceとsynchronisationは別である。Forward/Reverseはindependenceを作る。Expedited Data AcknowledgementまたはNon-blocking Expedited Dataが同期のための仕組みになり得る。independenceだけを選び同期しないserviceはISO 8072の定義を緩和する。

二つのsocketがhealthyでも、channel間の順序やapplication receiptは分からない。negotiation、establishment、binding、ordering、deliveryを別々に観測する必要がある。

同じnormal reason、異なるdelivery

Class 0のTransport DisconnectionはTCPの切断に依存し、disruptiveだった。Class 2ではDR/DC TPDUを交換し、DisruptiveとNon-Disruptiveを選べた。

Disruptiveではsourceに残るTPDUを送る義務はなく、DR reasonはnormalの16進80。Non-Disruptiveではlocal TS-providerに渡された全TPDUをremote TS-userへ届けてから閉じる。reasonは同じnormalで、Additional Information 80が差を表した。

したがってnormal closeという記録だけでは契約が分からない。local providerが受け取った時点はcustodyの開始であり、remote userへのdelivery完了ではない。

Portとsecurityも境界を越えない

TCP port 102は予約されたが、すべてのconnectionに必須ではない。IANAのiso-tsap 102/Class 0という行は番号調整を示すだけで、listen中のserviceやClass 2 supportを示さない。

Security Considerationsも明確で、RFC 2126は固有のsecurityを解決せず、TCPとISO 8073以上でも以下でもない。version、CC、socketはidentity、authority、confidentialityを証明しない。

Lu Hengの公開論考を現代的な読み方として明示すると、running codeから観測できる状態以上にclaimを広げず、最小のcoordination artifactに未来の判断を押し込まず、symbolic stateと実行結果を分ける必要がある。

RFC 2126の互換性は成功だった。ただし成功条件は、古いversion番号の代わりに細かなreceiptを残すことだった。version、requested class、selected class、acceptance、second channel、synchronisation、local custody、remote deliveryは同じ事実ではない。

情報源