メインコンテンツまでスキップ

2. リンク層 (LINK LAYER)

2.1 はじめに (INTRODUCTION)​

すべてのインターネットシステム（ホストもゲートウェイも）は、リンク層プロトコルに対して同じ要件を持つ。これらの要件は「インターネットゲートウェイ要件」[INTRO:2] の第 3 章に記載されており、本節により補足される。

2.2 プロトコルウォークスルー (PROTOCOL WALK-THROUGH)​

なし (None)。

2.3 個別課題 (SPECIFIC ISSUES)​

2.3.1 トレーラプロトコルネゴシエーション (Trailer Protocol Negotiation)​

リンク層カプセル化のトレーラプロトコル [LINK:1] は使用してもよい (MAY) が、リンク層通信に参加する 2 つのシステム（ホストまたはゲートウェイ）の両方がトレーラを実装していることが検証された場合にのみ使用してよい。システムが宛先アドレスごとにトレーラプロトコルの使用を動的にネゴシエートしない場合、デフォルト設定では当該プロトコルを無効にしなければならない (MUST)。

DISCUSSION (議論)：

トレーラプロトコルは、物理ネットワーク上で送信されるパケットのデータ内容を並べ替えるリンク層カプセル化技術である。一部の環境では、トレーラは上位層プロトコルのスループットを向上させるが、それはオペレーティングシステム内部のデータコピー量を減らすことによる。上位層プロトコルはトレーラの使用を認識しないが、トレーラを使用する場合、送信側と受信側の両ホストがそのプロトコルを理解しなければならない (MUST)。

トレーラを不適切に使用すると、非常に紛らわしい症状を引き起こす。特定のサイズ属性を持つパケットのみがトレーラカプセル化を使用し、通常、交換されるパケットのうちその属性を持つものはわずかである。したがって、トレーラを使用するシステムが使用しないシステムとパケットを交換する場合、一部のパケットはブラックホールに消え、他のパケットは正常に配信される。

IMPLEMENTATION (実装)：

イーサネット上では、トレーラカプセル化されたパケットは異なるイーサネットタイプ [LINK:1] を使用し、トレーラネゴシエーションは、ARP を使用して宛先システムのリンク層アドレスを発見するときに実行される。

具体的には、ARP 交換は通常の IP プロトコルタイプを使用して通常の方法で実行されるが、トレーラを使用したいホストは、追加の「トレーラ ARP 応答 (trailer ARP reply)」パケット、すなわちトレーラカプセル化プロトコルタイプを指定し、それ以外は通常の ARP 応答と同じ形式の ARP 応答を送信する。トレーラを使用するように設定されたホストがリモートマシンからトレーラ ARP 応答メッセージを受信した場合、そのマシンをトレーラを理解するマシンのリストに追加できる（たとえば、ARP キャッシュ内の対応するエントリにマークするなど）。

トレーラカプセル化されたパケットを受信したいホストは、IP の通常の ARP メッセージ交換を完了するたびにトレーラ ARP 応答を送信する。したがって、その IP プロトコルアドレス宛ての ARP 要求を受信したホストは、通常の IP ARP 応答に加えてトレーラ ARP 応答を送信する。IP ARP 要求を送信したホストは、対応する IP ARP 応答を受信するときにトレーラ ARP 応答を送信する。このようにして、IP ARP 交換の要求側と応答側の両方のホストがトレーラカプセル化の受信を要求できる。

この方式は、トレーラプロトコルタイプに対して ARP 要求を送信する代わりに、追加のトレーラ ARP 応答パケットを使用する。その目的は、いかなる仕様や常識にも反する (behaving contrary to any specification or common sense) ホストが、トレーラの ARP 応答に対して別の IP の ARP 応答で応答することによる、ホストとの継続的な ARP パケット交換を回避することである。この問題は、未処理の要求に対する IP ARP 応答を受信したときにのみトレーラ ARP 応答を送信することで回避される。すなわち、IP ARP 応答を受信したときにホストのハードウェアアドレスがまだ不明な場合である。トレーラ ARP 応答は、IP ARP 要求に応答する IP ARP 応答とともに常に送信できる。

2.3.2 アドレス解決プロトコル -- ARP (Address Resolution Protocol -- ARP)​

2.3.2.1 ARP キャッシュの検証 (ARP Cache Validation)​

アドレス解決プロトコル (ARP) [LINK:2] の実装は、古いキャッシュエントリをクリアするメカニズムを提供しなければならない (MUST)。そのメカニズムがタイムアウトを含む場合、タイムアウト値は設定可能であるべきである (SHOULD)。

同じ IP アドレスに対する ARP 要求を高速で繰り返し送信する ARP フラッド（ARP flood）を防ぐメカニズムを備えなければならない (MUST)。推奨される宛先ごとの最大レートは 1 秒あたり 1 回である。

