要約

  • RFC 1498は、サービスまたは利用者、ノード、ネットワーク接続点、経路という四つの名付けられる対象を区別した。
  • Ethernetでノード名と接続点名を同じ48ビット値に固定すると、表を一つ省けるが、一台のノードと二つの接続点を同時に表現しにくくなる。
  • 解決結果やアドレスは、変化し得る結合の一断面である。本人性、権限、到達性、配送、アプリケーション結果は別の証拠を要する。

省かれた表の行方

RFC 1498が取り上げたEthernetでは、ノードが48ビットの一意な値を持ち運び、インターフェースがその値宛てのフレームを監視した。そのため、この値はノードの名前とも、ネットワーク接続点の名前とも読めた。

二つを同じ値にすれば、ノードは物理的に移動しても記録を変更せずに済む。ノードから接続点への対応表を一段省け、別経路の探索も簡単になる。これは明確な工学的利点であり、RFCはその選択自体を否定していない。

ただし同じEthernet上で二つの接続点を個別に指定したくなると、圧縮の代価が現れる。別々の値を付ければ、値をノード名として解釈する他の記録には二台のノードに見える。同じ値を使えば、一方の接続点だけを狙えない。結合表をなくしたのではない。ノードと接続点の結合を永久に固定し、その可変性を手放したのである。

文字列か数値かでは決まらない

Jerome Saltzerの論文は1982年に初出し、1993年8月にInformational RFCとして再掲された。中心にあったのは、名前、アドレス、経路という三語だけでは議論の対象を取り違えやすいという問題だった。

そこでRFC 1498は、まず四種類の対象を置く。サービスと利用者は機能とその利用主体、ノードは機能を実行する計算機、接続点はノードがネットワークに接続するポートや場所、経路は接続点間をリンクと転送ノードで結ぶ道筋である。

次に、表記の外見から対象を推測する罠を退ける。読める文字列だからサービス名とは限らず、バイナリだからノード識別子とは限らない。階層的だから接続点アドレスとも限らない。どの対象も用途に適した形式で名付けられ、一つの対象が複数形式の名前を持つこともある。

問うべきは「これは何という形か」より先に、「何を名付け、どの文脈で何に結び付けられるか」である。

三つの移動を分離する

サービスは同一性を保ったまま別ノードへ移せる。ノードは同じノードのまま別接続点へ移れる。接続点間の経路も、端点の同一性を変えずに変化できる。

したがってサービスへ送信するには、サービスを実行するノードを見つけ、ノードへ届く接続点を見つけ、送信側からその接続点への経路を見つける。RFC 1498はこれをサービス名解決、ノード名位置決定、経路サービスという三つの概念的な結合サービスに分けた。

各段階には複数候補があり得る。複製サービス、マルチホームノード、複数経路があるからだ。候補同士も独立ではなく、経路状況を見てからノードを選ぶ場合がある。表は部分的な結合や一覧だけを返し、最終選択をネットワーク外の利用者に残してもよい。

一つの返答だけでは、候補集合も選択方針も分からない。現在の値は現在の結合を示すのであって、対象の不変な本質ではない。

DIALOGの行を書き換える

RFC 1498の別の例では、表に「Lockheed DIALOG Serviceはノード5で動作中」と記されている。この文には、名前とサービス、名前「5」とノード、そしてサービスとノードという三つの対応がある。

簡単に変更するため表に置かれたのは最後の対応だけだった。DIALOGをノード6へ移しても、サービス名もノード名も変わらない。本当にサービスを改名するなら、プログラム、文書、メモ、広告まで変更しなければならない。

表の管理者は配置を変えられる。しかし、その操作権限からサービスの意味や所有、外部の法的効果を決める権限は導けない。可変な関係の管理と、対象そのものへの権威は別である。

親しみやすい名前が下の層を指す

ARPANET NCPの文字列名は、ノード名やサービス名らしく見えながら、実際には接続点を名付けていた。RADC-MulticsはIMP 18のポート0を指した。コンピュータを別ポートへ付け替えると、利用者が新しい名前を覚えるか、多数の表を変える必要があった。

メール機能は複数の計算機で代替できても、利用者は一見別のサービス名を入力しなければならないことがあった。冗長性はサービス層に存在したが、名前は接続点層に固定されていたからである。

一つのネームサーバーがサービス名から接続点を直接返せば、最初の二つの結合は機械的に一つに見える。分散ルーティングが経路を選べば、三つ目も見えない。しかし障害時には、サービス配置、ノード接続、経路のどこが変わったかを再び分けて調べる必要がある。

後の RFC 1958 はアプリケーションにハードコードされたアドレスを避け、名前を使うよう求めた。RFC 2101 はIPv4の識別子とロケータの要件を分け、同じフィールドの兼用を歴史上の偶然と呼んだ。RFC 2956 はノード同一性と配送位置の混同が生む問題を記録した。いずれも後世の比較材料であり、RFC 1498の内容を遡って変更するものではない。

RFC 1498自身はセキュリティを論じていない。経路にはノード内の活動やsocketの指定も必要であり、それでも認証、認可、応答、業務結果までは証明しない。

Heng LuのRunning-Code Primacy、Localized Future Decision、現実の層に関する論考に照らせば、共有記録は相互運用を支える最小の座標である。記録が対象になったり、稼働実態や継続的な統治権を生んだりするわけではない。

検証可能な履歴には、名前空間、照会時刻、全候補、配置と接続状態、経路方針、選択結果、socket、セッション、アプリケーション応答を残す必要がある。RFC 1498が教えるのは、名前を増やすことではない。省いた表がどの区別まで奪ったのかを忘れないことである。

情報源