要約

  • RFC 1086は、指定X.25 addressへの発呼と、X.25サブアドレスで待ち受けて指定IP address／TCP portへ折り返す登録を定義した。
  • 待受登録は専用TCP connectionが存在する間だけ続いた。closeは希少なサブアドレスを回収する合図だが、申請者のidentityや権限を証明しない。
  • 発呼成立後も、X.25側とTCP側には別々のnetwork connectionがあった。ブリッジが運ぶのはTPDUであり、applicationの承認や結果ではない。

片側の住所をもう片側から借りる

RFC 1006により、TCP/IP hostはTP0を利用できた。X.25にもTP0を載せる方法があった。そこでRFC 1086は、双方のcarrierを扱うbridge hostを置いた。

ただし、これは何でも変換するgatewayではない。両端が上位ISO protocol、特にTP0を既に話すことが前提だった。文書自身もDDN/ISO相互運用の万能解ではなく、実験的提案として範囲を限定している。

TCP/IP側から発呼するだけなら、行き先のX.25 addressをbridgeへ伝えればよい。難しいのはX.25側からの着呼だった。発信者はX.25空間のaddressを必要とするが、実際のserviceはIP hostにある。bridgeが持つサブアドレスは無限ではない。

永久割当は資源を浪費する。終了を確認できない一時割当も同じ結果になる。そこで登録の存続を一つのTCP connectionに結び付けた。

最初のoctetが二つの仕事を分けた

IP hostはbridgeのTCP port 146へ接続し、function octetを送る。値1は特定X.25 hostへのconnection、値2は着呼用addressの登録である。0は不正、3から255は予約された。

function 1ではX.25 addressを送り、bridgeが発呼する。失敗すればTCP connectionを閉じる。gateway独自の詳細なerror protocolは追加しない。

function 2では、bridgeのX.25 address配下であるべきサブアドレスと、着呼を処理するIPv4 address／TCP portを登録する。bridgeがそのサブアドレスで待ち受け、着呼時に新しいTCP connectionをcallback先へ開く。openに失敗すればX.25 callを拒否する。

ここで作られるのは運用上のbindingである。世界的なdirectory entryでも、addressの譲渡契約でもない。このbridgeが、この登録epochで、この着呼をこのcallbackへ結ぶという約束にすぎない。

heartbeatはhealth checkではなかった

登録時に開いたTCP connectionをRFCはheartbeatと呼ぶ。しかし周期message、probe、application response、health scoreは規定されていない。connectionそのものの継続が状態だった。

closeを観測すると、bridgeは待受終了とみなし、サブアドレスを解放する。著者は、この仕組みがなければaddressを再利用できないと説明した。遠端の明示的な解除messageだけに頼らず、bridge自身がcleanupを開始できる点が強い。

同時に、見えるのはconnectionの寿命だけである。未認可hostでも接続を維持できれば枠を占有できる。正当なhostでも一時的なnetwork failureで登録を失う。socketが開いていてもcallback applicationが応答可能とは限らない。

liveness、identity、authorization、service healthはそれぞれ別の記録でなければならない。

TP0の下には二つのcarrierが残った

setupが成功すると、bridgeにはX.25 network connectionとTCP connectionが一つずつできる。TP0は両方の上で動き、bridgeは一方からTPDUを読み、他方へ書く。片側のdisconnectは反対側のdisconnectを引き起こす。

RFC 905はTP0とTPDUの意味を与え、RFC 793は当時のTCP substrateを与える。RFC 1006はTCP stream上のTPDU境界を作る。RFC 1086の主題は、それらをどう登録し、どう二本に結ぶかだった。

上位から一つのtransport exchangeに見えても、故障は一つにならない。X.25 callが成立してもTCP callbackは失敗できる。登録connectionが残っても個別callは切れる。TCP openが成功してもapplication-level peerが承認されたとは言えない。

transparentにするほど、operator logが重要になる

RFC 1086はTP0以外のerrorを報告しない。回復可能なnetwork errorは無視し、それ以外はdisconnectにする。bridge固有処理をconnection establishmentへ集め、成立後はRFC 1006実装のように見せようとした。

endpointにとっては単純だが、原因の解像度は下がる。closeだけではX.25 refusal、TCP failure、local policy、resource exhaustionを区別できない。public interfaceを小さくするなら、bridge operatorはprivate telemetryを厚くする必要がある。

protocolが避けたsecurity decision

文書はauthenticationとauthorizationをlocal matterと明記した。無制限に運用すると、任意のTCP/IP hostがbridgeの限られたX.25 address spaceをclaimできるとも警告する。

正しいformatは権利ではない。IP addressはroute先、TCP portはtransport endpoint、open connectionはstateである。どれもpersonやorganisationを証明しない。空きサブアドレスも、最初の申請者が所有してよいという意味ではない。

したがってoperatorは、principal、許可範囲、quota、最大期間、collision処理、revocation、監査を別に決める。function octetは希望を伝える。希望を受け入れるauthorityはbridge側に残る。

address recordは道具であって身分証ではない

RFC 1086のX.25 recordは68 octetsで、X.121 address、protocol ID、call user data、facilitiesと各lengthを持つ。TCP/IP callback recordにはaddress type、TCP port、IPv4 address、reserved paddingがある。

著者はこの形式をad hocかつUNIX固有と認めた。実験を動かす正確さと、長期identityとしての安定性は同じではない。parse成功はbyte grammarの証明にとどまる。

現在のIANA Service Name and Transport Protocol Port Number Registryはport 146にiso-tp0を載せる。一方でIANAは、port assignmentがendorsementではなく、そこで見たtrafficが登録serviceとは限らないと注意する。UDP rowが存在しても、TCPで定義されたRFC 1086登録手順のUDP版を証明しない。

一つのactive flagでは足りない

必要な証拠は、登録request、local admission decision、登録connection lifetime、各callのX.25/TCP pair、TP0またはapplication outcomeである。

heartbeatがactiveでもcallbackは到達不能になり得る。callbackが開いても登録が無権限かもしれない。TP0 replyがあっても利用者の目的は未達かもしれない。

この小さなbridgeの価値は、connection closeをきれいなwithdrawal triggerにした点にある。だがwithdrawalをidentityへ拡張しなかった点も同じく重要だ。interoperabilityとgovernanceは別のcontrol surfaceとして残された。

出典と限界

bridgeの規則はRFC 1086、隣接するtransport/TCPの境界はRFC 1006、RFC 905、RFC 793、port registryはIANAに基づく。現在のdeployment、特定製品、real address owner、authenticated principal、call成功、user outcomeはこれらからは分からない。