要約

  • ARPでリンク上のハードウェアアドレスを得ても、その相手が任意のカプセル化を理解する証明にはならない。トレーラー方式には別の受信能力通知があった。
  • 可変長の上位ヘッダーをデータの後ろに移す目的は、受信側がページ単位でデータを扱える条件を整えることだった。TCPの意味やアプリケーションのバイト順を変える方式ではない。
  • 1989年の要件は両端の対応確認を求め、宛先ごとの動的な交渉がなければ既定で無効にした。効率化を試す自由と、参加しない相手との互換性を両立させる境界だった。

返事が証明する範囲

同じケーブルにつながっていること、IPアドレスが分かること、Ethernetの宛先アドレスを得ること。それぞれ通信に必要な情報だが、どれも「相手がこちらの特別な形式を読める」という意味ではない。

1982年11月の RFC 826 で示されたARPは、選ばれたリンク上でプロトコルアドレスをハードウェアアドレスに対応させる。その前には経路と次の転送先を選ぶ判断がある。ARPが担うのは、あらゆる将来のフレーム形式を承認する仕事ではない。

この限界を具体的にした例が、トレーラーカプセル化だった。普通のIPを受け取れる機器でも、そのヘッダーをデータの後ろに置いたフレームをそのまま処理できるとは限らない。外側の宛先が正しくても、中の並べ方について合意がなければ通信は壊れる。

重要なのは、ARPが不十分な設計だったという結論ではない。一つの成功に、そこで確認していない能力まで読み込まないことである。

コピーを省くために、線上の並びを変える

1984年4月の RFC 893 は、当時4.2BSD UNIXなどで使われていたトレーラー方式を説明した。文書は情報提供であり、ARPA Internetの公式プロトコルではないと明記している。特定の受信処理に役立つリンクレベルの工夫が主題だった。

データはネットワークから届いた後も、機器とメモリーの間、あるいはOSと利用者のアドレス空間の間でコピーされ得る。ページ方式の仮想記憶を備える環境では、バイトをもう一度移す代わりにページの対応を変えられれば、その仕事の一部を省ける。

ただし、任意の長さのデータを任意の場所に置くだけでは成立しない。文書が論じる典型的な条件は、データの先頭がページ境界にそろい、長さもページ単位、または境界まで埋められた形になることだった。保護の単位やハードウェアによって前提は変わる。

ここで可変長ヘッダーが障害になる。リンク側の前置きが一定でも、その後に来るIPやTCPなどのヘッダーの長さが変われば、欲しいデータの先頭は一定の位置に収まらない。合わせ直すためにコピーすれば、狙っていた節約が失われる。

そこで送信側が可変部分を後ろへ回す。固定的なリンクの前置きに続けてデータを置き、元の上位ヘッダーは後尾に置く。この操作が受信側に与えるのは、適切にページを扱える機会であって、すべての機器でコピーがなくなる保証ではない。

データの後ろにある説明書

受信側が尾部を探すための情報は、カプセル化の一部として用意される。リンクの種類を示す情報から特別な形式と尾部への位置を認識し、尾部にある元のプロトコル種別やヘッダー長の情報を使って、上位ヘッダーを取り出す。

その後、受信コードは必要なリンク用情報を除き、ヘッダーがデータの前にある通常の形へ戻す。上位のプロトコルに渡る段階では、元の意味を持つパケットになっていなければならない。

従って、これはアプリケーションが説明抜きのデータを先に読めるようにする仕組みではない。別のパケットでヘッダーが後着するのでもない。ひとつのリンクパケット内の物理的な配置を変え、受信時に復元する。TCPの順序の意味はそこから独立している。

同じ1984年4月の RFC 894 が記述する通常のIP over Ethernetでは、IPヘッダーの直後にIPデータが続く。トレーラーは、その基準と区別して扱う任意の形式である。IPを運んでいるという共通点だけでは、復元手順の違いを消せない。

遅れて見えることにも値段がある

並び替えは無償ではない。RFC 893は、受信側が望み、かつ扱えること、境界を合わせる費用が節約を上回らないこと、移したヘッダーがデータに比べて小さいこと、コピー削減が実装の複雑さに見合うことを前提に挙げた。

VAXについて示した512バイトのデータの例も、その時代の計算条件を説明するものだ。現在のページサイズを一律に定める数字でも、すべてのTCP/IPヘッダーの長さを決める数字でもない。歴史上の実装で得られたという利点を、そのまま今日のベンチマーク結果にはできない。

