要約

  • RFC 875は、共通のIPデータグラムを保つInternetゲートウェイと、異なるアドレス・確認・フロー制御・アプリケーション意味論を対応づける変換ゲートウェイを区別した。
  • 両側の接続を終端して対応状態を抱える中継装置は、セッションの特異点となり、冗長化・復旧・将来の変更に別の設計を要求した。

二つのネットワークを箱で結ぶ図には、変換できなかったものを描く記号がない。左から入ったアドレスが右の宛先を表せないときも、近くの装置が返した確認が遠いホストの確認ではないときも、矢印は同じ太さで引かれる。

M. A. Padlipskyが1982年9月に公表したRFC 875 Gateways, Architectures, and Heffalumps は、その箱に隠された判断を取り出した。これは実装標準でも、当時の変換装置を数えた調査でもない。互換性のないプロトコル体系をつなぐ変換／対応付けゲートウェイを、通常のInternetゲートウェイの延長として扱うことへの批判だった。

共通層があるから、ローカルな違いを残せた

RFC 791 のIPは、異なるパケット交換ネットワークを相互接続するためのデータグラムを定めた。Internetアドレスとフラグメンテーションにより、パケット寸法やローカル技術が異なるネットワークを越えられた。一方、エンドツーエンドの信頼性、順序、フロー制御はIPの約束ではなかった。

約束しない範囲は欠陥ではなく分担だった。ゲートウェイは入口のローカルフレームを外し、Internetアドレスから次の転送先を選び、同じIPデータグラムを出口のフレームに包む。RFC 791は上位プロトコルをゲートウェイに実装する必要がないとも記している。

RFC 793 は、接続、シーケンス、再送、ウィンドウ、緊急表示をホスト側のTCPに置いた。ゲートウェイが狭い責務を保てたのは、機械が単純だったからではない。どの意味を共通に保存し、どの保証を端点が持つかが定まっていたからである。

したがってRFC 875の批判は異種ネットワークそのものに向いていない。IPはまさに異種のローカルネットワークを越える仕組みだった。共通の細い層より下の差と、上位プロトコルが表す意味そのものの不一致は別問題だ、という指摘である。

NCPには外部ネットワークを指す場所がなかった

NCPのホストインターフェースはARPANET内のホストを識別した。IPアドレスはネットワーク部とホスト部を持つ。通常のNCP側には「別のネットワークにあるこのホスト」を指定する次元が欠けていた。

空きビットを探す、初期接続プロトコルを変える、アプリケーションデータにInternetアドレスを入れる、といった案は考えられる。しかし、どれも変更不要とされたNCP環境を拡張する。表記の変換では、元の契約にない宛先範囲を生成できない。

RFC 875は、境界を明示する別案を示した。中継装置がホストとして最初の接続を終端し、利用者に外部の行き先を尋ね、二本目の接続を開始する。Padlipskyはこれを「Janus Host」と呼んだ。Telnetのような用途では実用になり得るが、一本の透明な接続ではない。

RFC 801 のNCP/TCP移行計画では、この分離が操作として見える。Telnet利用者は中継ホストの特別なアカウントに入り、反対側へ新しいTelnet接続を開始する。FTPはファイルを二度移動し、メールには別の中継手順があった。アプリケーションごとの二段階リレーであって、プロトコル体系全体の無損失変換ではない。

近くから来た確認は、遠端の事実ではない

NCPのReady for Next Messageは宛先IMPから返る。変換装置が間にある場合、そのIMPは変換装置に隣接するものになり得る。信号はそこまでの状態を示しても、異なる体系の先にある最終ホストの受信やアプリケーション処理までは証明しない。

変換装置は信号を保留し、データをバッファできる。それでも、反対側の何を見て次を許可するかを決めなければならない。ローカル網の受理か、トランスポートの受信か、アプリケーションの消費か。相手のプロトコルが必要な事実を公開しなければ、待ち時間やメモリを増やしてもエンドツーエンドの証拠にはならない。

フロー制御は速度だけでなく、止まる主体、保護する資源、再開を許す証拠を定義する。両体系の境界が異なれば、その不一致は中継装置の内部状態になる。バッファは判断を先送りできても、欠けた意味を作れない。

同じ「緊急」でも、命令される主体が違った

