要約

  • RFC 1613はX.25 virtual circuitごとに別のTCP connectionを必須とした。XOT内のLogical Channel Numberは任意であり、別streamから届く同一番号のCallを識別できない。
  • XOT layerはstream identityをX.25 engineへ渡し、送出先のlocal interfaceは自分が使うLCNへ書き換える。回線の連続性は一つのfieldではなく、interface間のmappingにあった。
  • 明示的なflow-control facility、越境できないlocal packet、PVC固有のsetup交換は、共通ruleとlocal decisionを分離する同じ設計を示す。

同じ番号が衝突する場所

device AとBが、それぞれXOT sessionを使ってdevice Cを呼ぶ。両方のX.25 headerには同じLCNが入っている。CがLCNだけでCall stateを検索すれば、正しい二つのlocal valueを一つのnamespaceへ押し込めることになる。packetは別のstate machineへ入り、Clearは別のCallを閉じかねない。

RFC 1613は、このA/B/C例を説明している。RFC Editor recordによれば、cisco Systems X.25 over TCP (XOT) は1994年5月のInformational RFCであり、Internet standardではない。文書が証明するのは公開されたmethodであって、全製品の実装、運用者の採用、現在の普及ではない。

XOTの答えは、virtual circuitごとにTCP connectionを一つ使うことだった。XOT connection内のLCNは意味を持たず、値は任意でよい。CのX.25 engineは、同じ番号の二つのpacketが異なるlogical XOT interfaceから来たと知る必要があるため、XOT layerがstream identificationを伝える。

必要なのは、より大きな番号ではない。local identifierの意味を成立させているinterfaceとrunning stateを失わないことだった。

Streamが補った文脈

TCP connectionはX.25 circuitより先に作られ、RFC 1613ではTCP port 1998を使い、SYNにXOT dataを載せない。現在のIANA service-name/port registryはx25-svc-portを1998のTCPとUDPに掲載している。ただしregistry rowは番号の調整記録であって、listen中のserviceやconformanceの観測ではない。RFC 1613が規定するcarrierはTCPである。

一つのVCを一つのTCP connectionへ割り当てれば、stream lifetimeとendpointがlookup contextの一部になる。それでもTCP connectionは本人確認、Call authorization、application completionではない。LCNだけでは欠けていた技術的namespaceを補うにすぎない。

RFC 793のTCPはordered octet streamであり、X.25 packet boundaryを渡さない。そこでRFC 1613は16-bit Versionと16-bit Lengthからなる4-byte headerを置いた。Versionは0でなければならず、未知のversionやillegal lengthならTCPを閉じる。

しかし、これは本稿の主題ではない。RFC 1006のTPKTも別の4-octet headerでTCP streamにrecord boundaryを戻しており、BTWには既にその記事がある。XOT固有の問題は、packetを正しく切り出した後にも残る。stream/interface contextを捨てれば、完全なpacketを誤ったcircuitへ渡せるからだ。

出口で番号は変わる

TCPから来たX.25 packetをlocal interfaceへ送るとき、RFC 1613はそのinterfaceで使われるLCNを設定するよう求めた。番号がhandoffで変わっても、意図されたVCは続く。この一点だけでも、LCNをportable identityとして扱えない。

監査可能なreceiptには、TCP connection、logical XOT interface、incoming LCN、outgoing interfaceとoutgoing LCNが必要である。inner numberだけを残せば同番号の別Callを区別できない。TCP endpointだけではlocal X.25 allocationが消える。“forwarded”だけではmappingも次の結果も証明しない。

Heng LuのRunning-Code Primacyに沿えば、claimはlocalかつ検証可能にする。RFCはminimum interoperationを示し、configuration、state transition、packet observationが「この時点のこのimplementation」のmappingを示す。document publicationをrunning outcomeへ昇格させない。

Network defaultは共有できなかった

通常のX.25 interfaceにはpacket sizeとwindow sizeのnetwork defaultがあり得た。TCP/IP networkで多様なsiteを結ぶXOTでは共通defaultを期待しにくいため、Callは両facilityを明示しなければならない。

欠落したCallを受け入れるかはlocal matterである。ただし受け入れるなら、Call Confirmで実際の値を返す。共通layerは必要な事実を交換し、local systemは自分のcapacityとpolicyに基づいてaccept/refuseする。

Flow controlもend-to-endまたはlocalにできた。local方式はDATAを分割・結合し、各interfaceで別のpacket sequenceを持てる。modulo 128と8をつなぐならheader stateを翻訳し、8側に大き過ぎるwindowは下げるか接続を拒否する。片方向のRNRが反対方向のDATAまで止めると仮定してはいけない。

TCP reliabilityは、X.25 window agreement、receiver readiness、sequence translation、business resultをまとめて保証しない。

越境するpacketと止まるpacket

InterruptとResetはend-to-endなのでTCPを越える。Restart、DTE Reject、Diagnostic、Registrationはlocal DTE/DCE interfaceだけの意味を持ち、XOTへ送らず、TCPから受け取ればdiscardする。

Encapsulationはinner protocolの全controlをportableにしない。どのstateが新しいboundaryを越えられるかを分類することがinteroperabilityの一部だった。

PVCはさらに難しい。X.25のpermanent virtual circuitはprovider provisioningで存在し、Call/Clearを交換しない。XOTで運ぶには、TCP確立直後に非標準のPVC setupを送り、interface name、local LCN、flow-control valueを照合する必要があった。

Statusはinterface不存在・down、非X.25 interface、PVC不存在、configuration mismatch、flow-control mismatchなどを分ける。status zeroの成功後には双方のlocal interfaceでResetを完了する。TCP closeがXOT PVCの切断になる。同時setupで二本のTCP connectionができても、両方へtrafficを流してはならない。

これらは状態機械の証拠であって、契約主体や有用な通信の証明ではない。

証拠の境界

RFC 1613のSecurity Considerationsはsecurity issueを論じないとだけ述べる。議論がないことは安全性ではない。peer authentication、encryption、authorization、exposure control、injection防止はsourceから確認できない。port、Version、Length、LCN、setup successはそれらを代替しない。

本稿では実装、Cisco release、operator network、packet captureを試験していない。“existing implementations”がend-to-end flow controlを使ったという記述は1994年文書内の主張であり、現在のsupport matrixではない。IANA rowはdeploymentを示さない。現在の普及、incident、application completion、modern overlayへの直接的系譜も不明である。

確かな結論は狭い。正しいfieldでも、対象を識別するscopeが足りない場合がある。RFC 1613は共通ruleを必要最小限にし、implementation seamでstream identityを渡し、local interfaceに自分の番号を選ばせた。circuitを守ったのは番号の不変性ではなく、番号が持てなかった境界の保存だった。

情報源