また、ヘッダーが末尾にある以上、必要な情報を読むまでにパケット全体を受け取らなければならない。到着途中のヘッダーを使って早く拒否したり、受信資源を選んだりする実装には不利になる。

文書は種別の認識が遅れるという批判を認めている。そこで論じられたDMAの場合には、もともと全体を受信してから処理していた、という説明が続く。しかし、これはその条件での比較であり、あらゆるDMA機器が今も同じ動きをするという主張ではない。

送信側から見れば単なる順番の交換でも、受信側ではコピー、ページ対応、待ち時間、バッファーの使い方が変わる。受信者の意思を必要とする理由は、この費用の違いにある。

全員同じ、という仮定を外す

RFC 894は、同じEthernet上で合意したシステム同士がトレーラーを使うことを認めた一方、どのホストにも実装を義務付けなかった。送信する側には、受信者が解釈できると明確に知っていることを求めた。

1984年の記述にある4.2BSDは、起動時にインターフェースごとの選択を行う。共有する媒体の相手がそろって対応するか、そのインターフェースからはトレーラーを送らないかという粗い扱いだった。ARPを利用する相手ごとの交渉は、検討中、あるいは期待される変更として述べられた。

1989年10月の RFC 1122 第2.3.1節では、リンクの両端、ホストであれゲートウェイであれ、対応を確認した場合に限って使えるとした。宛先ごとの動的交渉がなければ、既定設定で無効にしなければならない。

この二つの時点から言えるのは、文書化された条件がインターフェース全体の仮定から個々の相手の確認へ具体化したことだ。最初の出荷日や、全BSD製品が一斉に移行した日まで示す証拠ではない。

普通の交換に、一つの通知を足す

RFC 1122が説明する交渉では、通常のIP用ARP交換を正常に完了させる。そのうえで、受信を望む側がTrailer ARP応答を追加する。通常のARP応答形式を使いつつ、ARP内部のプロトコル種別でトレーラーを示す。

ARPを運ぶ外側のEthernet種別、ARPの中のプロトコル欄、要求か応答かを示す操作コードは別のものだ。追加通知を新しいEthernetのARP要求と混同すると、交換の意味を読み違える。トレーラー用の要求を先に送ることが前提ではない。

通常の要求を受け取った側は、普通のIP応答と一緒に自分の受信能力を知らせられる。要求を出した側も、それに対応する普通の応答を受け取った際に通知できる。通知の主体が伝えるのは「自分が受け取れる」という方向の能力である。

使用する設定になっているホストは、受け取った通知を基に、例えばARPの項目へ相手の能力を記録できる。それは性能測定でも、アプリケーションデータの受領証でも、暗号による認証でもない。

範囲にも注意が要る。RFC 1009 の1987年6月のゲートウェイの説明では、proxy ARPによってゲートウェイがリンク外の到達可能な宛先について自分のインターフェースアドレスを返す場合がある。リンク上で知った相手の能力を、最終宛先や途中の全機器へ広げてはならない。

応答だけで会話を続けない

追加通知には停止の条件も必要だった。不適切な動作をするホストがTrailer ARP応答に普通のIP ARP応答を返すと、相手がすべてのIP応答に再び通知を返す実装なら、応答が応答を生む。

RFC 1122は、この分岐では普通のIP応答が未解決の要求に答えたときだけ追加通知を送るようにする。受信処理の前にはハードウェアアドレスがまだ分からなかった、という状態が判断を支える。受け取った要求に普通の応答と一緒に通知を付ける場合とは区別する。

外から来た一通の形だけでなく、その一通が解決する仕事が残っていたかを見る。新しいタイマーや認証手段を想像しなくても、記述された停止条件は理解できる。

一方、形式の不一致は常に全面停止として現れるわけではない。RFC 1122は、一定のサイズ属性を持つパケットだけが選ばれるため、一部は届き、一部は消える状態を指摘した。すべての大きなパケットが失敗するという意味ではなく、サイズに関係する損失だけで原因を断定することもできない。

並び替えとリンク容量も別だ。検証済みの訂正570 は、RFC 894の1500バイトについて「最小」を「最大」に直している。トレーラーを使うことは、通常のEthernetの容量制約を外す許可ではない。