NCPには制御リンク上の割り込み命令があり、TCPには接続内のUrgent機構があり、TelnetにはInterrupt Processがあった。ほかの体系には優先データがある。似た名前でも、誰に何をさせる信号かは一致しない。

RFC 793では、緊急機構は受信ユーザーに緊急情報の処理を促し、緊急モードへの出入りを扱う。プロトコル解釈部へ優先サービスを与えることと、最終プロセスへ処理中断を命じることは同じではない。

相手側に該当動作がなければ、中立的な変換はできない。信号を落とせば機能を失う。優先配送をプロセス割り込みとして扱えば、新しい権限を作る。アプリケーションを終端してローカル方針を実行するなら、少なくとも中継装置が判断者であることは明らかになる。

RFC 875はUniversity College Londonの端末ゲートウェイにも触れた。ARPANET TelnetとX.25/X.28/X.29系の間でデータは移動したが、文書が報告した範囲ではエコーのオプションだけが通った。この記述を装置全体の監査結果に広げてはならない。文字の到着と、文字を扱うオプション群の保存が別の証明であることを示す限定的な材料だ。

予備機は稼働中の会話を知らなかった

変換装置がすべての対応を実装すると、二つの接続識別子、二つのシーケンス空間、フロー状態、アドレス対応、オプション、アプリケーション上の前提を保持する。同じ機械を隣に置くだけでは、進行中の状態は共有されない。

RFC 875はこの中継点を「singularity point」と表現した。パケットの経路制御は故障リンクを迂回できても、変換装置だけが知る会話を再構成できない。引き継ぎには状態複製、競合解決、所有権移転のプロトコルが要る。図の一箱は分散システムになっていた。

変更時にも同じ集中が起きる。A–Bの変換装置はA–Cを解決しない。一方のアドレス、オプション、アプリケーションが変われば、関係する組み合わせを点検し直す。便宜的な境界が両側のリリース日程と曖昧さを抱え込む。

後のIPルーターも多くの適応を担った

RFC 1009 は後にInternetゲートウェイをIPレベルのルーターとして定義した。フレーム、MTU、ローカルアドレス対応、ローカルなフローやエラー表示に対処し、バッファと次ホップも管理する。責務が狭いことは処理が少ないことを意味しない。

重要なのは、適応の間を通る対象がIPデータグラムのままだった点である。ルーターは外国側アプリケーションの確認を再現したり、あるプロトコル解釈部への命令を別のプロセス命令へ変えたりする契約を持たない。共通層の境界が保たれていた。

後年の中間装置は同じ検査項目を別の形で示した

RFC 2775 は、アドレス変換がエンドツーエンドのアドレス透明性を壊し、ペイロードにアドレスを含むアプリケーションにはゲートウェイやプロキシの知識が必要になると述べた。アドレス依存の新アプリケーションが増えるたび、中間装置の理解も増え得る。

RFC 3234 はmiddleboxの有用性を認めながら、状態を持たない別装置への経路変更、装置障害によるセッション影響、複数層にまたがる診断といった故障面を整理した。アプリケーションゲートウェイが状態を持つのは、単なる不透明データの転送ではなく意味処理に参加するためである。

RFC 4966 は、埋め込みアドレス、IPv4/IPv6の意味差、断片状態、対応表の寿命、DNS-ALGの規模、障害・攻撃の集中など具体的理由によりNAT-PTをHistoricへ移した。これはすべての変換を否定する証拠でも、RFC 875からの直接的な系譜でもない。「パケットを変換する」だけでは仕様が完結しないという検査を、別の時代に繰り返した文書である。

欠けた意味は誰かの決定として表に出す

中間装置を通る矢印には四つの問いを置ける。入った主張は何か、出た主張は何か、誰が両者を対応づけたか、障害後にどの証拠が残るか。

最小の共通プロトコルがあれば、ゲートウェイは共通対象を保ちながらローカル実装を適応できる。なければ、サービスを共通部分まで落とす、いったん終端して再開する、端点に意味を追加する、ある機能が渡らないことを認める、という選択を明示しなければならない。

バイトが届いた、アドレスが書き換わった、端末が応答した。いずれも観測可能な成果だが、確認、緊急性、オプション、障害後の継続が同じ意味を保った証明ではない。ゲートウェイは両側が定義済みの対象を運べる。片側が一度も約束していない保証には、追加する主体か、失われる範囲を示す主体が必要である。

出典