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)
必须 (MUST) 验证 IP 头部中的版本字段（VERSION）等于 4。如果版本不等于 4，则 必须 (MUST) 静默丢弃该数据报；也可以生成 ICMP 参数问题消息。
3.2.1.2 头部校验和 (Header Checksum)
必须 (MUST) 验证传入 IP 数据报的头部校验和（HEADER CHECKSUM）；如果校验和错误，则 必须 (MUST) 静默丢弃该数据报。
DISCUSSION (讨论)：
校验和用于捕获头部在传输过程中发生的错误。请注意，这与更高层协议（如 TCP 或 UDP）中的端到端校验和不同。
3.2.1.3 地址 (Addresses)
(1) 源地址 (Source Address)
必须 (MUST) 验证传入数据报的源地址（SOURCE ADDRESS）不是广播或组播地址（见下文）；如果不是，则 必须 (MUST) 静默丢弃该数据报。
(2) 目的地址 (Destination Address)
数据包能够寻址到一个 IP 网络、子网或主机。寻址到一个主机的 IP 地址称为一个 "特定目的地址 (specific-destination address)"。特定目的地址要么是主机的 IP 地址，要么是广播或组播地址（见第 3.3.6 节与第 3.3.7 节）。
IP 数据报的目的地址 可以 (MAY) 是以下四种标准 IP 广播地址形式之一：
(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) 识别并接受这些非标准广播地址。
主机 必须 (MUST) 静默丢弃目的地址不是该主机自身 IP 地址、也不是有效广播或组播地址的传入数据报。然而，如果主机作为网关转发数据报（见第 3.3.5 节），则其处理不同于此处规定（参见 [INTRO:2]）。
如果主机接收到寻址到链路层广播地址（见第 2.4 节）的数据报，但其 IP 目的地址不是有效的 IP 广播或组播地址，则 应该 (SHOULD) 静默丢弃该数据报。
DISCUSSION (讨论)：
上述规则 (1) 和 (2) 结合起来，防止主机接受以下任何数据报：其目的地址无效、其源地址无效，或源地址为广播/组播地址。特别地，这可以防止 "Land" 类攻击（源地址等于目的地址的数据报）。
特定目的地址的概念用于区分数据报的真实目的地址（即使它是广播或组播）与 IP 目的地址字段中的值在本地网络解释方式之间的差异。
(3) 子网寻址 (Subnet Addressing)
主机 必须 (MUST) 实现子网寻址（如 RFC-950 [IP:3] 所定义）。这意味着地址掩码（ADDRESS MASK）用于确定 IP 目的地址中的哪些位标识网络/子网，哪些位标识主机。
(4) 无效的源地址 (Invalid Source Address)
IP 层 必须 (MUST) 在将传入数据报向上传递到传输层之前，检查源地址字段；如果源地址是 0、广播地址或组播地址，则 必须 (MUST) 静默丢弃该数据报。
3.2.1.4 重组 (Reassembly)
IP 层 必须 (MUST) 实现传入 IP 数据报的重组（见第 3.3.2 节）。
3.2.1.5 标识字段 (Identification)
如果主机不使用标识（IDENTIFICATION）字段，则它 可以 (MAY) 在传出数据报中将该字段置为零，或置为某个本地唯一的值。应该 (SHOULD) 避免在多个相同的数据报副本中保留相同的标识字段值。
DISCUSSION (讨论)：
标识字段用于区分一个数据报的不同副本（例如因源路由而多次发送）。如果同一数据报被发送多次且标识字段保持不变，接收方可能错误地将其视为重复分片而丢弃。
3.2.1.6 服务类型 (Type-Of-Service)
IP 头部包含一个服务类型（TOS）字段，如前所述。传输层 必须 (MUST) 能够设置传出数据报的 TOS 值；该值 必须 (MUST) 透明地传递到 IP 层。应该 (SHOULD) 将接收到的 TOS 值向上传递到传输层。
如果 IP 层实现了 RFC-795 [IP:13] 中定义的链路层映射，则 可以 (MAY) 使用这些映射来选择发送数据报的链路层优先级或服务类别。
DISCUSSION (讨论)：
TOS 字段当前的实现在全局互联网中尚未被广泛使用，但主机应当支持设置该字段，以便在这些机制生效时能够立即发挥作用。
3.2.1.7 生存时间 (Time-To-Live)
传出数据报的 TTL（生存时间）字段 必须 (MUST) 由发送方设置。不得 (MUST NOT) 发送 TTL 为 0 的数据报。不得 (MUST NOT) 丢弃接收到的 TTL 小于 2 的数据报（网关才会对 TTL 减 1 并在为 0 时丢弃）。
生存时间 必须 (MUST) 可由传输层设置，该值 必须 (MUST) 透明地传递到 IP 层。固定的 TTL 值 必须 (MUST) 可配置。
3.2.1.8 IP 选项 (IP Options)
(1) 选项处理总则 (General Option Processing)
IP 层 必须 (MUST) 允许传输层指定要在传出数据报中发送的 IP 选项，并且 必须 (MUST) 将接收到的所有 IP 选项透明地传递给更高层。IP 层 必须 (MUST) 静默忽略它不理解的选项。
如果 IP 层接收到一个它不理解但带有长度字段的 IP 选项，则 必须 (MUST) 跳过该选项继续处理头部。如果选项长度字段为零或导致越界，则 必须 (MUST) 处理为错误（例如发送 ICMP 参数问题消息）。
(2) 选项格式 (Option Format)
各 IP 选项的格式详见 RFC-791。此处不再赘述。
(3) 源路由选项 (Source Route Option)
主机 必须 (MUST) 能够发起和终止源路由（SOURCE ROUTE）选项；也就是说，主机必须能够在传出数据报中插入源路由选项，并必须能够处理传入数据报中的源路由选项。
如果一个传入数据报携带源路由选项且尚未完成，则主机 必须 (MUST) 将该数据报向上传递到传输层（因为完成的源路由由传输层处理）。如果源路由已完成，则 必须 (MUST) 将带有完成标记的数据报传递到传输层。
当主机作为网关转发源路由数据报时（见第 3.3.5 节），它 必须 (MUST) 按照网关规范更新源路由选项，并构建一个正确（无冗余）的返回路由。
一个 IP 头部中 可以 (MAY) 包含多个源路由选项。
(4) 记录路由选项 (Record Route Option)
主机 可以 (MAY) 在传出数据报中插入记录路由（RECORD ROUTE）选项，并且 可以 (MAY) 处理传入数据报中的该选项。对于要求支持此选项的主机，其 IP 层 必须 (MUST) 按 RFC-791 的规定正确更新该选项。
(5) 时间戳选项 (Time Stamp Option)
主机 可以 (MAY) 在传出数据报中插入时间戳（TIME STAMP）选项，并正确处理传入数据报中的该选项。
(6) 流标识符选项 (Stream Identifier Option)
主机 可以 (MAY) 发送流标识符（STREAM IDENTIFIER）选项，并且 必须 (MUST) 静默忽略接收到的该选项（因为该选项已被废弃）。
(7) 安全选项 (Security Option)
主机 可以 (MAY) 实现 IP 安全（SECURITY）选项 [IP:8]。如果该选项被实现，则其处理方式必须符合 RFC-791 与 RFC-1108。
3.2.2 互联网控制消息协议 -- ICMP (Internet Control Message Protocol -- ICMP)
ICMP 消息的格式与处理由 RFC-792 规定。此处只讨论与主机实现相关的要点。
(1) 消息处理总则 (General Message Processing)
主机 必须 (MUST) 静默丢弃类型未知的 ICMP 消息。对于 ICMP 错误消息，必须 (MUST) 在消息中包含至少 8 个字节的原始数据报（即原始 IP 头部加 8 个字节），并且所包含的原始数据报字节 必须 (MUST) 与接收到的内容完全相同。
ICMP 错误消息 必须 (MUST) 被解复用到正确的传输层协议（基于所包含的原始 IP 头部中的协议字段）。
(2) 目的不可达 (Destination Unreachable)
当 IP 层无法投递数据报时，它 必须 (MUST) 能够生成目的不可达（DESTINATION UNREACHABLE）消息，并支持以下代码：
- 代码 2（协议不可达）
- 代码 3（端口不可达）
ICMP 目的不可达消息 必须 (MUST) 向上传递到更高层。更高层 应该 (SHOULD) 对目的不可达消息采取适当动作（例如终止相关连接）。
主机 必须 (MUST) 将目的不可达消息仅作为提示来解释（即，它不强制立即采取动作，除非相关传输协议/应用要求）。
(3) 源抑制 (Source Quench)
如果主机的缓冲超过限制，它 可以 (MAY)（并且 应该 (SHOULD)）发送源抑制（SOURCE QUENCH）消息。收到的源抑制消息 必须 (MUST) 向上传递到更高层，更高层 应该 (SHOULD) 据此降低发送速率。
(4) 超时 (Time Exceeded)
收到的超时（TIME EXCEEDED）消息 必须 (MUST) 向上传递到更高层。
(5) 参数问题 (Parameter Problem)
主机 应该 (SHOULD) 在检测到 IP 头部中的错误参数时发送参数问题（PARAMETER PROBLEM）消息；收到的参数问题消息 必须 (MUST) 向上传递到更高层，并且 可以 (MAY)（应该 (SHOULD)）向用户报告该问题。
(6) 回显请求/应答 (Echo Request/Reply)
主机 必须 (MUST) 实现回显服务器（ECHO SERVER，响应回显请求）和回显客户端（ECHO CLIENT，发送回显请求）。回显请求 应该 (SHOULD) 被发送。
对于广播地址的回显请求 应该 (SHOULD) 静默丢弃；对于组播地址的回显请求 应该 (SHOULD) 静默丢弃。回显应答的源地址 必须 (MUST) 使用原始请求的特定目的地址。回显应答 必须 (MUST) 在数据中回送与请求相同的字节。回显应答 必须 (MUST) 向上传递到更高层。回显应答 应该 (SHOULD) 反射请求中的记录路由与时间戳选项；必须 (MUST) 反转并反射源路由选项。
(7) 信息请求/应答 (Information Request/Reply)
主机 可以 (MAY) 实现信息请求与信息应答消息。
(8) 时间戳与时间戳应答 (Timestamp and Timestamp Reply)
主机 可以 (MAY) 实现时间戳（TIMESTAMP）与时间戳应答消息。若实现，则 应该 (SHOULD) 最小化延迟的变异性，应该 (SHOULD) 静默丢弃广播时间戳与组播时间戳，时间戳应答的源地址 必须 (MUST) 使用特定目的地址，且 必须 (MUST) 遵守 RFC-792 中 "标准值" 的规则，并 必须 (MUST) 将时间戳应答向上传递到更高层。
(9) 地址掩码请求/应答 (Address Mask Request/Reply)
主机 必须 (MUST) 使地址掩码（ADDRESS MASK）可由配置指定，并且 必须 (MUST) 支持地址掩码的静态配置。主机 可以 (MAY) 在引导过程中动态获取地址掩码（通过引导协议），可以 (MAY) 通过 ICMP 地址掩码请求/应答获取地址掩码。如果在合理时间内未收到应答，则 必须 (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 数据报时，它必须决定使用哪个物理接口以及哪个第一跳网关（如果目的主机不在所连接的网络上）。这一决策过程称为 "路由 (routing)"。
主机 必须 (MUST) 在判断是否 "本地（所连接网络）" 与 "远端（非所连接网络）" 时使用地址掩码。
主机 必须 (MUST) 能够在所连接网络没有配置任何网关的情况下正常运行。
DISCUSSION (讨论)：
路由是互联网架构中最复杂且仍在演进的领域之一。主机不应实现完整的网关路由协议，而应依赖于简单的机制：默认网关、重定向消息和路由缓存。
3.3.1.2 路由缓存与静态路由 (Route Cache and Static Routes)
主机 必须 (MUST) 维护一个 "路由缓存 (route cache)"，记录到各目的网络/主机的下一跳网关。主机 必须 (MUST) 在路由缓存中找不到表项时使用默认网关。主机 必须 (MUST) 支持多个默认网关。
主机 可以 (MAY) 提供一张静态路由表（static routes）；这些静态路由 可以 (MAY) 被设置为可被重定向消息覆盖或不可覆盖。
DISCUSSION (讨论)：
重定向（Redirect）消息由网关发送，以告知主机针对某个特定目的主机有更好的第一跳网关。主机在收到重定向消息时 必须 (MUST) 更新其路由缓存。主机 必须 (MUST) 同时处理主机重定向（Host Redirect）与网络重定向（Net Redirect）；在主机中这两种重定向应当被同等对待。
非法的重定向消息（例如指向并非直接连接网络的网关）应该 (SHOULD) 被丢弃。
3.3.1.3 路由缓存的键 (Route Cache Keying)
路由缓存 应该 (SHOULD) 以目的主机地址（而非目的网络地址）为键，并且 应该 (SHOULD) 在缓存中包含 TOS 值。
DISCUSSION (讨论)：
以主机地址为键可以避免同一网络上不同主机因不同路径导致的问题，并支持基于每个目的主机的更精细路由。
3.3.1.4 失效网关检测 (Dead Gateway Detection)
主机 必须 (MUST) 能够检测下一跳网关的失效。主机 不得 (MUST NOT) 假设路由永远有效。
DISCUSSION (讨论)：
有若干技术可用于检测失效网关。一种方法是持续 ping 网关，但这会产生过多流量，因此 应该 (SHOULD) 仅在确有流量要发送时才 ping，且 应该 (SHOULD) 仅在缺乏正向指示时才 ping。更高层与更低层都可以给出投递成功/失败的建议（advice）。
另一种常见的技术（被动侦听网关路由协议）不被推荐（见下文）。
3.3.1.5 新网关选择 (New Gateway Selection)
如果失效的网关不是当前默认网关，IP 层可以立即切换到某个默认网关。如果失效的是当前默认网关，则 IP 层 必须 (MUST) 选择一个不同的默认网关（假设已知多个默认网关），用于失效的路由以及建立新路由。
DISCUSSION (讨论)：
当网关失效时，所连接网络上的其他网关将通过某种网关间路由协议得知该失效。但这不会立即发生，因为网关路由协议的稳定时间通常为 30–60 秒。如果在网关达成一致前主机就切换到替代网关，新的目标网关很可能将数据报转发给失效的网关并回送一个指向失效网关的重定向。结果是在网关稳定期间，主机路由缓存内容可能出现快速振荡。有人建议死网关逻辑应包含某种滞后（hysteresis）机制以防止此类振荡，但经验表明这种振荡并无危害。
IMPLEMENTATION (实现)：
选择新默认网关的一种实现技术是简单地在主机列表中的默认网关间轮询（round-robin）；另一种是按优先级对网关排序，当当前默认网关不是最高优先级时，缓慢地 "ping" 更高优先级的网关以检测其何时恢复服务。
3.3.1.6 初始化 (Initialization)
以下信息 必须 (MUST) 可配置：
(1) IP 地址（一个或多个）。
(2) 地址掩码（一个或多个）。
(3) 默认网关列表，带有优先级。
必须 (MUST) 提供手动输入这些配置数据的方法。此外，可以使用多种方法动态确定这些信息；参见 [INTRO:1] 中的 "主机初始化 (Host Initialization)" 章节。
DISCUSSION (讨论)：
某些主机实现通过在广播网络上侦听网关协议来获知存在哪些网关。一种标准的默认网关发现方法正在制定中。
3.3.2 重组 (Reassembly)
IP 层 必须 (MUST) 实现 IP 数据报的重组。
我们将能够被重组的最大数据报大小记为 EMTU_R（"有效接收 MTU"）；这有时被称为 "重组缓冲区大小 (reassembly buffer size)"。EMTU_R 必须 (MUST) 大于或等于 576，应该 (SHOULD) 可配置或为 "无限 (indefinite)"，并且 应该 (SHOULD) 大于或等于所连接网络的 MTU。
DISCUSSION (讨论)：
不应当将固定的 EMTU_R 上限固化在代码中，因为某些应用层协议要求的 EMTU_R 值大于 576。
IMPLEMENTATION (实现)：
实现可以为每个数据报使用一个连续的重组缓冲区，也可以使用更复杂的数据结构，对重组后数据报的大小不加确定限制；在后一种情况下，称 EMTU_R 为 "无限"。
从逻辑上讲，重组只是将每个分片复制到分组缓冲区中的正确偏移处。注意，如果连续的重传使用了不同的打包方式但相同的重组标识（Id），分片可能会重叠。
重组的难点在于簿记（bookkeeping），以确定数据报的所有字节何时已被重组完毕。我们推荐 Clark 的算法 [IP:10]，它不需要额外的数据空间来做簿记。但请注意，与 [IP:10] 相反，第一个分片的头部需要被保存，以便包含在可能的 ICMP 超时（重组超时）消息中。
必须 (MUST) 存在一种机制，使传输层能够获知 MMS_R —— 可以在一个 IP 数据报中接收并重组的最大消息大小（见第 3.4 节的 GET_MAXSIZES 调用）。如果 EMTU_R 不是无限的，则 MMS_R 的值为：
MMS_R = EMTU_R - 20
因为 20 是 IP 头部的最小大小。
必须 (MUST) 存在一个重组超时。重组超时值 应该 (SHOULD) 是一个固定值，而不是取自剩余 TTL。建议该值在 60 秒到 120 秒之间。如果超时到期，则部分重组的数据报 必须 (MUST) 被丢弃，并向源主机发送一个 ICMP 超时消息（前提是已收到分片零）。
DISCUSSION (讨论)：
IP 规范称重组超时应为 IP 头部中的剩余 TTL，但这并不好用，因为网关通常将 TTL 视为简单的跳数而非经过的时间。如果重组超时过小，数据报会被不必要地丢弃，通信可能失败。超时至少需要与互联网典型的跨网最大延迟一样大。一个现实的最小重组超时是 60 秒。
有人建议缓存由传输协议为各个目的主机测量的往返时间，并用这些值来动态确定合理的重组超时值。对此方法的进一步研究尚待进行。
如果重组超时设置得过高，接收主机中的缓冲区资源将被占用过久，且 MSL（最大段寿命）[TCP:1] 将不必要地变大。MSL 控制着使用不同 16 位标识（Ident）字段值发送分片数据报的最大速率；较大的 MSL 会降低最大速率。TCP 规范 [TCP:1] 武断地假设 MSL 为 2 分钟，这为合理的重组超时值设定了上限。
3.3.3 分片 (Fragmentation)
可选地，IP 层 可以 (MAY) 实现一种机制来故意对传出的数据报进行分片。
我们将 EMTU_S（"有效发送 MTU"）记为对于给定的 IP 源地址与目的地址组合（可能还包括 TOS）所能发送的最大 IP 数据报大小。
主机 必须 (MUST) 实现一种机制，使传输层能够获知 MMS_S —— 对于给定的 {源, 目的, TOS} 三元组所能发送的最大传输层消息大小（见第 3.4 节的 GET_MAXSIZES 调用）。如果不进行本地分片，则 MMS_S 的值为：
MMS_S = EMTU_S - <IP 头部大小>
且 EMTU_S 必须小于或等于对应于数据报源地址的网络接口的 MTU。注意，此方程中的 <IP 头部大小> 将为 20，除非 IP 为自己插入 IP 选项而保留了空间（除传输层插入的任何选项之外）。
不进行本地分片的主机 必须 (MUST) 确保传输层（针对 TCP）或应用层（针对 UDP）从 IP 层获得 MMS_S，并且不发送超过 MMS_S 大小的数据报。
通常希望避免本地分片，并选择足够低的 EMTU_S 以避免路径上任何网关处的分片。在缺乏路径上最小 MTU 的实际知识时，IP 层 应该 (SHOULD) 在目的地址不在所连接网络上时使用 EMTU_S <= 576，否则使用所连接网络的 MTU。
每个物理接口的 MTU 必须 (MUST) 可配置。
主机 IP 层实现 可以 (MAY) 有一个配置标志 "All-Subnets-MTU（所有子网 MTU）"，表示所连接网络的 MTU 将用于同一网络内不同子网上的目的地址，但不用于其他网络。因此，该标志导致使用网络类别掩码而非子网地址掩码来选择 EMTU_S。对于多宿主主机，每个网络接口都需要一个 "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) 理想情况下，主机应将给定目的的 EMTU_S 限制为路径上所有网络的最小 MTU，以避免任何分片。IP 分片虽然形式上正确，但会造成严重的传输协议性能问题，因为单个分片的丢失意味着该段中的所有分片都必须重传 [IP:9]。
由于互联网中几乎所有网络当前都支持 576 或更大的 MTU，我们强烈建议使用 576 作为发往非本地网络的数据报大小。
有人建议，主机可以通过发送一个偏移量为零的数据报分片，并等待接收方超时重组（无法完成！）后返回 ICMP 超时消息来确定给定路径上的 MTU。该消息将在其正文中包含最大的剩余分片头部。更直接的机制正在试验中，但尚未被采用（例如见 RFC-1063）。
3.3.4 本地多宿主 (Local Multihoming)
3.3.4.1 引言 (Introduction)
多宿主主机拥有多个 IP 地址，我们可以将其视为 "逻辑接口 (logical interfaces)"。这些逻辑接口可以关联到一个或多个物理接口，而这些物理接口可以连接到相同或不同的网络。
以下是一些重要的多宿主情形：
(a) 多个逻辑网络 (Multiple Logical Networks)
互联网架构师设想每个物理网络拥有单一的、唯一的 IP 网络（或子网）编号。然而，LAN 管理员有时发现违反这一假设是有用的，即在一个物理所连接网络上运行多个逻辑网络。
如果连接到这样一个物理网络的主机被配置为处理 N 个不同逻辑网络的流量，那么该主机将拥有 N 个逻辑接口。这些接口可以共享一个物理接口，也可以使用 N 个物理接口连接到同一个网络。
(b) 多个逻辑主机 (Multiple Logical Hosts)
当主机拥有多个 IP 地址，且这些地址具有相同的 <网络号> 部分（以及相同的 <子网号> 部分，如果存在）时，这些逻辑接口被称为 "逻辑主机 (logical hosts)"。这些逻辑接口可以共享单一物理接口，也可以使用独立的物理接口连接到同一个物理网络。
(c) 简单多宿主 (Simple Multihoming)
在这种情况下，每个逻辑接口被映射到一个独立的物理接口，且每个物理接口连接到不同的物理网络。术语 "多宿主" 最初仅用于这种情况，但现在应用得更广。
带有嵌入式网关功能的主机通常属于简单多宿主情形。但请注意，一台主机可以在不包含嵌入式网关的情况下简单地多宿主，即不将数据报从一个所连接网络转发到另一个。
这种情况提出了最困难的路由问题。接口的选择（即第一跳网络的选择）可能会显著影响性能甚至互联网远端的连通性。
最后，我们注意到另一种 不是 多宿主的可能性：一个逻辑接口可以绑定到多个物理接口，以便通过在这些直接相连的机器之间提供替代的物理路径来提高可靠性或吞吐量。例如，两个系统可能由多条点到点链路连接。我们称之为 "链路层复用 (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) 选择一个源地址。该选择的规则如下文所述。
与多宿主相关的两个关键要求议题是：
(A) 主机 可以 (MAY) 静默丢弃其目的地址与接收它的物理接口不对应的传入数据报。
(B) 主机 可以 (MAY) 将自己限制为仅通过与其 IP 源地址对应的物理接口来发送（非源路由的）IP 数据报。
DISCUSSION (讨论)：
互联网主机实现者使用了两种不同的多宿主概念模型，简述如下。本文档对哪种模型更优不持立场；每种似乎都有其用武之地。这种矛盾态度反映在议题 (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 源地址至少应有一个默认网关，最好是多个默认网关。
-
弱端系统模型 (Weak ES Model)
这种观点淡化 ES/IS 区分，因此会在上述议题 (A) 和 (B) 中以 不得 (MUST NOT) 替代 可以 (MAY)。对于侦听网关路由协议的主机，此模型可能更自然，并且对于带有嵌入式网关功能的主机是必需的。
弱 ES 模型可能导致重定向机制失效。如果数据报被发出到一个与目的地址不对应的物理接口，第一跳网关将无法意识到它何时需要发送重定向。另一方面，如果主机具有嵌入式网关功能，那么它无需侦听重定向就能获得路由信息。
在弱 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 节），因此主机可以将这两个功能的实现合并。
3.3.5 源路由转发 (Source Route Forwarding)
在以下限制条件下，主机 可以 (MAY) 作为源路由中的中间跳，将源路由数据报转发到下一个指定跳。
然而，在执行这种类似网关的功能时，主机 必须 (MUST) 遵守网关转发源路由数据报的所有相关规则 [INTRO:2]。这包括以下内容（这些特定条款覆盖本文档前面给出的相应主机条款）：
(A) TTL（参见第 3.2.1.7 节）
TTL 字段 **必须 (MUST)** 按 [INTRO:2] 中对网关的规定进行递减，并可能因此丢弃数据报。
(B) ICMP 目的不可达（参见第 3.2.2.1 节）
主机 **必须 (MUST)** 能够生成带有以下代码的 "目的不可达" 消息：
4 （需要分片但 DF 置位）——当源路由数据报无法分片以适应目标网络时；
5 （源路由失败）——当源路由数据报无法被转发时，例如由于路由问题或严格源路由的下一跳不在所连接网络上时。
(C) IP 源地址（参见第 3.2.1.3 节）
被转发的源路由数据报 **可以 (MAY)**（并且通常会）拥有一个并非转发主机自身 IP 地址之一的源地址。
(D) 记录路由选项（参见第 3.2.1.8d 节）
转发包含记录路由选项的源路由数据报的主机 **必须 (MUST)** 更新该选项（如果其仍有空间）。
(E) 时间戳选项（参见第 3.2.1.8e 节）
转发包含时间戳选项的源路由数据报的主机 **必须 (MUST)** 按照该选项的规则，将当前时间戳加入该选项。
为了定义限制主机转发源路由数据报的规则，我们使用术语 "本地源路由 (local source-routing)" 表示下一跳将通过数据报到达时所经由的同一物理接口；否则为 "非本地源路由 (non-local source-routing)"。
- 主机被允许不受限制地执行本地源路由。
- 支持非本地源路由的主机 必须 (MUST) 有一个可配置开关来禁用转发，且该开关 必须 (MUST) 默认为禁用。
- 主机 必须 (MUST) 满足 [INTRO:2] 中限制非本地转发的可配置策略过滤器的所有网关要求。
如果主机收到一个带有不完整源路由的数据报，但因某种原因未转发它，则主机 应该 (SHOULD) 返回一个 ICMP "目的不可达（代码 5，源路由失败）" 消息，除非该数据报本身是 ICMP 错误消息。
3.3.6 广播 (Broadcasts)
第 3.2.1.3 节定义了四种标准 IP 广播地址形式：
受限广播 (Limited Broadcast)： {-1, -1}
定向广播 (Directed Broadcast)： {<网络号>, -1}
子网定向广播 (Subnet Directed Broadcast)： {<网络号>, <子网号>, -1}
全子网定向广播 (All-Subnets Directed Broadcast)： {<网络号>, -1, -1}
主机 必须 (MUST) 识别传入数据报目的地址中的上述任何形式。
有一类主机* 使用非标准的广播地址形式，以 0 替代 -1。所有主机 应该 (SHOULD) 识别并接受任何这些非标准广播地址作为传入数据报的目的地址。主机 可以 (MAY) 为每个物理接口可选地提供一个配置选项来选择广播地址的 0 形式或 -1 形式，但该选项 应该 (SHOULD) 默认为标准（-1）形式。
*4.2BSD Unix 及其衍生系统，但不包括 4.3BSD。
当主机将数据报发送到链路层广播地址时，IP 目的地址 必须 (MUST) 是一个合法的 IP 广播地址或 IP 组播地址。
主机 应该 (SHOULD) 静默丢弃通过链路层广播（见第 2.4 节）接收，但未指定 IP 组播或广播目的地址的数据报。
主机 应该 (SHOULD) 使用受限广播地址向所连接网络进行广播。
DISCUSSION (讨论)：
使用受限广播地址而非定向广播地址可能会提高系统的健壮性。问题常常由不理解大量广播地址（见第 3.2.1.3 节）的机器，或对哪些广播地址在使用有不同看法的机器引起。后者的典型例子是不理解子网划分但连接到一个已划分子网的网络上的机器。为所连接网络发送子网广播会让那些机器困惑，它们会将其视为发往其他某台主机的消息。
关于寻址到受限广播地址的数据报是否应当从多宿主主机的所有接口发出，一直存在讨论。本规范对此问题不持立场。
3.3.7 IP 多播 (IP Multicasting)
主机 应该 (SHOULD) 在所有已定义了从 D 类 IP 地址到链路层地址映射的所连接网络上支持本地 IP 多播（见下文）。对本地 IP 多播的支持包括发送多播数据报、加入多播组并接收多播数据报，以及离开多播组。这意味着支持 [IP:4] 的全部内容（IGMP 协议本身除外，它是 可选 (OPTIONAL) 的）。
DISCUSSION (讨论)：
IGMP 为能够进行多播路由的网关提供所需信息，以支持跨多个网络的 IP 多播。目前，多播路由网关尚处于实验阶段，并未广泛可用。对于未连接到拥有多播路由网关的网络，或不需要接收源自其他网络的多播数据报的主机而言，IGMP 毫无用处，因此目前是可选的。然而，[IP:4] 的其余部分目前被推荐使用，目的是提供对本地网络多播寻址的 IP 层访问，作为本地广播寻址的可取替代方案。预计在未来多播路由网关变得更为普及时，IGMP 会变得被推荐使用。
如果未实现 IGMP，主机 应该 (SHOULD) 仍在其 IP 层初始化时加入 "所有主机 (all-hosts)" 组（224.0.0.1），并在 IP 层活跃的整个期间保持为该组成员。
DISCUSSION (讨论)：
加入 "所有主机" 组将支持多播的严格本地用途，例如网关发现协议，即使未实现 IGMP 也是如此。
IP D 类地址到本地地址的映射目前针对以下类型的网络做了规定：
-
以太网/IEEE 802.3，如 [IP:4] 所定义。
-
任何支持广播但不支持多播寻址的网络：所有 IP D 类地址都映射到本地广播地址。
-
任何类型的点到点链路（如 SLIP 或 HDLC 链路）：不需要映射。所有 IP 多播数据报都在本地帧内原样发送。
其他类型网络的映射将在未来规定。
主机 应该 (SHOULD) 提供一种方式，使更高层协议或应用能够确定主机的哪些所连接网络支持 IP 多播寻址。
3.3.8 错误报告 (Error Reporting)
在切实可行的范围内，主机 必须 (MUST) 在检测到错误时返回 ICMP 错误数据报，除非在某些明确禁止返回 ICMP 错误消息的情况下。
DISCUSSION (讨论)：
数据报网络中一个常见的现象是 "黑洞病 (black hole disease)"：数据报被发送出去，但什么也没有返回。没有任何错误消息，用户很难弄清楚问题出在哪里。
3.4 互联网/传输层接口 (INTERNET/TRANSPORT LAYER INTERFACE)
IP 层与传输层之间的接口 必须 (MUST) 提供对 IP 层所有机制的完全访问，包括选项、服务类型和生存时间。传输层 必须 (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 包含数据报的目的地址。由于这可能是广播或组播地址，因此 必须 (MUST) 传递 SpecDest 参数（RFC-791 中未显示）。参数 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 节。传输层 必须 (MUST) 能够发送某些 ICMP 消息：端口不可达或任何查询类型的消息。当然，此功能可视为 SEND() 调用的特例；为清晰起见我们分开描述。
-
接收 ICMP 消息 (Receive ICMP Message)
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
（参数在 RFC-791 中定义）。
IP 层 必须 (MUST) 将某些 ICMP 消息向上传递给相应的传输层例程。当然，此功能可视为 RECV() 调用的特例；为清晰起见我们分开描述。
对于 ICMP 错误消息，向上传递的数据 必须 (MUST) 包含原始互联网头部加上 ICMP 消息中所包含的原始消息的所有字节。传输层将利用这些数据来定位连接状态信息（如果有）。
特别地，应向上传递以下 ICMP 消息：
- 目的不可达 (Destination Unreachable)
- 源抑制 (Source Quench)
- 回显应答（送往 ICMP 用户接口，除非回显请求源自 IP 层）
- 时间戳应答（送往 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 | ||||
| 在应用层处理远端多宿主 (Handle remote multihoming in application layer) | 3.1 | x | ||||
| 支持本地多宿主 (Support local multihoming) | 3.1 | x | ||||
| 若转发数据报则满足网关规范 (Meet gateway specs if forward datagrams) | 3.1 | x | ||||
| 嵌入式网关的配置开关 (Configuration switch for embedded gateway) | 3.1 | x | 1 | |||
| - 配置开关默认非网关 (- Config switch default to non-gateway) | 3.1 | x | 1 | |||
| - 基于接口数的自动配置 (- Auto-config based on number of interfaces) | 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 | ||||
| - 在一个头部中发送多个 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 | |||
| 非本地源路由的可配置开关 (Configurable switch for non-local SRing) | 3.3.5 | x | 1 | |||
| 默认为关闭 (Defaults to OFF) | 3.3.5 | x | 1 | |||
| 满足非本地源路由的网关访问规则 (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) 除非具有嵌入式网关功能或被源路由。