要約

  • RFC 1188は、FDDIでIPとARPを扱うためにLLC/SNAP、4352オクテットのIP MTU、ブリッジされたEthernetと両立するARP表現を定めた。
  • プロトコル識別子、MACアドレス、ARPキャッシュ、フレームサイズ、受信フレームはリンク上の限定された事実であり、本人性、所有、許可、到達、アプリケーションの成功を単独では示さない。

リングが速くても、読み方は自明ではなかった

1990年10月のDavid KatzによるRFC 1188はRFC 1103を置き換え、FDDIでIPデータグラムとARPを送る方法を定めた。その発想はRFC 1042から明瞭に続く。まず異なる実装が同じリンク上で同じペイロード文法を読めなければならない。

type 1 LLCとSNAPの並びでは、AA-AA-03、ゼロの組織コード、続くプロトコル識別子が、下の内容をIPまたはARPとして解釈させる。これは受信器への構文上の指示である。署名ではない。EtherTypeがIPであっても、送信者がそのIPアドレスを保有すると証明しないし、遠隔のホストを操作する資格を発生させない。リンクが理解したことと、上位の主体が受け入れたことの間には、なお多くの判断がある。

4352はローカルな枠であった

RFC 1188はFDDIのIP MTUを4352オクテットとした。最大フレームはLLC/SNAP後におよそ4470オクテットを残せたが、MACヘッダとフレーム状態の変動・将来拡張のために余地を残した。ゲートウェイはこのMTUを受け入れ、必要なら断片化する。これはFDDI区間の予算であり、経路全体への予約ではない。

明示的に宛先能力を知っていないホストは576オクテットを越えるデータグラムを送ってはならない、という通常の境界も残る。RFC 1191が後に4352を歴史的なFDDIパスMTUとして掲げても、それは特定経路の観測ではない。最初のリンクで入ること、途中で断片化できること、宛先が受け入れること、アプリケーションが意味を処理することは別々の出来事である。

ARPが見つけたのは次ホップ表現だった

FDDIには16ビットと48ビットの局アドレスがあり得たが、RFC 1188はIPとARPには48ビットのみを用いるようにした。Ethernetとのブリッジ相互運用を妨げないため、ARPはハードウェア種別1で送信し、1または6を受信可能とし、アドレスをcanonical bit orderで運ぶ。FDDIで普段表示されるGroup bitの位置とは異なるため、ARP欄では各オクテットのビットを反転する。

これは表示形式の誤読を防ぐ規則である。ARPキャッシュは、ローカルな媒体でフレームを向ける先をIPアドレスから選ぶための対応表にすぎない。それは人の名前でも、資産台帳でも、相手が稼働中だという証明でもない。ARP応答の後にも、ブリッジ、経路、ホスト、TCP、アプリケーションはそれぞれ別に拒否・損失・変化を起こし得る。

後継RFCは現在を証明しない

RFC 1390は1993年のIP/ARP over FDDIのInternet Standard後継を記録する。これは文書史の事実であって、今日のFDDI利用、特定設備の実装、RFC 1188自身の現行性を示すものではない。

この文書の強さは、共有するものを小さく保った点にある。カプセル化は構文、ARPは局所対応、MTUは区間の上限を述べる。身元、権限、経路、到達結果には、それぞれ別の証拠が必要である。

情報源と証拠の境界

根拠はRFC 1042、RFC 1188、RFC 1191、RFC 1390である。これらは封入規則、歴史的MTU、文書の継承を示し、現在の導入、本人性、許可、実経路、配達、アプリ結果を示さない。