DISCUSSION (議論)：

ARP 仕様 [LINK:2] はタイムアウトメカニズムを推奨するが必須とはしておらず、ホストがイーサネットアドレスを変更したときにキャッシュエントリを無効にする。プロキシ ARP（[INTRO:2] の 2.4 節参照）の普及は、ホストのキャッシュエントリが無効になる可能性を著しく高めたため、ホストには何らかの ARP キャッシュ無効化メカニズムが必要である。プロキシ ARP が存在しない場合でも、長いキャッシュタイムアウト周期は、キャッシュされた誤った ARP データを自動的に修正するのに有用である。

IMPLEMENTATION (実装)：

古いキャッシュエントリをクリアするために、単独または組み合わせて使用される 4 つのメカニズムがある。

(1) タイムアウト (Timeout) —— 使用されていても定期的にキャッシュエントリをタイムアウトさせる。キャッシュエントリが「更新 (refreshed)」されたとき（関連するシステムからの ARP ブロードキャストのソースフィールドを、ターゲットアドレスに関わらず観察することによって）、そのタイムアウトは再開されるべきである。プロキシ ARP の場合、タイムアウトは約 1 分のオーダーである必要がある。

(2) ユニキャストポーリング (Unicast Poll) —— リモートホストへのポイントツーポイント ARP 要求を定期的に送信して能動的にポーリングし、N 回連続して ARP 応答がない場合、そのエントリを削除する。同様に、タイムアウトは約 1 分のオーダーであるべきであり、通常 N は 2 である。

(3) リンク層からの助言 (Link-Layer Advice) —— リンク層ドライバが配信問題を検出した場合、対応する ARP キャッシュエントリをクリアする。

(4) より上位層からの助言 (Higher-layer Advice) —— インターネット層からリンク層への呼び出しを提供し、配信問題を示す。この呼び出しの作用は、対応するキャッシュエントリを無効にすることである。この呼び出しは、トランスポート層からインターネット層への「ADVISE_DELIVPROB()」呼び出し（第 3.4 節参照）に類似しており、実際、ADVISE_DELIVPROB ルーチンがリンク層助言ルーチンを呼び出して ARP キャッシュエントリを無効にする場合がある。

方法 (1) と (2) は、約 1 分以下の ARP キャッシュタイムアウトを伴う。プロキシ ARP がない場合、このような短いタイムアウトは、非常に大きなイーサネット上で顕著なオーバーヘッドトラフィックを生成する可能性がある。したがって、ARP キャッシュタイムアウトを長くするようにホストを設定する必要があるかもしれない。

2.3.2.2 ARP パケットキュー (ARP Packet Queue)​

リンク層は、同じ未解決の IP アドレス宛ての各グループのパケットのうち少なくとも 1 つ（最新のもの）を保存（破棄せず）し、アドレスが解決された後に保存したパケットを送信すべきである (SHOULD)。

DISCUSSION (議論)：

この助言に従わないと、交換される最初のパケットが毎回失われる。上位層プロトコルは通常、パケット損失を再送により処理できるが、パケット損失は確かにパフォーマンスに影響する。たとえば、TCP オープン要求を失うと、初期往復時間推定が誇張される。UDP ベースのアプリケーション（ドメインネームシステムなど）はより深刻な影響を受ける。

2.3.3 イーサネットと IEEE 802 のカプセル化 (Ethernet and IEEE 802 Encapsulation)​

イーサネット上の IP カプセル化は RFC-894 [LINK:3] で記述され、RFC-1042 [LINK:4] は IEEE 802 ネットワーク上の IP カプセル化を記述している。RFC-1042 は [INTRO:2] の 3.4 節の議論を詳述し、置き換えるものである。

10Mbps イーサネットケーブルに接続された各インターネットホスト：

  • RFC-894 カプセル化を使用してパケットを送受信できること (MUST)；
  • RFC-1042 パケットを受信し、RFC-894 パケットと混在できるべきである (SHOULD)；かつ
  • RFC-1042 カプセル化を使用してパケットを送信してもよい (MAY)。

RFC-894 と RFC-1042 の両方のカプセル化を送信するホストを実装する場合、送信するカプセル化を選択する設定スイッチを提供しなければならず (MUST)、そのスイッチは RFC-894 をデフォルトとしなければならない (MUST)。

IEEE が IP 用に予約したプロトコル id 値 (K1=6) は、RFC-1042 の標準 IP カプセル化では使用されないことに注意されたい。代わりに、（K1=170 で、Ether-Type フィールドを保持できることを示す）拡張（「SNAP」）を示唆する値が使用される。インターネットシステムは、K1=6 を使用する 802 パケットを送信してはならない (MUST NOT)。

