3. インターネット層プロトコル (INTERNET LAYER PROTOCOLS)
3.1 はじめに (INTRODUCTION)
すべてのインターネットホストは、IP、ICMP、および（少なくとも制限された形で）IGMP を実装しなければならない。
DISCUSSION (議論)：
IP および ICMP について、本覚書は RFC-791、RFC-792、および RFC-950 のホスト仕様を修正し補足するとともに、その中のいくつかの重要点を再叙述する。IGMP について、本覚書はそのホスト側の要件を規定し、IGMP プロトコル自体は RFC-1112 [IP:4] で定義されている。
複数のホストをホストする（第 3.3.4 節参照）ホストは、複数のインタフェースから到着する着信データグラムを正しく処理できなければならず、また外出データグラムの送信元アドレスとして任意のアドレスを使用できなければならない。
IP 層とトランスポート層の間のインタフェースは、IP 層のすべてのメカニズムへの完全なアクセスを提供しなければならない。第 3.4 節を参照。
インターネット層プロトコル IP、ICMP、および IGMP については第 3 章で論じる。
3.2 プロトコルウォークスルー (PROTOCOL WALK-THROUGH)
本節では、IP、ICMP、および IGMP のプロトコル仕様文書を節ごとに検討し、誤りを修正し、曖昧または定義が不十分な要件を記述する。
3.2.1 インターネットプロトコル -- IP (Internet Protocol -- IP)
3.2.1.1 バージョン (Version)
IP ヘッダのバージョンフィールド（VERSION）が 4 に等しいことを検証しなければならない (MUST)。バージョンが 4 でない場合、静粛にそのデータグラムを破棄しなければならない (MUST)。ICMP パラメータ問題メッセージを生成してもよい (MAY)。
3.2.1.2 ヘッダチェックサム (Header Checksum)
着信 IP データグラムのヘッダチェックサム（HEADER CHECKSUM）を検証しなければならない (MUST)。チェックサムが誤っている場合、静粛にそのデータグラムを破棄しなければならない (MUST)。
DISCUSSION (議論)：
チェックサムは、伝送中に発生したヘッダのエラーを捕捉するために使用される。これは、TCP や UDP などの上位層プロトコルにおけるエンドツーエンドのチェックサムとは異なることに注意。
3.2.1.3 アドレス (Addresses)
(1) 送信元アドレス (Source Address)
着信データグラムの送信元アドレス（SOURCE ADDRESS）がブロードキャストまたはマルチキャストアドレスでないことを検証しなければならない (MUST)。そうでない場合、静粋にそのデータグラムを破棄しなければならない (MUST)。
(2) 宛先アドレス (Destination Address)
データグラムは、IP ネットワーク、サブネット、またはホストに宛てることができる。ホストに宛てる IP アドレスは「特定の宛先アドレス (specific-destination address)」と呼ばれる。特定の宛先アドレスは、ホストの IP アドレス、あるいはブロードキャストまたはマルチキャストアドレスのいずれかである（第 3.3.6 節および第 3.3.7 節参照）。
IP データグラムの宛先アドレスは、4 つの標準的な IP ブロードキャストアドレス形式のいずれかであってもよい (MAY)：
(a) {ネットワーク番号, -1} 指向ブロードキャスト (Directed Broadcast)
(b) {ネットワーク番号, サブネット番号, -1} サブネット指向ブロードキャスト (Subnet Directed Broadcast)
(c) {ネットワーク番号, -1, -1} 全サブネット指向ブロードキャスト (All-Subnets Directed Broadcast)
(d) {-1, -1} 限定ブロードキャスト (Limited Broadcast)
ここで "-1" は、対応するフィールドのすべてのビットが 1 であることを示す。このようなアドレスを「ブロードキャストアドレス (broadcast address)」と呼ぶ。ネットワーク番号およびサブネット番号フィールドの具体的な解釈は RFC-950 [IP:3] を参照。
ホストは、着信データグラムの宛先アドレスにおける上記のいずれかのブロードキャスト形式を認識しなければならない (MUST)。さらに、非標準のブロードキャストアドレス形式として 0 ではなく -1 を使用するホストクラス（例：4.2BSD Unix およびその派生システムだが、4.3BSD は除く）について、ホストはこれらの非標準ブロードキャストアドレスを認識して受け入れるべきである (SHOULD)。
ホストは、自身の IP アドレス、有効なブロードキャストアドレス、またはマルチキャストアドレス宛てでない着信データグラムを静粋に破棄しなければならない (MUST)。ただし、ホストがデータグラムを転送するゲートウェイとして機能する場合（第 3.3.5 節参照）、その処理はここでの規定とは異なる（[INTRO:2] を参照）。
ホストがリンク層ブロードキャストアドレス（第 2.4 節参照）宛てに送信されたデータグラムを受信したが、その IP 宛先アドレスが有効な IP ブロードキャストまたはマルチキャストアドレスでない場合、静粋にそのデータグラムを破棄すべきである (SHOULD)。
DISCUSSION (議論)：
上記の規則 (1) および (2) を組み合わせることで、ホストが以下のいずれかのデータグラムを受け入れることを防ぐ：無効な宛先アドレス、無効な送信元アドレス、または送信元がブロードキャスト/マルチキャストアドレスであるデータグラム。特に、これにより「Land」型攻撃（送信元アドレスが宛先アドレスと等しいデータグラム）を防ぐことができる。
特定の宛先アドレスの概念は、データグラムの真の宛先アドレス（ブロードキャストやマルチキャストであっても）と、IP 宛先アドレスフィールドの値がローカルネットワーク上でどのように解釈されるかの違いを区別するために使用される。
(3) サブネットアドレッシング (Subnet Addressing)
ホストは、RFC-950 [IP:3] で定義されているサブネットアドレッシングを実装しなければならない (MUST)。つまり、アドレスマスク（ADDRESS MASK）を使用して、IP 宛先アドレスのどのビットがネットワーク/サブネットを識別し、どのビットがホストを識別するかを決定する。
(4) 無効な送信元アドレス (Invalid Source Address)
IP 層は、着信データグラムをトランスポート層に上位へ渡す前に、送信元アドレスフィールドをチェックしなければならない (MUST)。送信元アドレスが 0、ブロードキャストアドレス、またはマルチキャストアドレスの場合、静粋にそのデータグラムを破棄しなければならない (MUST)。
3.2.1.4 再構成 (Reassembly)
IP 層は、着信 IP データグラムの再構成を実装しなければならない (MUST)（第 3.3.2 節参照）。
3.2.1.5 識別フィールド (Identification)
ホストが識別（IDENTIFICATION）フィールドを使用しない場合、送出データグラムにおいてそのフィールドをゼロに設定してもよい (MAY)、または何らかの局所的に一意な値に設定してもよい (MAY)。同一のデータグラムの複数のコピー間で、同じ識別フィールド値を保持することを避けるべきである (SHOULD)。
DISCUSSION (議論)：
識別フィールドは、データグラムの異なるコピー（例：ソースルーティングにより複数回送信されたもの）を区別するために使用される。同じデータグラムが複数回送信され、識別フィールドが変わらない場合、受信側がそれを重複したフラグメントと誤って破棄する可能性がある。
3.2.1.6 サービスタイプ (Type-Of-Service)
IP ヘッダには、前述のサービスタイプ（TOS）フィールドが含まれる。トランスポート層は、送出データグラムの TOS 値を設定できなければならない (MUST)。その値は IP 層に透過的に渡されなければならない (MUST)。受信した TOS 値をトランスポート層に渡すべきである (SHOULD)。
IP 層が RFC-795 [IP:13] で定義されたリンク層マッピングを実装している場合、これらのマッピングを使用して送出データグラムのリンク層優先度またはサービスクラスを選択してもよい (MAY)。
DISCUSSION (議論)：
TOS フィールドの現在の実装は、グローバルインターネットではまだ広く使用されていないが、ホストはこのフィールドの設定をサポートすべきである。これにより、これらのメカニズムが有効な場合に即座に機能するようになる。
3.2.1.7 生存時間 (Time-To-Live)
送出データグラムの TTL（生存時間）フィールドは、送信側によって設定されなければならない (MUST)。TTL が 0 のデータグラムを送信してはならない (MUST NOT)。TTL が 2 未満の受信データグラムを破棄してはならない (MUST NOT)（TTL を減算し 0 になった場合にのみゲートウェイが破棄する）。
生存時間はトランスポート層によって設定可能でなければならず (MUST)、その値は IP 層に透過的に渡されなければならない (MUST)。固定の TTL 値は設定可能でなければならない (MUST)。
3.2.1.8 IP オプション (IP Options)
(1) オプション処理の一般原則 (General Option Processing)
IP 層は、送出データグラムで送信される IP オプションをトランスポート層が指定できるようにしなければならず (MUST)、また受信したすべての IP オプションを上位層に透過的に渡さなければならない (MUST)。IP 層は、理解できないオプションを静粋に無視しなければならない (MUST)。
IP 層が理解できないが長さフィールドを持つ IP オプションを受信した場合、そのオプションをスキップしてヘッダの処理を続行しなければならない (MUST)。オプションの長さフィールドがゼロであるか範囲外を指している場合、エラーとして処理しなければならない (MUST)（例：ICMP パラメータ問題メッセージを送信するなど）。
(2) オプション形式 (Option Format)
各 IP オプションの形式の詳細は RFC-791 を参照。
(3) ソースルートオプション (Source Route Option)
ホストは、ソースルート（SOURCE ROUTE）オプションを開始および終端できるようにしなければならない (MUST)。つまり、ホストは送出データグラムにソースルートオプションを挿入でき、かつ着信データグラムのソースルートオプションを処理できなければならない。
ソースルートオプションを伴い、まだ完了していない着信データグラムを受信した場合、ホストはそのデータグラムをトランスポート層に上位へ渡さなければならない (MUST)（完了したソースルートはトランスポート層で処理されるため）。ソースルートが完了している場合、完了マーク付きのデータグラムをトランスポート層に渡さなければならない (MUST)。
ホストがデータグラムをゲートウェイとして転送する場合（第 3.3.5 節参照）、ゲートウェイ仕様に従ってソースルートオプションを更新し、正しい（冗長のない）リターンルートを構築しなければならない (MUST)。
1 つの IP ヘッダに複数のソースルートオプションを含めてもよい (MAY)。
(4) レコードルートオプション (Record Route Option)
ホストは、送出データグラムにレコードルート（RECORD ROUTE）オプションを挿入してもよい (MAY)、また着信データグラムの当該オプションを処理してもよい (MAY)。このオプションのサポートが要求されるホストの場合、その IP 層は RFC-791 の規定に従って当該オプションを正しく更新しなければならない (MUST)。
(5) タイムスタンプオプション (Time Stamp Option)
ホストは、送出データグラムにタイムスタンプ（TIME STAMP）オプションを挿入してもよく (MAY)、着信データグラムの当該オプションを正しく処理してもよい (MAY)。
(6) ストリーム識別子オプション (Stream Identifier Option)
ホストは、ストリーム識別子（STREAM IDENTIFIER）オプションを送信してもよく (MAY)、受信した当該オプションを静粋に無視しなければならない (MUST)（このオプションは廃止されているため）。
(7) セキュリティオプション (Security Option)
ホストは、IP セキュリティ（SECURITY）オプション [IP:8] を実装してもよい (MAY)。実装する場合、その処理は RFC-791 および RFC-1108 に準拠しなければならない (MUST)。
3.2.2 インターネット制御メッセージプロトコル -- ICMP (Internet Control Message Protocol -- ICMP)
ICMP メッセージの形式と処理は RFC-792 で規定されている。ここではホスト実装に関連する要点のみを論じる。
(1) メッセージ処理の一般原則 (General Message Processing)
ホストは、タイプ未知の ICMP メッセージを静粋に破棄しなければならない (MUST)。ICMP エラーメッセージについては、元のデータグラムの少なくとも 8 バイト（すなわち元の IP ヘッダ + 8 バイト）を含まなければならず (MUST)、含まれる元のデータグラムのバイトは受信したものと完全に同一でなければならない (MUST)。
ICMP エラーメッセージは、含まれる元の IP ヘッダのプロトコルフィールドに基づいて、正しいトランスポート層プロトコルに多重分離（デマルチプレックス）しなければならない (MUST)。
(2) 宛先到達不能 (Destination Unreachable)
IP 層がデータグラムを配信できない場合、宛先到達不能（DESTINATION UNREACHABLE）メッセージを生成できなければならず (MUST)、以下のコードをサポートしなければならない (MUST)：
- コード 2（プロトコル到達不能）
- コード 3（ポート到達不能）
ICMP 宛先到達不能メッセージは上位層に渡さなければならない (MUST)。上位層は宛先到達不能メッセージに対して適切な動作をとるべきである (SHOULD)（例：関連する接続状態を終了するなど）。
ホストは、宛先到達不能メッセージを単なるヒントとして解釈しなければならない (MUST)（つまり、関連するトランスポートプロトコル/アプリケーションが要求しない限り、即時の動作を強制するものではない）。
(3) ソースクエンチ (Source Quench)
ホストのバッファが限界を超えた場合、ソースクエンチ（SOURCE QUENCH）メッセージを送信してもよく (MAY)、かつ送信すべきである (SHOULD)。受信したソースクエンチメッセージは上位層に渡さなければならず (MUST)、上位層は送信レートを低下させるべきである (SHOULD)。
(4) タイムアウト (Time Exceeded)
受信したタイムアウト（TIME EXCEEDED）メッセージは上位層に渡さなければならない (MUST)。
(5) パラメータ問題 (Parameter Problem)
ホストは、IP ヘッダの誤ったパラメータを検出したとき、パラメータ問題（PARAMETER PROBLEM）メッセージを送信すべきである (SHOULD)。受信したパラメータ問題メッセージは上位層に渡さなければならず (MUST)、またユーザーに当該問題を報告してもよく (MAY)、かつ報告すべきである (SHOULD)。
(6) エコー要求/応答 (Echo Request/Reply)
ホストは、エコーサーバー（ECHO SERVER、エコー要求に応答）およびエコークライアント（ECHO CLIENT、エコー要求を送信）を実装しなければならない (MUST)。エコー要求は送信すべきである (SHOULD)。
ブロードキャストアドレス宛てのエコー要求は静粋に破棄すべきである (SHOULD)。マルチキャストアドレス宛てのエコー要求は静粋に破棄すべきである (SHOULD)。エコー応答の送信元アドレスは、元の要求の特定の宛先アドレスを使用しなければならない (MUST)。エコー応答は、要求と同じバイトをデータに回送しなければならない (MUST)。エコー応答は上位層に渡さなければならない (MUST)。エコー応答は、要求のレコードルートおよびタイムスタンプオプションを反射すべきである (SHOULD)。ソースルートオプションは反転して反射しなければならない (MUST)。
(7) 情報要求/応答 (Information Request/Reply)
ホストは、情報要求および情報応答メッセージを実装してもよい (MAY)。
(8) タイムスタンプおよびタイムスタンプ応答 (Timestamp and Timestamp Reply)
ホストは、タイムスタンプ（TIMESTAMP）およびタイムスタンプ応答メッセージを実装してもよい (MAY)。実装する場合、遅延のばらつきを最小限にすべきであり (SHOULD)、ブロードキャストタイムスタンプおよびマルチキャストタイムスタンプを静粋に破棄すべきであり (SHOULD)、タイムスタンプ応答の送信元アドレスは特定の宛先アドレスを使用しなければならず (MUST)、RFC-792 の「標準値」の規則に従わなければならず (MUST)、タイムスタンプ応答を上位層に渡さなければならない (MUST)。
(9) アドレスマスク要求/応答 (Address Mask Request/Reply)
ホストは、アドレスマスク（ADDRESS MASK）を設定により指定可能でなければならず (MUST)、アドレスマスクの静的設定をサポートしなければならない (MUST)。ホストは、ブートストラップ中に（ブートプロトコルにより）アドレスマスクを動的に取得してもよく (MAY)、また ICMP アドレスマスク要求/応答により取得してもよい (MAY)。合理的な時間内に応答が得られない場合、アドレスマスク要求を再送信しなければならず (MUST)、それでも応答がない場合はデフォルトマスクを仮定すべきである (SHOULD)。アドレスマスクは妥当性チェックされるべきである (SHOULD)。ホストは、許可されていないアドレスマスク応答を送信してはならない (MUST NOT)。ホストがアドレスマスクエージェントとして明示的に設定されている場合にのみ、アドレスマスク応答を送信しなければならず (MUST)（かつ権威フラグを設定する）。初期化時にはアドレスマスク要求をブロードキャストで送信しなければならない (MUST)。
3.2.3 インターネットグループ管理プロトコル -- IGMP (Internet Group Management Protocol -- IGMP)
IGMP は RFC-1112 [IP:4] で定義されており、ホスト側の実装要件については第 3.3.7 節を参照。IGMP 自体は、マルチキャストルーティングをサポートするゲートウェイに接続されていないホストに対してはオプションである。
3.3 個別課題 (SPECIFIC ISSUES)
3.3.1 外出データグラムのルーティング (Routing Outbound Datagrams)
3.3.1.1 はじめに (Introduction)
ホストが IP データグラムを送信するとき、どの物理インタフェースおよびどの第 1 ホップゲートウェイ（宛先ホストが接続されたネットワーク上にない場合）を使用するかを決定しなければならない。この決定プロセスを「ルーティング (routing)」と呼ぶ。
ホストは、あるネットワークが「ローカル（接続されたネットワーク）」か「リモート（接続されていないネットワーク）」かを判断するとき、アドレスマスクを使用しなければならない (MUST)。
ホストは、接続されたネットワークにゲートウェイが 1 つも設定されていない状態で正常に動作できなければならない (MUST)。
DISCUSSION (議論)：
ルーティングは、インターネットアーキテクチャにおいて最も複雑で、かつまだ進化している分野の 1 つである。ホストは完全なゲートウェイルーティングプロトコルを実装すべきではなく、単純なメカニズムに依存すべきである：デフォルトゲートウェイ、リダイレクトメッセージ、およびルートキャッシュ。
3.3.1.2 ルートキャッシュと静的ルート (Route Cache and Static Routes)
ホストは、各宛先ネットワーク/ホストへの次ホップゲートウェイを記録する「ルートキャッシュ (route cache)」を維持しなければならない (MUST)。ホストは、ルートキャッシュにエントリが見つからない場合にデフォルトゲートウェイを使用しなければならない (MUST)。ホストは複数のデフォルトゲートウェイをサポートしなければならない (MUST)。
ホストは、静的ルートテーブル（static routes）を提供してもよい (MAY)。これらの静的ルートは、リダイレクトメッセージによって上書き可能または不可のいずれかとして設定してよい (MAY)。
DISCUSSION (議論)：
リダイレクト（Redirect）メッセージは、特定の宛先ホストに対してより良い第 1 ホップゲートウェイがあることをホストに通知するためにゲートウェイから送信される。ホストはリダイレクトメッセージを受信したとき、ルートキャッシュを更新しなければならない (MUST)。ホストはホストリダイレクト（Host Redirect）とネットワークリダイレクト（Net Redirect）の両方を同等に処理しなければならない (MUST)。
不正なリダイレクトメッセージ（例：直接接続されたネットワーク上にないゲートウェイを指すもの）は破棄すべきである (SHOULD)。
3.3.1.3 ルートキャッシュのキー (Route Cache Keying)
ルートキャッシュは、宛先ホストアドレス（宛先ネットワークアドレスではなく）をキーとすべきであり (SHOULD)、またキャッシュに TOS 値を含めるべきである (SHOULD)。
DISCUSSION (議論)：
ホストアドレスをキーとすることで、同じネットワーク上の異なるホストが異なるパスをとることによる問題を回避でき、また宛先ホストごとのよりきめ細かいルーティングが可能になる。
3.3.1.4 死ゲートウェイ検出 (Dead Gateway Detection)
ホストは、次ホップゲートウェイの死を検出できるようにしなければならない (MUST)。ホストは、ルートが永遠に有効であると仮定してはならない (MUST NOT)。
DISCUSSION (議論)：
死んだゲートウェイを検出するために使用できる技術がいくつかある。1 つの方法は、ゲートウェイに対して継続的に ping を行うことだが、これは過剰なトラフィックを生成するため、実際に送信するトラフィックがある場合にのみ ping を行うべきであり (SHOULD)、かつ肯定的な指示がない場合にのみ ping を行うべきである (SHOULD)。上位層および下位層の両方から、配信成功/失敗の助言（advice）を与えることができる。
別の一般的な技術（パッシブにゲートウェイルーティングプロトコルを聴くこと）は推奨されない（後述）。
3.3.1.5 新ゲートウェイ選択 (New Gateway Selection)
死んだゲートウェイが現在のデフォルトゲートウェイでない場合、IP 層は即座に別のデフォルトゲートウェイに切り替えてもよい。死んだゲートウェイが現在のデフォルトゲートウェイである場合、IP 層は（複数のデフォルトゲートウェイが既知であると仮定して）別のデフォルトゲートウェイを選択しなければならず (MUST)、それは死んだルートに対しても新しいルートの確立に対しても使用される。
DISCUSSION (議論)：
ゲートウェイが死んだとき、接続されたネットワーク上の他のゲートウェイは、何らかのゲートウェイ間ルーティングプロトコルを通じてその死を知るだろう。しかしこれは即座には起こらない。なぜならゲートウェイルーティングプロトコルの安定時間は通常 30～60 秒だからである。ゲートウェイが合意に達する前にホストが代替ゲートウェイに切り替えると、新しいターゲットゲートウェイはおそらくデータグラムを死んだゲートウェイに転送し、死んだゲートウェイへのリダイレクトを返送するだろう。結果として、ゲートウェイの安定化中にホストのルートキャッシュの内容が急速に振動する可能性がある。死ゲートウェイロジックに何らかのヒステリシス（遅滞）機構を含めることでこのような振動を防ぐことが提案されているが、経験上この振動は無害であることが示されている。
IMPLEMENTATION (実装)：
新しいデフォルトゲートウェイを選択する 1 つの実装技術は、ホストリスト内のデフォルトゲートウェイ間を単純にラウンドロビン（round-robin）で巡回することである。別の方法は、ゲートウェイに優先順位を付け、現在のデフォルトゲートウェイが最高優先順位でない場合、より高い優先順位のゲートウェイがいつサービスに復帰したかを検出するために「ping」を行うことである。
3.3.1.6 初期化 (Initialization)
以下の情報は設定可能でなければならない (MUST)：
(1) IP アドレス（1 つ以上）。
(2) アドレスマスク（1 つ以上）。
(3) 優先順位付きのデフォルトゲートウェイリスト。
これらの設定データを手動で入力する方法を提供しなければならない (MUST)。さらに、これらの情報を動的に決定するための複数の方法を使用できる（[INTRO:1] の「ホスト初期化 (Host Initialization)」章参照）。
DISCUSSION (議論)：
一部のホスト実装は、ブロードキャストネットワーク上でゲートウェイプロトコルを聴くことで、どのゲートウェイが存在するかを知る。標準的なデフォルトゲートウェイ発見方法は現在策定中である。
3.3.2 再構成 (Reassembly)
IP 層は、IP データグラムの再構成を実装しなければならない (MUST)。
再構成できる最大データグラムサイズを EMTU_R（「有効受信 MTU」）と記す。これは「再構成バッファサイズ (reassembly buffer size)」と呼ばれることもある。EMTU_R は 576 以上でなければならず (MUST)、「設定可能であるか無限 (indefinite)」であるべきであり (SHOULD)、接続されたネットワークの MTU 以上であるべきである (SHOULD)。
DISCUSSION (議論)：
固定された EMTU_R 上限をコードにハードコードすべきではない。なぜなら、一部のアプリケーション層プロトコルは 576 より大きな EMTU_R 値を要求するからである。
IMPLEMENTATION (実装)：
実装は、各データグラムに対して連続した再構成バッファを使用してもよく、またより複雑なデータ構造を使用して、再構成されたデータグラムのサイズに確定的な制限を設けなくてもよい。後者の場合、EMTU_R は「無限」と呼ばれる。
論理的には、再構成は各フラグメントをパケットバッファ内の正しいオフセットにコピーするだけである。連続する再送が異なるパッキングを使用するが同じ再構成識別（Id）を使用する場合、フラグメントが重複し得ることに注意。
再構成の難点は、すべてのバイトがいつ再構成されたかを決定するための簿記（bookkeeping）である。Clark のアルゴリズム [IP:10] を推奨する。これは簿記用の追加データ空間を必要としない。ただし [IP:10] とは逆に、最初のフラグメントのヘッダを保存して、可能な ICMP タイムアウト（再構成タイムアウト）メッセージに含める必要がある。
トランスポート層が MMS_R（IP データグラム内で受信および再構成できる最大メッセージサイズ）を知ることができるメカニズムが存在しなければならない (MUST)（第 3.4 節の GET_MAXSIZES 呼び出し参照）。EMTU_R が無限でない場合、MMS_R の値は：
MMS_R = EMTU_R - 20
20 は IP ヘッダの最小サイズであるため。
再構成タイムアウトが存在しなければならない (MUST)。再構成タイムアウト値は固定値であるべきであり (SHOULD)、残りの TTL から取られるべきではない。推奨値は 60 秒から 120 秒の間である。タイムアウトが期限切れになった場合、部分的に再構成されたデータグラムは破棄されなければならず (MUST)、かつ（フラグメントゼロを受信していれば）送信元ホストに ICMP タイムアウトメッセージを送信しなければならない (MUST)。
DISCUSSION (議論)：
IP 仕様では再構成タイムアウトを IP ヘッダの残り TTL とするとしているが、これは使い勝手が悪い。なぜならゲートウェイは通常 TTL を単なるホップ数ではなく経過時間として扱うからである。再構成タイムアウトが小さすぎると、データグラムが不必要に破棄され、通信が失敗する可能性がある。タイムアウトは、インターネットの典型的な網間最大遅延以上でなければならない。現実的な最小再構成タイムアウトは 60 秒である。
トランスポートプロトコルが各宛先ホストについて測定した往復時間をキャッシュし、それらの値を使用して合理的な再構成タイムアウト値を動的に決定することが提案されている。この方法のさらなる研究は今後の課題である。
再構成タイムアウトを高くしすぎると、受信ホストのバッファリソースが長く占有され、MSL（最大セグメント寿命）[TCP:1] が不必要に大きくなる。MSL は異なる 16 ビット識別（Ident）フィールド値を用いたフラグメントデータグラムの送信最大レートを制御する。大きな MSL は最大レートを低下させる。TCP 仕様 [TCP:1] は MSL を独断的に 2 分と仮定しており、これは合理的な再構成タイムアウト値の上限を設定する。
3.3.3 フラグメンテーション (Fragmentation)
オプションとして、IP 層は送出データグラムを意図的にフラグメントするメカニズムを実装してもよい (MAY)。
与えられた IP 送信元アドレスと宛先アドレスの組（TOS を含む可能性もある）に対して送信できる最大 IP データグラムサイズを EMTU_S（「有効送信 MTU」）と記す。
ホストは、トランスポート層が MMS_S（与えられた {送信元, 宛先, TOS} の組に対して送信できる最大トランスポート層メッセージサイズ）を知ることができるメカニズムを実装しなければならない (MUST)（第 3.4 節の GET_MAXSIZES 呼び出し参照）。ローカルフラグメンテーションを行わない場合、MMS_S の値は：
MMS_S = EMTU_S - <IP ヘッダサイズ>
となり、EMTU_S はデータグラムの送信元アドレスに対応するネットワークインタフェースの MTU 以下でなければならない。この式の <IP ヘッダサイズ> は、IP がトランスポート層が挿入したものに加えて自分自身の IP オプション用の空間を予約しない限り、20 になることに注意。
ローカルフラグメンテーションを行わないホストは、トランスポート層（TCP の場合）またはアプリケーション層（UDP の場合）が IP 層から MMS_S を取得し、MMS_S を超えるデータグラムを送信しないことを確実にしなければならない (MUST)。
通常、ローカルフラグメンテーションを回避し、パス上のいかなるゲートウェイでもフラグメントが発生しないよう十分に低い EMTU_S を選択したい。パス上の最小 MTU についての実用的な知識がない場合、IP 層は宛先が接続されたネットワーク上にないときは EMTU_S <= 576 を使用し、そうでないときは接続されたネットワークの MTU を使用すべきである (SHOULD)。
各物理インタフェースの MTU は設定可能でなければならない (MUST)。
ホスト IP 層実装は、構成フラグ「All-Subnets-MTU（すべてのサブネット MTU）」を持っていてもよい (MAY)。これは、接続されたネットワークの MTU が、同じネットワーク内の異なるサブネット上の宛先アドレスに対して使用されるが、他のネットワークに対しては使用されないことを示す。したがってこのフラグは、EMTU_S の選択にネットワーククラスマスクではなくサブネットアドレスマスクを使用させる。マルチホームホストの場合、各ネットワークインタフェースに 1 つの「All-Subnets-MTU」フラグが必要である。
DISCUSSION (議論)：
指定した目的への適切なデータグラムサイズの選択は複雑なトピックである [IP:9]。
(a) 一般的に、どのホストも 576 バイト（ヘッダとデータを含む）を超える IP データグラムの受受入れを要求されていないため、目的ホストとの明示的な知識や事前の取り決めがない限り、ホストはそれより大きなデータグラムを送信してはならない。したがって、MMS_S が 556 を超える場合でも、目的ホストに関する他の知識がない限り、トランスポート層はメッセージを 556 バイト以内に制限しなければならない。
(b) 一部のトランスポートプロトコル（TCP など）は、もう一方のホストが受信および再構成できる最大データグラムサイズを明示的に通知する手段を提供する [IP:7]。IP 層にそのようなメカニズムはない。EMTU_R が 576 より大きいと仮定するトランスポートプロトコル（第 3.3.2 節参照）は、同じプロトコルを実装する別のホストにその大きいサイズのデータグラムを送信できる。
(c) 理想的には、ホストは与えられたパス上のすべてのネットワークの最小 MTU に指定先の EMTU_S を制限し、いかなるフラグメンテーションも回避すべきである。IP フラグメンテーションは形式的には正しいが、単一フラグメントの損失がそのセグメント内のすべてのフラグメントを再送させることになるため [IP:9]、トランスポートプロトコルの性能に深刻な問題を引き起こす。
インターネットのほぼすべてのネットワークが現在 576 以上の MTU をサポートしているため、非ローカルネットワーク宛てのデータグラムサイズとして 576 を使用することを強く推奨する。
パス上の MTU を決定するために、ホストがオフセットゼロのデータグラムフラグメントを送信し、受信側が再構成のタイムアウト（完了しない！）を待ってから ICMP タイムアウトメッセージを返すことで MTU を決定できるという提案がある。このメッセージには最大の残りフラグメントヘッダが本文に含まれる。より直接的なメカニズムが試験されているが、まだ採用されていない（RFC-1063 参照）。
3.3.4 ローカルマルチホーミング (Local Multihoming)
3.3.4.1 はじめに (Introduction)
マルチホームホストは複数の IP アドレスを持ち、これらを「論理インタフェース (logical interfaces)」と見なすことができる。これらの論理インタフェースは、1 つまたは複数の物理インタフェースに関連付けられ、それらは同じまたは異なるネットワークに接続されている可能性がある。
以下は重要なマルチホーミングの状況である：
(a) 複数の論理ネットワーク (Multiple Logical Networks)
インターネットアーキテクトは、各物理ネットワークが一意の IP ネットワーク（またはサブネット）番号を持つことを想定している。しかし LAN 管理者は、1 つの物理接続ネットワーク上で複数の論理ネットワークを実行することが有用であると気づくことがある。
そのような物理ネットワークに接続されたホストが N 個の異なる論理ネットワークのトラフィックを処理するように設定されている場合、そのホストは N 個の論理インタフェースを持つことになる。これらのインタフェースは 1 つの物理インタフェースを共有してよく、また N 個の物理インタフェースを使用して同じネットワークに接続してもよい。
(b) 複数の論理ホスト (Multiple Logical Hosts)
ホストが複数の IP アドレスを持ち、それらのアドレスが同じ <ネットワーク番号> 部分（および同じ <サブネット番号> 部分が存在する場合はそれも）を持つとき、これらの論理インタフェースは「論理ホスト (logical hosts)」と呼ばれる。これらの論理インタフェースは単一の物理インタフェースを共有してよく、また独立した物理インタフェースを使用して同じ物理ネットワークに接続してもよい。
(c) 単純マルチホーミング (Simple Multihoming)
この場合、各論理インタフェースは独立した物理インタフェースにマッピングされ、各物理インタフェースは異なる物理ネットワークに接続される。「マルチホーム (multihomed)」という用語は当初この場合にのみ使用されていたが、現在ではより広く適用されている。
組み込みゲートウェイ機能を持つホストは通常、単純マルチホーミングのケースに該当する。ただし、ホストは組み込みゲートウェイなしで単にマルチホームであってもよく、すなわちある接続ネットワークから別の接続ネットワークへのデータグラム転送を行わないことに注意。
このケースは最も困難なルーティング問題を提示する。インタフェースの選択（すなわち第 1 ホップネットワークの選択）は、性能やインターネット遠端での接続性に大きな影響を与える可能性がある。
最後に、もう 1 つのマルチホーミングでない可能性に注意する。1 つの論理インタフェースを複数の物理インタフェースにバインドして、これらの直接接続されたマシン間に代替の物理パスを提供することで信頼性またはスループットを向上させることができる。たとえば、2 つのシステムが複数のポイントツーポイントリンクで接続されている場合である。これを「リンク層多重化 (link-layer multiplexing)」と呼ぶ。リンク層多重化では、リンク層の上のプロトコルは複数の物理インタフェースの存在を認識せず、リンク層デバイスドライバが物理インタフェース間の多重化とルーティングを担当する。
インターネットプロトコルアーキテクチャでは、トランスポートプロトコルインスタンス（「エンティティ」）は独自のアドレスを持たず、単一のインターネットプロトコル（IP）アドレスを使用する。これは IP 層、トランスポート層、アプリケーション層、およびそれらの間のインタフェースに影響を与える。特に、アプリケーションソフトウェアはマルチホームホストの複数の IP アドレスを認識する必要があるかもしれない。他の場合には、選択をネットワークソフトウェア内部で行うことができる。
3.3.4.2 マルチホーミング要件 (Multihoming Requirements)
マルチホームホストからデータグラムを送信するときの IP 送信元アドレスの選択に関する以下の一般的な規則が適用される。
(1) データグラムが受信したデータグラムへの応答として送信される場合、応答の送信元アドレスは要求の特定の宛先アドレスであるべきである (SHOULD)。より高い層に関するより具体的な要件については、第 4.1.3.5 節、第 4.2.3.7 節、および [INTRO:1] の「一般的問題 (General Issues)」章を参照。
それ以外の場合は、送信元アドレスを選択しなければならない。
(2) アプリケーションは、接続または要求を開始するために使用する送信元アドレスを明示的に指定できなければならない (MUST)。
(3) そのような指定がない場合、ネットワークソフトウェアが送信元アドレスを選択しなければならない (MUST)。その選択の規則は以下の通り。
マルチホーミングに関連する 2 つの重要な要件課題は：
(A) ホストは、受信した物理インタフェースに対応しない宛先アドレスを持つ着信データグラムを静粋に破棄してもよい (MAY)。
(B) ホストは、（ソースルーティングされていない）IP データグラムを、その IP 送信元アドレスに対応する物理インタフェースを通じてのみ送信するように制限してもよい (MAY)。
DISCUSSION (議論)：
インターネットホスト実装者は、マルチホーミングに対して 2 つの異なる概念モデルを使用している。以下に簡単に説明する。本ドキュメントはどちらのモデルが優れているかについて立場をとらない。各モデルには有用な場面があるようである。この矛盾する態度は、課題 (A) と (B) の両方がオプションであるという事実に反映されている。
-
強エンドシステムモデル (Strong ES Model)
強エンドシステム（End System、すなわちホスト）モデルは、ホスト/ゲートウェイ（ES/IS）の区別を強調するため、上記の課題 (A) と (B) において 必須 (MUST) を してもよい (MAY) の代わりに使用する。このモデルは、マルチホームホストを同一物理ホスト内の一連の論理ホストとしてモデル化する傾向がある。
課題 (A) について、強 ES モデルの支持者は、自動的なインターネットルーティングメカニズムは、宛先アドレスに対応しない物理インタフェースにデータグラムをルーティングできないと指摘する。
強 ES モデルでは、外出データグラムのルーティング計算は次のマッピングである：
route(src IP addr, dest IP addr, TOS) -> gateway
ここで送信元アドレスは、適切な物理インタフェースを介して直接到達可能なゲートウェイを選択するためにパラメータとして含まれる。このモデルでは、通常、各 IP 送信元アドレスごとに少なくとも 1 つのデフォルトゲートウェイ、できれば複数のデフォルトゲートウェイがあることが論理的に必要であることに注意。
-
弱エンドシステムモデル (Weak ES Model)
この見方は ES/IS 区別を薄く見るため、上記の課題 (A) と (B) において してはならない (MUST NOT) を してもよい (MAY) の代わりに使用する。ゲートウェイルーティングプロトコルを聴くホストには自然であり、組み込みゲートウェイ機能を持つホストには必須である。
弱 ES モデルはリダイレクトメカニズムを無効にする可能性がある。データグラムが宛先アドレスに対応しない物理インタフェースから送信されると、第 1 ホップゲートウェイはいつリダイレクトを送信すべきかを認識できない。一方、ホストに組み込みゲートウェイ機能がある場合、ルーティング情報をリダイレクトに頼らずに取得できる。
弱 ES モデルでは、外出データグラムのルーティング計算は次のマッピングである：
route(dest IP addr, TOS) -> gateway, interface
3.3.4.3 送信元アドレスの選択 (Choosing a Source Address)
DISCUSSION (議論)：
初期接続要求（TCP の "SYN" セグメントなど）やデータグラムサービス要求（UDP ベースのクエリなど）を送信するとき、マルチホームホスト上のトランスポート層は使用する送信元アドレスを知る必要がある。アプリケーションが指定していない場合、トランスポート層は IP 層に次の概念的マッピングを実行するよう要求しなければならない：
GET_SRCADDR(remote IP addr, TOS) -> local IP address
ここで TOS はサービスタイプ値（第 3.2.1.6 節参照）であり、結果は期待される送信元アドレスである。このマッピングを実装するための推奨規則は以下の通り：
(a) リモートインターネットアドレスがホストが直接接続された（サブネット）ネットワーク上にある場合、対応する送信元アドレスを選択してよい（関連するインタフェースがダウンしていないことが知られている場合を除く）。
(b) 指定された目的ネットワークへのアクティブなルートが任意のネットワークインタフェースを通じて存在するかどうかをルートキャッシュで調べてよい。存在する場合、そのインタフェースに対応するローカル IP アドレスを選択できる。
(c) 同様に静的ルートテーブル（存在する場合、第 3.3.1.2 節参照）を調べてよい。
(d) デフォルトゲートウェイを調べてよい。これらのゲートウェイが異なるインタフェースに割り当てられている場合、優先順位が最も高いゲートウェイに対応するインタフェースを選択できる。
将来的には、マルチホームホストが、すべての接続されたネットワーク上のゲートウェイに問い合わせて、指定された目的に対する最適なネットワークに関する助言を得るための、定義された方法が利用可能になる可能性がある。
IMPLEMENTATION (実装)：
このプロセスは本質的にデータグラムルーティング（第 3.3.1 節）と同じであるため、ホストはこれら 2 つの機能の実装を統合できることに注意。
3.3.5 ソースルート転送 (Source Route Forwarding)
以下の制限の下で、ホストはソースルート内の中间ホップとして、ソースルートデータグラムを次の指定ホップに転送してもよい (MAY)。
ただし、このようなゲートウェイのような機能を実行するとき、ホストはソースルートデータグラムの転送に関するゲートウェイのすべての関連規則 [INTRO:2] を遵守しなければならない (MUST)。これには以下が含まれる（これらの特定条項は、本ドキュメントの前文の対応するホスト条項を上書きする）：
(A) TTL（第 3.2.1.7 節参照）
TTL フィールドは [INTRO:2] のゲートウェイ規則に従って減算されなければならず (MUST)、その結果としてデータグラムが破棄される可能性がある。
(B) ICMP 宛先到達不能（第 3.2.2.1 節参照）
ホストは以下のコードを持つ「宛先到達不能」メッセージを**生成できなければならない (MUST)**：
4 （フラグメント化が必要だが DF が設定されている）——ソースルートデータグラムが対象ネットワークに合わせてフラグメント化できない場合；
5 （ソースルート失敗）——ソースルートデータグラムが、例えばルーティング問題や厳密なソースルートの次ホップが接続されたネットワーク上にない場合などにより転送できない場合。
(C) IP 送信元アドレス（第 3.2.1.3 節参照）
転送されるソースルートデータグラムは、転送ホスト自身の IP アドレスのいずれでもない送信元アドレスを持っていて**よく (MAY)**（そして通常はそうなる）。
(D) レコードルートオプション（第 3.2.1.8d 節参照）
レコードルートオプションを含むソースルートデータグラムを転送するホストは、そのオプションを更新しなければならない (MUST)（まだ空きがある場合）。
(E) タイムスタンプオプション（第 3.2.1.8e 節参照）
タイムスタンプオプションを含むソースルートデータグラムを転送するホストは、現在のタイムスタンプをそのオプションに追加しなければならなければならない (MUST)。
ローカルソースルーティング (local source-routing) という用語を、次ホップがデータグラムが到着したのと同じ物理インタフェースを通じて到達する場合に使用する。それ以外は非ローカルソースルーティング (non-local source-routing) である。
- ホストはローカルソースルーティングを無制限に実行してよい。
- 非ローカルソースルーティングをサポートするホストは、転送を無効にする設定可能なスイッチを持たなければならず (MUST)、そのスイッチはデフォルトで無効でなければならない (MUST)。
- ホストは [INTRO:2] の非ローカル転送を制限する構成可能なポリシーフィルタのすべてのゲートウェイ要件を満たさなければならない (MUST)。
ホストが不完全なソースルートを持つデータグラムを受信したが、何らかの理由でそれを転送しなかった場合、ホストは（そのデータグラム自体が ICMP エラーメッセージでない限り）ICMP「宛先到達不能（コード 5、ソースルート失敗）」メッセージを返すべきである (SHOULD)。
3.3.6 ブロードキャスト (Broadcasts)
第 3.2.1.3 節は、4 つの標準的な IP ブロードキャストアドレス形式を定義している：
限定ブロードキャスト (Limited Broadcast)： {-1, -1}
指向ブロードキャスト (Directed Broadcast)： {<ネットワーク番号>, -1}
サブネット指向ブロードキャスト (Subnet Directed Broadcast)： {<ネットワーク番号>, <サブネット番号>, -1}
全サブネット指向ブロードキャスト (All-Subnets Directed Broadcast)： {<ネットワーク番号>, -1, -1}
ホストは、着信データグラムの宛先アドレスにおける上記のいずれかの形式を認識しなければならない (MUST)。
0 ではなく -1 を使用する非標準のブロードキャストアドレス形式を使用するホストクラス* がある。すべてのホストは、これらの非標準ブロードキャストアドレスを着信データグラムの宛先アドレスとして認識および受け入れるべきである (SHOULD)。ホストは、各物理インタフェースごとに、ブロードキャストアドレスの 0 形式または -1 形式を選択する設定オプションを提供してもよい (MAY) が、そのオプションはデフォルトで標準（-1）形式であるべきである (SHOULD)。
*4.2BSD Unix およびその派生システム（4.3BSD は除く）。
ホストがリンク層ブロードキャストアドレスにデータグラムを送信するとき、IP 宛先アドレスは有効な IP ブロードキャストアドレスまたは IP マルチキャストアドレスでなければならない (MUST)。
ホストは、リンク層ブロードキャスト（第 2.4 節参照）を介して受信され、IP マルチキャストまたはブロードキャスト宛先アドレスが指定されていないデータグラムを静粋に破棄すべきである (SHOULD)。
ホストは、接続されたネットワークへのブロードキャストに限定ブロードキャストアドレスを使用すべきである (SHOULD)。
DISCUSSION (議論)：
限定ブロードキャストアドレスを指向ブロードキャストアドレスの代わりに使用することで、システムの堅牢性が向上する可能性がある。問題は、多くのブロードキャストアドレス形式（第 3.2.1.3 節参照）を理解しないマシン、あるいはどのブロードキャストアドレスが使用されているかについて異なる見解を持つマシンによって引き起こされることが多い。後者の典型的な例は、サブネット化を理解せず、サブネット化されたネットワークに接続されたマシンである。接続されたネットワークへのサブネットブロードキャストを送信すると、それらのマシンはそれを別のホスト宛てのメッセージと誤解する。
限定ブロードキャストアドレスを宛先とするデータグラムを、マルチホームホストのすべてのインタフェースから送信すべきかどうかについて議論が続いている。本仕様はこの問題について立場をとらない。
3.3.7 IP マルチキャスト (IP Multicasting)
ホストは、D クラス IP アドレスからリンク層アドレスへのマッピングが定義されているすべての接続されたネットワーク上で、ローカル IP マルチキャストをサポートすべきである (SHOULD)（後述）。ローカル IP マルチキャストのサポートには、マルチキャストデータグラムの送信、マルチキャストグループへの参加および受信、およびマルチキャストグループからの離脱が含まれる。これは [IP:4] の全内容（IGMP プロトコル自体はオプション (OPTIONAL) である）のサポートを意味する。
DISCUSSION (議論)：
IGMP は、マルチキャストルーティングが可能なゲートウェイに、複数のネットワークにわたる IP マルチキャストをサポートするために必要な情報を提供する。現在、マルチキャストルーティングゲートウェイは実験段階であり、広く利用可能ではない。マルチキャストルーティングゲートウェイに接続されていないネットワーク、または他のネットワークから発信されたマルチキャストデータグラムを受信する必要がないホストにとって、IGMP は無用であり、したがって現在はオプションである。しかし、[IP:4] の残りの部分は現在推奨されており、ローカルネットワークマルチキャストアドレッシングへの IP 層アクセスを提供するためである。マルチキャストルーティングゲートウェイがより普及する未来には、IGMP が推奨されるようになると予想される。
IGMP を実装していない場合、ホストは起動時に「すべてのホスト (all-hosts)」グループ（224.0.0.1）に参加し、IP 層がアクティブな間はそのグループのメンバーであり続けるべきである (SHOULD)。
DISCUSSION (議論)：
「すべてのホスト」グループへの参加は、IGMP を実装していなくても、ゲートウェイ発見プロトコルなどのマルチキャストの厳密なローカル用途をサポートする。
IP D クラスアドレスからローカルアドレスへのマッピングは、現在以下のタイプのネットワークに対して規定されている：
-
イーサネット/IEEE 802.3：[IP:4] で定義されている通り。
-
ブロードキャストはサポートするがマルチキャストアドレッシングをサポートしないネットワーク：すべての IP D クラスアドレスはローカルブロードキャストアドレスにマッピングされる。
-
あらゆるタイプのポイントツーポイントリンク（SLIP や HDLC リンクなど）：マッピングは不要。すべての IP マルチキャストデータグラムはローカルフレーム内でそのまま送信される。
他のタイプのネットワークのマッピングは将来規定される。
ホストは、ホストのどの接続されたネットワークが IP マルチキャストアドレッシングをサポートしているかを、より高い層のプロトコルまたはアプリケーションが判断できる方法を提供すべきである (SHOULD)。
3.3.8 エラー報告 (Error Reporting)
実行可能な範囲で、ホストはエラーを検出したときに ICMP エラーデータグラムを返さなければならない (MUST)。ただし、ICMP エラーメッセージの返送が明示的に禁止されている場合を除く。
DISCUSSION (議論)：
データグラムネットワークにおける一般的な現象に「ブラックホール病 (black hole disease)」がある。データグラムは送信されるが、何も返ってこない。エラーメッセージがまったくないと、ユーザーが問題の所在を理解するのは困難である。
3.4 インターネット/トランスポート層インタフェース (INTERNET/TRANSPORT LAYER INTERFACE)
IP 層とトランスポート層の間のインタフェースは、IP 層のすべてのメカニズム（オプション、サービスタイプ、生存時間を含む）への完全なアクセスを提供しなければならない (MUST)。トランスポート層は、これらのインタフェースパラメータを設定するメカニズム、またはアプリケーション層からそれらを透過的に渡すパス、あるいはその両方を持たなければならない (MUST)。
DISCUSSION (議論)：
これらのメカニズムが適用可能な場所ではアプリケーションによる利用を促す。たとえそれらがインターネット内で現在まだ有効でなくても（例：TOS）、これらのメカニズムが有効なときに即座に利用可能になるよう、ホストソフトウェアの大規模な改造を必要とせずに済む。
ここで、トランスポート層と IP 層の間の概念的インタフェースを一連のプロシージャル呼び出しとして記述する。これは RFC-791 [IP:1] 第 3.3 節の情報の拡張である。
-
データグラム送信 (Send Datagram)
SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result )
パラメータは RFC-791 で定義されている。Id パラメータの受け渡しはオプション（第 3.2.1.5 節参照）。
-
データグラム受信 (Receive Datagram)
RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)
RFC-791 で定義されたすべてのパラメータに加えて：
SpecDest = データグラムの特定の宛先アドレス （第 3.2.1.3 節定義）
result パラメータ dst にはデータグラムの宛先アドレスが含まれる。宛先がブロードキャストまたはマルチキャストアドレスである可能性があるため、SpecDest パラメータ（RFC-791 には表示されない）を渡さなければならない (MUST)。パラメータ opt にはデータグラムで受信したすべての IP オプションが含まれ、これらはトランスポート層にも渡されなければならない (MUST)。
-
送信元アドレス選択 (Select Source Address)
GET_SRCADDR(remote, TOS) -> local
remote = リモート IP アドレス TOS = サービスタイプ local = ローカル IP アドレス
第 3.3.4.3 節参照。
-
最大データグラムサイズ検索 (Find Maximum Datagram Sizes)
GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
MMS_R = 受信可能な最大トランスポートメッセージサイズ。 MMS_S = 送信可能な最大トランスポートメッセージサイズ。 （local、remote、TOS は上記定義）
第 3.3.2 節および第 3.3.3 節参照。
-
配信成功助言 (Advice on Delivery Success)
ADVISE_DELIVPROB(sense, local, remote, TOS)
ここでパラメータ sense は、正の助言か負の助言かを示す 1 ビットフラグ（第 3.3.1.4 節の議論参照）。他のパラメータは前述。
-
ICMP メッセージ送信 (Send ICMP Message)
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result
（パラメータは RFC-791 で定義）。
Id パラメータの受け渡しはオプション（第 3.2.1.5 節参照）。トランスポート層は、特定の ICMP メッセージ（ポート到達不能、または任意のクエリタイプのメッセージ）を送信できなければならない (MUST)。もちろん、この機能は SEND() 呼び出しの特殊ケースと見なせる。明確化のため分けて記述する。
-
ICMP メッセージ受信 (Receive ICMP Message)
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
（パラメータは RFC-791 で定義）。
IP 層は、特定の ICMP メッセージを対応するトランスポート層ルーチンに上位へ渡さなければならない (MUST)。もちろん、この機能は RECV() 呼び出しの特殊ケースと見なせる。明確化のため分けて記述する。
ICMP エラーメッセージの場合、上位へ渡されるデータには、元のインターネットヘッダおよび ICMP メッセージに含まれる元のメッセージのすべてのバイトが含まれなければならない (MUST)。トランスポート層はこれらのデータを使用して接続状態情報（存在する場合）を見つける。
特に、以下の ICMP メッセージを上位へ渡さなければならない (MUST)：
- 宛先到達不能 (Destination Unreachable)
- ソースクエンチ (Source Quench)
- エコー応答（エコー要求が IP 層から発信された場合を除き、ICMP ユーザインタフェースへ）
- タイムスタンプ応答（ICMP ユーザインタフェースへ）
- タイムアウト (Time Exceeded)
DISCUSSION (議論)：
将来、このインタフェースに、IP 層とトランスポート層間でパスデータを渡すための追加が行われる可能性がある（第 3.3.1.3 節参照）。
3.5 インターネット層要件サマリ (INTERNET LAYER REQUIREMENTS SUMMARY)
| 特性 (Feature) | 節 (Section) | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| IP と ICMP の実装 (Implement IP and ICMP) | 3.1 | x | ||||
| 不正なデータグラムをログ記録可能 (Able to log discarded datagrams) | 3.1 | x | ||||
| - カウンタに記録 (- Record in counter) | 3.1 | x | ||||
| バージョン != 4 を静粋に破棄 (Silently discard Version != 4) | 3.2.1.1 | x | ||||
| IP チェックサム検証、不良を静粋に破棄 (Verify IP checksum, silently discard bad dgram) | 3.2.1.2 | x | ||||
| アドレッシング (Addressing): | ||||||
| - サブネットアドレッシング (RFC-950) (- Subnet addressing (RFC-950)) | 3.2.1.3 | x | ||||
| - 送信元アドレスはホスト自身の IP アドレス (- Src address must be host's own IP address) | 3.2.1.3 | x | ||||
| - 不正な宛先アドレスのデータグラムを静粋に破棄 (- Silently discard datagram with bad dest addr) | 3.2.1.3 | x | ||||
| - 不正な送信元アドレスのデータグラムを静粋に破棄 (- Silently discard datagram with bad src addr) | 3.2.1.3 | x | ||||
| 再構成のサポート (Support reassembly) | 3.2.1.4 | x | ||||
| 同一データグラムで同じ Id フィールドを保持 (Retain same Id field in identical datagram) | 3.2.1.5 | x | ||||
| TOS: | ||||||
| - トランスポート層が TOS を設定可能 (- Allow transport layer to set TOS) | 3.2.1.6 | x | ||||
| - 受信した TOS をトランスポート層に渡す (- Pass received TOS up to transport layer) | 3.2.1.6 | x | ||||
| - TOS に RFC-795 リンク層マッピングを使用 (- Use RFC-795 link-layer mappings for TOS) | 3.2.1.6 | x | ||||
| TTL: | ||||||
| - TTL 0 のパケット送信 (- Send packet with TTL of 0) | 3.2.1.7 | x | ||||
| - TTL < 2 の受信パケット破棄 (- Discard received packets with TTL < 2) | 3.2.1.7 | x | ||||
| - トランスポート層が TTL を設定可能 (- Allow transport layer to set TTL) | 3.2.1.7 | x | ||||
| - 固定 TTL 設定可能 (- Fixed TTL is configurable) | 3.2.1.7 | x | ||||
| IP オプション (IP Options): | ||||||
| - トランスポート層が IP オプション送信可能 (- Allow transport layer to send IP options) | 3.2.1.8 | x | ||||
| - 受信したすべての IP オプションを上位層へ (- Pass all IP options rcvd to higher layer) | 3.2.1.8 | x | ||||
| - IP 層が未知オプションを静粋に無視 (- IP layer silently ignore unknown options) | 3.2.1.8 | x | ||||
| - セキュリティオプション (- Security option) | 3.2.1.8a | x | ||||
| - ストリーム識別子オプション送信 (- Send Stream Identifier option) | 3.2.1.8b | x | ||||
| - ストリーム識別子オプションを静粋に無視 (- Silently ignore Stream Identifer option) | 3.2.1.8b | x | ||||
| - レコードルートオプション (- Record Route option) | 3.2.1.8d | x | ||||
| - タイムスタンプオプション (- Timestamp option) | 3.2.1.8e | x | ||||
| ソースルートオプション (Source Route Option): | ||||||
| - ソースルートオプションの開始と終端 (- Originate & terminate Source Route options) | 3.2.1.8c | x | ||||
| - 完了した SR データグラムを TL に渡す (- Datagram with completed SR passed up to TL) | 3.2.1.8c | x | ||||
| - 正しい（非冗長）リターンルート構築 (- Build correct (non-redundant) return route) | 3.2.1.8c | x | ||||
| - 1 ヘッダで複数 SR オプション送信 (- Send multiple SR options in one header) | 3.2.1.8c | x | ||||
| ICMP: | ||||||
| - タイプ未知の ICMP メッセージを静粋に破棄 (- Silently discard ICMP msg with unknown type) | 3.2.2 | x | ||||
| - 元データグラムの 8 バイト超を含む (- Include more than 8 octets of orig datagram) | 3.2.2 | x | ||||
| - 受信時と同じバイトを含む (- Included octets same as received) | 3.2.2 | x | ||||
| - ICMP エラーをトランスポートプロトコルにデマルチプレックス (- Demux ICMP Error to transport protocol) | 3.2.2 | x | ||||
| - TOS=0 で ICMP エラーメッセージ送信 (- Send ICMP error message with TOS=0) | 3.2.2 | x | ||||
| - 以下の場合 ICMP エラーメッセージ送信 (- Send ICMP error message for: ) | ||||||
| - ICMP エラーメッセージ (- ICMP error msg) | 3.2.2 | x | ||||
| - IP ブロードキャストまたは IP マルチキャスト (- IP b'cast or IP m'cast) | 3.2.2 | x | ||||
| - リンク層ブロードキャスト (- Link-layer b'cast) | 3.2.2 | x | ||||
| - 非初期フラグメント (- Non-initial fragment) | 3.2.2 | x | ||||
| - 非一意の送信元アドレスを持つデータグラム (- Datagram with non-unique src address) | 3.2.2 | x | ||||
| - エラー検出時に ICMP エラーメッセージ返送（禁止されていない場合）(- Return ICMP error msgs (when not prohibited)) | 3.3.8 | x | ||||
| - 宛先到達不能 (Dest Unreachable): | ||||||
| 宛先到達不能（コード 2/3）生成 (Generate Dest Unreachable (code 2/3)) | 3.2.2.1 | x | ||||
| ICMP 宛先到達不能を上位層へ渡す (Pass ICMP Dest Unreachable to higher layer) | 3.2.2.1 | x | ||||
| 上位層が宛先到達不能に動作 (Higher layer act on Dest Unreach) | 3.2.2.1 | x | ||||
| 宛先到達不能を単なるヒントとして解釈 (Interpret Dest Unreach as only hint) | 3.2.2.1 | x | ||||
| - リダイレクト (Redirect): | ||||||
| ホストがリダイレクト送信 (Host send Redirect) | 3.2.2.2 | x | ||||
| リダイレクト受信時にルートキャッシュ更新 (Update route cache when recv Redirect) | 3.2.2.2 | x | ||||
| ホストとネットの両リダイレクトを処理 (Handle both Host and Net Redirects) | 3.2.2.2 | x | ||||
| 不正なリダイレクト破棄 (Discard illegal Redirect) | 3.2.2.2 | x | ||||
| - ソースクエンチ (Source Quench): | ||||||
| バッファ超過時にソースクエンチ送信 (Send Source Quench if buffering exceeded) | 3.2.2.3 | x | ||||
| ソースクエンチを上位層へ渡す (Pass Source Quench to higher layer) | 3.2.2.3 | x | ||||
| 上位層がソースクエンチに動作 (Higher layer act on Source Quench) | 3.2.2.3 | x | ||||
| - タイムアウト：上位層へ渡す (Time Exceeded: pass to higher layer) | 3.2.2.4 | x | ||||
| - パラメータ問題 (Parameter Problem): | ||||||
| パラメータ問題メッセージ送信 (Send Parameter Problem messages) | 3.2.2.5 | x | ||||
| パラメータ問題を上位層へ渡す (Pass Parameter Problem to higher layer) | 3.2.2.5 | x | ||||
| ユーザーにパラメータ問題報告 (Report Parameter Problem to user) | 3.2.2.5 | x | ||||
| - ICMP エコー要求または応答 (ICMP Echo Request or Reply): | ||||||
| エコーサーバーとエコークライアント (Echo server and Echo client) | 3.2.2.6 | x | ||||
| エコークライアント (Echo client) | 3.2.2.6 | x | ||||
| ブロードキャスト宛てのエコー要求破棄 (Discard Echo Request to broadcast address) | 3.2.2.6 | x | ||||
| マルチキャスト宛てのエコー要求破棄 (Discard Echo Request to multicast address) | 3.2.2.6 | x | ||||
| エコー応答の送信元に特定宛先アドレス使用 (Use specific-dest addr as Echo Reply src) | 3.2.2.6 | x | ||||
| エコー応答で同じデータ送信 (Send same data in Echo Reply) | 3.2.2.6 | x | ||||
| エコー応答を上位層へ渡す (Pass Echo Reply to higher layer) | 3.2.2.6 | x | ||||
| レコードルート、タイムスタンプオプション反射 (Reflect Record Route, Time Stamp options) | 3.2.2.6 | x | ||||
| ソースルートオプション反転および反射 (Reverse and reflect Source Route option) | 3.2.2.6 | x | ||||
| - ICMP アドレスマスク要求/応答 (ICMP Address Mask Request and Reply): | ||||||
| アドレスマスク取得元設定可能 (Addr Mask source configurable) | 3.2.2.9 | x | ||||
| アドレスマスクの静的設定サポート (Support static configuration of addr mask) | 3.2.2.9 | x | ||||
| ブート中に動的取得 (Get addr mask dynamically during booting) | 3.2.2.9 | x | ||||
| ICMP アドレスマスク要求/応答で取得 (Get addr via ICMP Addr Mask Request/Reply) | 3.2.2.9 | x | ||||
| 応答なければアドレスマスク要求再送 (Retransmit Addr Mask Req if no Reply) | 3.2.2.9 | x | 3 | |||
| 応答なければデフォルトマスク仮定 (Assume default mask if no Reply) | 3.2.2.9 | x | 3 | |||
| 最初の応答からのみ更新 (Update address mask from first Reply only) | 3.2.2.9 | x | 3 | |||
| アドレスマスク妥当性チェック (Reasonableness check on Addr Mask) | 3.2.2.9 | x | ||||
| 許可されていないアドレスマスク応答送信 (Send unauthorized Addr Mask Reply msgs) | 3.2.2.9 | x | ||||
| エージェントとして明示設定 (Explicitly configured to be agent) | 3.2.2.9 | x | ||||
| 静的設定 => アドレスマスク権威フラグ (Static config=> Addr-Mask-Authoritative flag) | 3.2.2.9 | x | ||||
| 初期化時にブロードキャスト応答 (Broadcast Addr Mask Reply when init.) | 3.2.2.9 | x | 3 | |||
| 外出データグラムのルーティング (ROUTING OUTBOUND DATAGRAMS): | ||||||
| - ローカル/リモート決定にアドレスマスク使用 (Use address mask in local/remote decision) | 3.3.1.1 | x | ||||
| - 接続ネットワークにゲートウェイなしで動作 (Operate with no gateways on conn network) | 3.3.1.1 | x | ||||
| - 次ホップゲートウェイの「ルートキャッシュ」維持 (Maintain "route cache" of next-hop gateways) | 3.3.1.2 | x | ||||
| - ホストとネットのリダイレクトを同等扱い (Treat Host and Net Redirect the same) | 3.3.1.2 | x | ||||
| - キャッシュエントリなければデフォルトゲートウェイ使用 (If no cache entry, use default gateway) | 3.3.1.2 | x | ||||
| 複数デフォルトゲートウェイサポート (Support multiple default gateways) | 3.3.1.2 | x | ||||
| - 静的ルートテーブル提供 (Provide table of static routes) | 3.3.1.2 | x | ||||
| フラグ：リダイレクトで上書き可 (Flag: route overridable by Redirects) | 3.3.1.2 | x | ||||
| - ルートキャッシュのキーをホストに (Key route cache on host, not net address) | 3.3.1.3 | x | ||||
| - ルートキャッシュに TOS 含める (Include TOS in route cache) | 3.3.1.3 | x | ||||
| - 次ホップゲートウェイ死検出可能 (Able to detect failure of next-hop gateway) | 3.3.1.4 | x | ||||
| - ルートが永遠に有効と仮定 (Assume route is good forever) | 3.3.1.4 | x | ||||
| - ゲートウェイに継続 ping (Ping gateways continuously) | 3.3.1.4 | x | ||||
| - トラフィック送信時のみ ping (Ping only when traffic being sent) | 3.3.1.4 | x | ||||
| - 肯定的指示がない場合のみ ping (Ping only when no positive indication) | 3.3.1.4 | x | ||||
| - 上位層と下位層から助言 (Higher and lower layers give advice) | 3.3.1.4 | x | ||||
| - 死デフォルトゲートウェイから別へ切替 (Switch from failed default g'way to another) | 3.3.1.5 | x | ||||
| - 設定情報手動入力方法 (Manual method of entering config info) | 3.3.1.6 | x | ||||
| 再構成とフラグメンテーション (REASSEMBLY and FRAGMENTATION): | ||||||
| - 着信データグラムの再構成可能 (Able to reassemble incoming datagrams) | 3.3.2 | x | ||||
| 少なくとも 576 バイトデータグラム (At least 576 byte datagrams) | 3.3.2 | x | ||||
| EMTU_R 設定可能または無限 (EMTU_R configurable or indefinite) | 3.3.2 | x | ||||
| - トランスポート層が MMS_R を学習可能 (Transport layer able to learn MMS_R) | 3.3.2 | x | ||||
| - 再構成タイムアウト時に ICMP タイムアウト送信 (Send ICMP Time Exceeded on reassembly timeout) | 3.3.2 | x | ||||
| 固定再構成タイムアウト値 (Fixed reassembly timeout value) | 3.3.2 | x | ||||
| - MMS_S を上位層へ渡す (Pass MMS_S to higher layers) | 3.3.3 | x | ||||
| - 外出パケットのローカルフラグメンテーション (Local fragmentation of outgoing packets) | 3.3.3 | x | ||||
| さもなくば MMS_S より大きく送信しない (Else don't send bigger than MMS_S) | 3.3.3 | x | ||||
| - 非ローカル宛先に最大 576 送信 (Send max 576 to off-net destination) | 3.3.3 | x | ||||
| - All-Subnets-MTU 設定フラグ (All-Subnets-MTU configuration flag) | 3.3.3 | x | ||||
| マルチホーミング (MULTIHOMING): | ||||||
| - 応答を特定宛先と同じアドレスに (Reply with same addr as spec-dest addr) | 3.3.4.2 | x | ||||
| - アプリケーションがローカル IP アドレス選択可能 (Allow application to choose local IP addr) | 3.3.4.2 | x | ||||
| - 「誤った」インタフェースのデータグラム静粋破棄 (Silently discard d'gram in "wrong" interface) | 3.3.4.2 | x | ||||
| - 「正しい」インタフェースのみから送信 (Only send d'gram through "right" interface) | 3.3.4.2 | x | 4 | |||
| ソースルート転送 (SOURCE-ROUTE FORWARDING): | ||||||
| - ソースルートオプション付きデータグラム転送 (Forward datagram with Source Route option) | 3.3.5 | x | 1 | |||
| 対応するゲートウェイ規則遵守 (Obey corresponding gateway rules) | 3.3.5 | x | 1 | |||
| ゲートウェイ規則による TTL 更新 (Update TTL by gateway rules) | 3.3.5 | x | 1 | |||
| ICMP エラーコード 4、5 生成可能 (Able to generate ICMP err code 4, 5) | 3.3.5 | x | 1 | |||
| IP 送信元アドレスはローカルホストでない (IP src addr not local host) | 3.3.5 | x | 1 | |||
| タイムスタンプ、レコードルートオプション更新 (Update Timestamp, Record Route options) | 3.3.5 | x | 1 | |||
| 非ローカル SR の設定可能スイッチ (Configurable switch for non-local SRing) | 3.3.5 | x | 1 | |||
| デフォルトでオフ (Defaults to OFF) | 3.3.5 | x | 1 | |||
| 非ローカル SR のゲートウェイアクセス規則満足 (Satisfy gwy access rules for non-local SRing) | 3.3.5 | x | 1 | |||
| 転送しない場合、宛先到達不能（コード 5）送信 (If not forward, send Dest Unreach (cd 5)) | 3.3.5 | x | 2 | |||
| ブロードキャスト (BROADCAST): | ||||||
| - IP 送信元アドレスをブロードキャストアドレスに (Broadcast addr as IP source addr) | 3.2.1.3 | x | ||||
| - 0 および -1 ブロードキャスト形式両方受信可 (Receive 0 or -1 broadcast formats OK) | 3.3.6 | x | ||||
| - 0 または -1 ブロードキャスト送信設定オプション (Config'ble option to send 0 or -1 b'cast) | 3.3.6 | x | ||||
| デフォルトは -1 ブロードキャスト (Default to -1 broadcast) | 3.3.6 | x | ||||
| - すべてのブロードキャストアドレス形式認識 (Recognize all broadcast address formats) | 3.3.6 | x | ||||
| - リンク層ブロードキャストで IP ブロード/マルチキャスト使用 (Use IP b'cast/m'cast addr in link-layer b'cast) | 3.3.6 | x | ||||
| - リンク層のみのブロードキャストデータグラム静粋破棄 (Silently discard link-layer-only b'cast dg's) | 3.3.6 | x | ||||
| - 接続ネットワークに限定ブロードキャスト使用 (Use Limited Broadcast addr for connected net) | 3.3.6 | x | ||||
| マルチキャスト (MULTICAST): | ||||||
| - ローカル IP マルチキャストサポート (RFC-1112) (Support local IP multicasting (RFC-1112)) | 3.3.7 | x | ||||
| - IGMP サポート (RFC-1112) (Support IGMP (RFC-1112)) | 3.3.7 | x | ||||
| - 起動時にすべてのホストグループ参加 (Join all-hosts group at startup) | 3.3.7 | x | ||||
| - 上位層がインタフェースのマルチキャスト能力を学習 (Higher layers learn i'face m'cast capability) | 3.3.7 | x | ||||
| インタフェース (INTERFACE): | ||||||
| - トランスポート層がすべての IP メカニズム使用可能 (Allow transport layer to use all IP mechanisms) | 3.4 | x | ||||
| - インタフェース識別をトランスポート層へ渡す (Pass interface ident up to transport layer) | 3.4 | x | ||||
| - すべての IP オプションをトランスポート層へ渡す (Pass all IP options up to transport layer) | 3.4 | x | ||||
| - トランスポート層が特定 ICMP メッセージ送信可能 (Transport layer can send certain ICMP messages) | 3.4 | x | ||||
| - 指定 ICMP メッセージをトランスポート層へ渡す (Pass spec'd ICMP messages up to transp. layer) | 3.4 | x | ||||
| IP ヘッダ + 元の 8 バイト以上含める (Include IP hdr+8 octets or more from orig.) | 3.4 | x |
脚注 (Footnotes):
(1) その特性が実装されている場合のみ。 (2) データグラムが ICMP エラーメッセージである場合、この要件は無効になる。 (3) その特性が実装され「オン」に設定されている場合のみ。 (4) 組み込みゲートウェイ機能がある場合、またはソースルーティングによる場合を除く。