3. Link Layer (リンク層)
3. Link Layer (リンク層)
[INTRO:1] はリンク層標準 (さまざまなリンク層上での IP の実装、ARP など) をカバーしていますが、この文書は、リンク層資料が別個のリンク層要件文書でカバーされることを予期しています。リンク層要件文書は、ホストとルーターの両方に適用されます。したがって、この文書は、リンク層の問題を扱う [INTRO:1] のセクションを廃止しません。
3.1 Introduction (はじめに)
ルーターは、本質的に他のタイプのインターネットシステムと同じリンク層プロトコル要件を持っています。これらの要件は、Requirements for Internet Gateways [INTRO:1] の第3章に記載されています。ルーターはその要件に従わなければならず (MUST)、その推奨事項に従うべきです (SHOULD)。その文書の一部の資料はやや古くなっているため、以下にいくつかの追加要件と説明が含まれています。
DISCUSSION (議論)
インターネットコミュニティが、この章と [INTRO:1] の「INTERNET LAYER PROTOCOLS」というタイトルの章に代わるインターネットリンク層要件標準を作成することが期待されています。
3.2 Link/Internet Layer Interface (リンク層/ネットワーク層インターフェイス)
この文書は、リンク層と上位層の間のインターフェイスを指定しようとはしません。ただし、この文書の他の部分、特に第5章では、さまざまなタイプの情報がこの層境界を越えて渡される必要があることに注意してください。
このセクションでは、次の定義を使用します:
Source physical address (ソース物理アドレス)
ソース物理アドレスは、パケットを受信したホストまたはルーターのリンク層アドレスです。
Destination physical address (宛先物理アドレス)
宛先物理アドレスは、パケットが送信されたリンク層アドレスです。
受信した各パケットについて、リンク層からネットワーク層に渡される必要がある情報は次のとおりです:
(1) IP パケット [5.2.2]
(2) リンク層フレームのデータ部分の長さ (つまり、リンク層フレームを除く) [5.2.2]
(3) IP パケットが受信された物理インターフェイスの識別 [5.2.3]、および
(4) リンク層ユニキャスト、ブロードキャスト、またはマルチキャストとしてのパケット宛先物理アドレスの分類 [4.3.2]、[5.3.4]
さらに、リンク層は次を提供すべきです (SHOULD):
(5) ソース物理アドレス
送信される各パケットについて、ネットワーク層からリンク層に渡される必要がある情報は次のとおりです:
(1) IP パケット [5.2.1]
(2) IP パケットの長さ [5.2.1]
(3) 宛先物理インターフェイス [5.2.1]
(4) ネクストホップ IP アドレス [5.2.1]
さらに、ネットワーク層は次を提供すべきです (SHOULD):
(5) リンク層優先度値 [5.3.3.2]
送信されるパケットがリンク層優先度関連のエラーを引き起こす場合、リンク層はネットワーク層に通知する必要があります [5.3.3.3]。
3.3 Specific Issues (具体的な問題)
3.3.1 Trailer Encapsulation (トレーラーカプセル化)
10メガビットイーサネットに接続できるルーターは、[LINK:1] で説明されているトレーラーカプセル化を使用するイーサネットパケットを受信および転送できます (MAY)。ただし、ルーターはトレーラーカプセル化されたパケットを開始してはなりません (SHOULD NOT)。ルーターは、[INTRO:2] で説明されているメカニズムを使用して、パケットの直接宛先がトレーラーカプセル化されたパケットを受け入れることができ、受け入れる意志があることを最初に確認せずに、トレーラーカプセル化されたパケットを開始してはなりません (MUST NOT)。ルーターは (これらのメカニズムを使用して) トレーラーカプセル化されたパケットを受け入れることに同意してはなりません (SHOULD NOT)。
3.3.2 Address Resolution Protocol - ARP (アドレス解決プロトコル)
ARP を実装するルーターは、[INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。
リンク層は、宛先に ARP キャッシュエントリがないという理由だけで、IP に宛先到達不能エラーを報告してはなりません (MUST NOT)。ARP 要求/応答シーケンスを実行している間、少数のデータグラムを一時的にキューに入れるべきであり (SHOULD)、これが無益であることが証明された場合にのみ、キューに入れられたデータグラムの1つに対して宛先到達不能で応答すべきです。
ルーターは、別のホストまたはルーターのリンク層アドレスがブロードキャストまたはマルチキャストアドレスであると主張する ARP 応答を信頼してはなりません (MUST NOT)。
3.3.3 Ethernet and 802.3 Coexistence (イーサネットと802.3の共存)
10メガビットイーサネットに接続できるルーターは、[INTRO:2] のイーサネット要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。
3.3.4 Maximum Transmission Unit - MTU (最大伝送単位)
各論理インターフェイスの MTU は、インターフェイスの正当な MTU 範囲内で構成可能でなければなりません (MUST)。
多くのリンク層プロトコルは、送信できる最大フレームサイズを定義しています。この場合、ルーターは、リンク層プロトコルが許可するよりも大きいフレームを送信できるような MTU の設定を許可してはなりません (MUST NOT)。ただし、ルーターは、MTU よりも大きい場合でも、最大フレームサイズと同じくらい大きいパケットを受信できるようにすべきです (SHOULD)。
DISCUSSION (議論)
これは、[INTRO:2] がホストに課すよりも厳しい要件であることに注意してください。[INTRO:2] は、各物理インターフェイスの MTU が構成可能であることを要求しています。
ネットワークがリンク層の最大フレームサイズよりも小さい MTU を使用している場合、ルーターは、構成が不適切で完全に初期化されていないホストから、MTU よりも大きいパケットを受信する可能性があります。堅牢性の原則は、可能であれば、ルーターがこれらのパケットを正常に受信すべきであることを示しています。
3.3.5 Point-to-Point Protocol - PPP (ポイントツーポイントプロトコル)
[INTRO:1] とは対照的に、インターネットには実際に標準のポイントツーポイント回線プロトコルがあります: Point-to-Point Protocol (PPP、ポイントツーポイントプロトコル)、[LINK:2]、[LINK:3]、[LINK:4]、および [LINK:5] で定義されています。
ポイントツーポイントインターフェイスは、ポイントツーポイント回線を介してデータを送信するように設計されたインターフェイスです。このようなインターフェイスには、電話、リース、専用、または直接回線 (2線または4線) が含まれ、ポイントツーポイントチャネルまたは多重化インターフェイスの仮想回路 (ISDN など) を使用できます。通常、標準化されたモデムまたはビットシリアルインターフェイス (RS-232、RS-449、または V.35 など) を使用し、同期または非同期クロックを使用します。多重化インターフェイスには通常、特別な物理インターフェイスがあります。
汎用シリアルインターフェイスは、ポイントツーポイント回線と同じ物理メディアを使用しますが、リンク層ネットワークとポイントツーポイント接続の使用をサポートします。リンク層ネットワーク (X.25 やフレームリレーなど) は、代替 IP リンク層仕様を使用します。
ポイントツーポイントまたは汎用シリアルインターフェイスを実装するルーターは、PPP を実装しなければなりません (MUST IMPLEMENT)。
ルーター上のすべての汎用シリアルインターフェイスは、PPP をサポートしなければなりません (MUST)。ルーターは、PPP 以外のポイントツーポイント回線プロトコルを使用するように回線を構成できるようにすることができます (MAY)。ポイントツーポイントインターフェイスは、有効にされたときにデフォルトで PPP を使用するか、有効にする前にリンク層プロトコルの構成を要求すべきです (SHOULD)。汎用シリアルインターフェイスは、有効にする前にリンク層プロトコルの構成を要求すべきです (SHOULD)。
3.3.5.1 Introduction (はじめに)
このセクションは、ルーター実装者に、同期または非同期リンクを介して PPP を使用する他のルーターとの相互運用性を確保できるようにガイダンスを提供します。
実装者がオプション交渉メカニズムのセマンティクスを理解することは非常に重要です。オプションは、ローカルデバイスがリモートピアから受け入れるものをリモートピアに示す方法であり、送信したいものではありません。リモートピアは、ローカルデバイスが受け入れることができると述べたオプションセットの範囲内で、最も便利なものを送信することを決定できます。したがって、リモートピアが LCP Configuration Request (CR) で示されたすべてのオプションを ACK することは完全に受け入れられ、正常です。たとえリモートピアがこれらのオプションのいずれもサポートしていない場合でも。繰り返しますが、オプションは、どちらかの当事者のデバイスが受け入れるものをピアに示すメカニズムであり、必ずしも送信するものではありません。
3.3.5.2 Link Control Protocol (LCP) Options (リンク制御プロトコルオプション)
PPP Link Control Protocol (LCP、リンク制御プロトコル) は、交渉できる多くのオプションを提供します。これらのオプションには、アドレスおよび制御フィールド圧縮、プロトコルフィールド圧縮、非同期文字マッピング、Maximum Receive Unit (MRU、最大受信単位)、Link Quality Monitoring (LQM、リンク品質監視)、マジックナンバー (ループバック検出用)、Password Authentication Protocol (PAP、パスワード認証プロトコル)、Challenge Handshake Authentication Protocol (CHAP、チャレンジハンドシェイク認証プロトコル)、および32ビット Frame Check Sequence (FCS、フレームチェックシーケンス) が含まれます (ただし、これらに限定されません)。
ルーターは、同期または非同期リンク上でアドレス/制御フィールド圧縮を使用できます (MAY)。ルーターは、同期または非同期リンク上でプロトコルフィールド圧縮を使用できます (MAY)。これらの圧縮を受け入れることができることを示すルーターは、圧縮されていない PPP ヘッダー情報も受け入れることができなければなりません (MUST)。
DISCUSSION (議論)
これらのオプションは、PPP ヘッダーの外観を制御します。通常、PPP ヘッダーは、アドレス、制御フィールド、およびプロトコルフィールドで構成されます。ポイントツーポイント回線上のアドレスは 0xFF で、「ブロードキャスト」を表します。制御フィールドは 0x03 で、「番号なし情報」を表します。Protocol Identifier は2バイトの値で、フレームデータ領域の内容を示します。システムがアドレスおよび制御フィールド圧縮を交渉する場合、ヘッダーの前にこれらのフィールドがある場合とない場合の PPP フレームを受け入れることをピアに示します。送信者がこれらのフィールドを削除したフレームを送信することを意味するものではありません。
プロトコルフィールド圧縮を交渉する場合、合法である場合にプロトコルフィールドが1バイトに圧縮された状態で受信することをシステムが喜んで受け入れることを示します。送信者がそうする必要はありません。
アドレス/制御フィールド圧縮の使用は、番号モード (信頼性のある) PPP の使用と矛盾します。
IMPLEMENTATION (実装)
一部のハードウェアは、可変長ヘッダー情報をうまく処理できません。この場合、リモートピアが完全な PPP ヘッダーを送信することが最も理にかなっています。実装は、リモートピアにアドレス/制御フィールドおよびプロトコルフィールド圧縮オプションを送信しないことによって、これを保証できます。リモートピアが圧縮ヘッダーを受け入れることができることを示している場合でも、ローカルルーターが圧縮ヘッダーを送信する必要はありません。
ルーターは、非同期 PPP リンクの Asynchronous Control Character Map (ACCM、非同期制御文字マップ) を交渉しなければなりませんが (MUST)、同期リンクの ACCM を交渉してはなりません (SHOULD NOT)。ルーターが同期リンク上で ACCM を交渉しようとする要求を受信した場合、そのオプションを確認 (ACKnowledge) してから無視しなければなりません (MUST)。
DISCUSSION (議論)
一部の実装は、同じコードを使用してオプション交渉を実装する、同期および非同期動作モードを提供します。この場合、一方または他方が同期リンク上で ACCM オプションを送信する可能性があります。
ルーターは、maximum receive unit (MRU、最大受信単位) を正しく交渉すべきです (SHOULD)。システムが1,500バイト未満の MRU を交渉した場合でも、1,500バイトのフレームを受信できなければなりません (MUST)。
ルーターは、link quality monitoring (LQM、リンク品質監視) オプションを交渉して有効にすべきです (SHOULD)。
DISCUSSION (議論)
このメモは、リンク品質が十分かどうかを決定するためのポリシーを指定していません。ただし、ルーターが障害のあるリンクを無効にすることが重要です (セクション [3.3.6] を参照)。
ルーターは、ループバック検出用の magic number (マジックナンバー) オプションを実装して交渉すべきです (SHOULD)。
ルーターは、認証オプション (PAP - Password Authentication Protocol パスワード認証プロトコル、および/または CHAP - Challenge Handshake Authentication Protocol チャレンジハンドシェイク認証プロトコル) をサポートできます (MAY)。
ルーターは、16ビット CRC frame check sequence (FCS、フレームチェックシーケンス) をサポートしなければならず (MUST)、32ビット CRC をサポートできます (MAY)。
3.3.5.3 IP Control Protocol (IPCP) Options (IP 制御プロトコルオプション)
ルーターは、IP アドレス交渉を実行することを提供できます (MAY)。ルーターは、ピアからの IP アドレス交渉の実行の拒否 (REJect) を受け入れなければなりません (MUST)。
19,200 BPS 以下のリンク速度で動作するルーターは、Van Jacobson ヘッダー圧縮を実装して実行することを提供すべきです (SHOULD)。VJ 圧縮を実装するルーターは、それを有効または無効にする管理制御を実装すべきです (SHOULD)。
3.3.6 Interface Testing (インターフェイステスト)
ルーターは、ルーティングソフトウェアが物理インターフェイスがパケットを送信できる状態にあるかどうかを判断できるメカニズムを持っていなければなりません (MUST)。限られた隣接セット用の永続的な仮想回路を開く多重化インターフェイスでは、ルーターは仮想回路が実行可能かどうかも判断できなければなりません。ルーターは、ルーティングソフトウェアが物理インターフェイスの品質を判断できるメカニズムを持つべきです (SHOULD)。ルーターは、管理操作の結果として物理インターフェイスがパケットの送信に使用可能または使用不可能になったときにルーティングソフトウェアに通知するメカニズムを持っていなければなりません (MUST)。ルーターは、リンクレベルのインターフェイスが何らかの理由で使用可能または使用不可能になったことを検出したときにルーティングソフトウェアに通知するメカニズムを持っていなければなりません (MUST)。
DISCUSSION (議論)
ルーターが、ネットワーク接続が正常に動作しているかどうかを判断するための動作するメカニズムを持つことは非常に重要です。リンクの喪失を検出できなかったり、問題が検出されたときに適切な措置を講じなかったりすると、ブラックホールが発生する可能性があります。
ネットワーク接続の問題を検出するために使用できるメカニズムは、使用されるリンク層プロトコルとインターフェイスハードウェアによって大きく異なります。目的は、リンク層の制約内で障害を検出する能力を最大化することです。