イーサネットおよび IEEE 802 ネットワーク上の、インターネットアドレスからリンク層アドレスへの変換は、アドレス解決プロトコル (ARP) によって管理されなければならない (MUST)。

イーサネットの MTU は 1500 であり、802.3 の MTU は 1492 である。

DISCUSSION (議論)：

IEEE 802.3 仕様は、10Mbps イーサネットケーブル上での動作を規定しており、この場合イーサネットと 802.3 フレームは物理的に混在できる。受信側は、802.3 長フィールドの値によってイーサネットと 802.3 フレームを区別できる。この 2 バイトフィールドは、ヘッダ内でイーサネットフレームの Ether-Type フィールドと同じ位置にある。具体的には、802.3 長フィールドは 1500 以下でなければならず、有効なすべての Ether-Type 値は 1500 より大きい。

別の互換性の問題は、リンク層ブロードキャストにある。あるフレーム形式で送信されたブロードキャストは、別のフレーム形式のみを受信できるホストには見えない。

本節の規定は、同じケーブル上で 894 対応システムと 1042 対応システムの間で直接の相互運用を可能にすることを目的としている。その目的は、現在 894 のみのシステムが主流である状況を支援し、1042 システムが普及する将来へのスムーズな移行を提供することである。

894 のみのシステムは 1042 のみのシステムと直接相互運用できないことに注意されたい。これらの 2 つのシステムタイプが同じケーブル上の 2 つの異なる論理ネットワークとして設定されている場合、IP ゲートウェイを介してのみ通信できる。さらに、リンク層ブロードキャストの問題により、両形式を自動的に送信すべき形式を検出することは無用であり、不可能でもある。

2.4 リンク/インターネット層インタフェース (LINK/INTERNET LAYER INTERFACE)​

IP 層とリンク層の間のパケット受信インタフェースは、着信パケットがリンク層ブロードキャストアドレス宛てかどうかを示すフラグを含まなければならない (MUST)。

DISCUSSION (議論)：

IP 層は通常リンク層アドレスを認識しない（異なるネットワークメディアごとに異なるアドレス形式がある可能性があるため）。ただし、ブロードキャスト機能を持つメディア上のブロードキャストアドレスは重要な特例である。第 2.4 節、特にブロードキャストストームの議論を参照。

IP とリンク層の間のパケット送信インタフェースは、5 ビットの TOS フィールド（第 3.2.1.6 節参照）を含まなければならない (MUST)。

リンク層は、ある宛先アドレスに ARP キャッシュエントリがないという理由だけで、IP に「宛先到達不能 (Destination Unreachable)」エラーを報告してはならない (MUST NOT)。

特性 (Feature)節 (Section)MUSTSHOULDMAYSHOULD NOTMUST NOT
トレーラカプセル化 (Trailer encapsulation)2.3.1x
ネゴシエーションなしでのトレーラ送信デフォルト (Send Trailers by default without negotiation)2.3.1x
ARP2.3.2
古い ARP キャッシュエントリのフラッシュ (Flush out-of-date ARP cache entries)2.3.2.1x
ARP フラッドの防止 (Prevent ARP floods)2.3.2.1x
キャッシュタイムアウト設定可能 (Cache timeout configurable)2.3.2.1x
未解決パケットの少なくとも 1 つ（最新）を保存 (Save at least one (latest) unresolved pkt)2.3.2.2x
イーサネットと IEEE 802 カプセル化 (Ethernet and IEEE 802 Encapsulation)2.3.3
ホストが可能：(Host able to:)2.3.3
- RFC-894 カプセル化の送受信 (- Send & receive RFC-894 encapsulation)2.3.3x
- RFC-1042 カプセル化の受信 (- Receive RFC-1042 encapsulation)2.3.3x
- RFC-1042 カプセル化の送信 (- Send RFC-1042 encapsulation)2.3.3x
設定スイッチで選択、デフォルト RFC-894 (Then config. sw. to select, RFC-894 dflt)2.3.3x
K1=6 カプセル化の送信 (Send K1=6 encapsulation)2.3.3x
イーサネットと IEEE 802 ネットワークで ARP 使用 (Use ARP on Ethernet and IEEE 802 nets)2.3.3x
リンク/インターネット層インタフェース (Link/Internet Layer Interface)2.4
リンク層から IP 層へのブロードキャスト報告 (Link layer report b'casts to IP layer)2.4x
IP 層からリンク層への TOS 受け渡し (IP layer pass TOS to link layer)2.4x
ARP キャッシュエントリなしを宛先到達不能とみなす (No ARP cache entry treated as Dest. Unreach.)2.4x

参考文献 (References):

  • [LINK:1] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893, Univ. of California at Berkeley, April 1984.
  • [LINK:2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
  • [LINK:3] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC-894, April 1984.
  • [LINK:4] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, February 1988.