Skip to main content

3. 互联网层协议 (INTERNET LAYER PROTOCOLS)

3.1 简介 (INTRODUCTION)​

健壮性原则 (Robustness Principle): "在接受时要宽容, 在发送时要保守" 在互联网层尤为重要, 因为一个行为不当的主机可能会拒绝向许多其他主机提供互联网服务。

互联网层使用的协议标准包括:

  • RFC-791 [IP:1] 定义了 IP 协议并介绍了互联网的架构。

  • RFC-792 [IP:2] 定义了 ICMP, 它为 IP 提供路由、诊断和错误功能。尽管 ICMP 消息封装在 IP 数据报中, ICMP 处理被认为是 (并且通常被实现为) IP 层的一部分。参见第 3.2.2 节。

  • RFC-950 [IP:3] 定义了对寻址架构的强制性子网扩展。

  • RFC-1112 [IP:4] 定义了互联网组管理协议 (Internet Group Management Protocol, IGMP), 作为对主机和主机-网关接口的推荐扩展的一部分, 以支持在 IP 级别的互联网范围组播。参见第 3.2.3 节。

IP 组播的目标可以是任意一组互联网主机。IP 组播被设计为某些网络的链路层组播功能的自然扩展, 并且它为本地访问此类链路层组播功能提供了标准方法。

其他重要参考文献列在本文档的第 5 节中。

主机软件的互联网层必须 (MUST) 同时实现 IP 和 ICMP。有关 IGMP 支持的要求, 请参见第 3.3.7 节。

主机 IP 层具有两个基本功能: (1) 为传出的 IP 数据报选择 "下一跳" 网关或主机, (2) 重组传入的 IP 数据报。IP 层还可以 (3) 实现传出数据报的有意分片 (intentional fragmentation)。最后, IP 层必须 (4) 提供诊断和错误功能。我们预计随着进一步开发互联网控制和管理功能, IP 层功能将在未来有所增加。

对于正常数据报, 处理过程很简单。对于传入的数据报, IP 层:

(1) 验证数据报格式是否正确;

(2) 验证它是否发往本地主机;

(3) 处理选项;

(4) 如有必要重组数据报; 以及

(5) 将封装的消息传递给适当的传输层协议模块。

对于传出的数据报, IP 层:

(1) 设置传输层未设置的任何字段;

(2) 在连接的网络上选择正确的第一跳 (这个过程称为 "路由");

(3) 如有必要且实现了有意分片, 则对数据报进行分片 (参见第 3.3.3 节); 以及

(4) 将数据包传递给适当的链路层驱动程序。

如果主机具有多个 IP 地址, 则称该主机为多宿主 (multihomed)。多宿主给协议套件带来了相当大的混乱和复杂性, 这是互联网架构严重未能解决所有问题的一个领域。多宿主有两个不同的问题领域:

(1) 本地多宿主 (Local multihoming) -- 主机本身是多宿主的; 或

(2) 远程多宿主 (Remote multihoming) -- 本地主机需要与远程多宿主主机通信。

目前, 远程多宿主必须 (MUST) 在应用层处理, 如配套 RFC [INTRO:1] 中所述。主机可以 (MAY) 支持本地多宿主, 本文档中对此进行了讨论, 特别是在第 3.3.4 节中。

任何转发由另一台主机生成的数据报的主机都充当网关, 并且必须 (MUST) 符合网关要求 RFC [INTRO:2] 中规定的规范。包含嵌入式网关代码的互联网主机必须 (MUST) 具有配置开关以禁用网关功能, 并且此开关必须 (MUST) 默认为非网关模式。

在此模式下, 通过一个接口到达的数据报将不会转发到另一个主机或网关 (除非它是源路由的), 无论主机是单宿主还是多宿主。如果主机有多个接口, 主机软件绝对不能 (MUST NOT) 自动进入网关模式, 因为机器的操作员可能既不想提供该服务, 也可能不具备这样做的能力。

在以下内容中, 在某些情况下指定的操作是 "静默丢弃" (silently discard) 接收到的数据报。这意味着数据报将在没有进一步处理的情况下被丢弃, 并且主机不会因此发送任何 ICMP 错误消息 (参见第 3.2.2 节)。但是, 为了诊断问题, 主机应该 (SHOULD) 提供记录错误的能力 (参见第 1.2.3 节), 包括静默丢弃的数据报的内容, 并且应该 (SHOULD) 在统计计数器中记录该事件。

讨论 (DISCUSSION): 静默丢弃错误数据报通常旨在防止 "广播风暴" (broadcast storms)。

3.2 协议详解 (PROTOCOL WALK-THROUGH)​

3.2.1 互联网协议 -- IP (Internet Protocol -- IP)​

3.2.1.1 版本号 (Version Number): RFC-791 第 3.1 节​

版本号不是 4 的数据报必须 (MUST) 被静默丢弃。

3.2.1.2 校验和 (Checksum): RFC-791 第 3.1 节​

主机必须 (MUST) 验证每个接收到的数据报的 IP 头部校验和, 并静默丢弃每个具有错误校验和的数据报。

3.2.1.3 寻址 (Addressing): RFC-791 第 3.2 节​

现在有五类 IP 地址: A 类到 E 类。D 类地址用于 IP 组播 [IP:4], 而 E 类地址保留用于实验使用。

组播 (D 类) 地址是一个 28 位逻辑地址, 代表一组主机, 可以是永久的或临时的。永久组播地址由互联网号码分配机构 (Internet Assigned Number Authority) [INTRO:6] 分配, 而临时地址可以动态分配给临时组。组成员身份使用 IGMP [IP:4] 动态确定。

我们现在总结 A、B 和 C 类 IP 地址的重要特殊情况, 使用以下符号表示 IP 地址:

{ <Network-number>, <Host-number> }

或

{ <Network-number>, <Subnet-number>, <Host-number> }

以及符号 "-1" 表示包含全 1 位的字段。此符号并不意味着地址掩码中的 1 位必须是连续的。

(a) 0

此网络上的此主机。绝对不能 (MUST NOT) 发送, 除非作为初始化过程的一部分的源地址, 通过该过程主机学习其自己的 IP 地址。

另请参见第 3.3.6 节了解 0 的非标准用法。

(b) { 0, <Host-number> }

此网络上的指定主机。绝对不能 (MUST NOT) 发送, 除非作为初始化过程的一部分的源地址, 通过该过程主机学习其完整的 IP 地址。

(c) { -1, -1 }

有限广播 (Limited broadcast)。绝对不能 (MUST NOT) 用作源地址。

具有此目标地址的数据报将被连接的物理网络上的每个主机接收, 但不会转发到该网络之外。

(d) { <Network-number>, -1 }

定向广播到指定网络 (Directed broadcast)。绝对不能 (MUST NOT) 用作源地址。

(e) { <Network-number>, <Subnet-number>, -1 }

定向广播到指定子网。绝对不能 (MUST NOT) 用作源地址。

(f) { <Network-number>, -1, -1 }

定向广播到指定子网网络的所有子网。绝对不能 (MUST NOT) 用作源地址。

(g) { 127, <any> }

内部主机环回地址 (Internal host loopback address)。此形式的地址绝对不能 (MUST NOT) 出现在主机之外。

<Network-number> 是管理分配的, 因此其值在整个世界中将是唯一的。

IP 地址不允许 <Host-number>、<Network-number> 或 <Subnet-number> 字段的值为 0 或 -1 (上面列出的特殊情况除外)。这意味着这些字段中的每一个都至少有两位长。

有关广播地址的进一步讨论, 请参见第 3.3.6 节。

主机必须 (MUST) 支持对 IP 的子网扩展 [IP:3]。因此, 将有一个形式为 {-1, -1, 0} 的地址掩码与主机的每个本地 IP 地址相关联; 参见第 3.2.2.9 和 3.3.1.1 节。

当主机发送任何数据报时, IP 源地址必须 (MUST) 是其自己的 IP 地址之一 (但不是广播或组播地址)。

主机必须 (MUST) 静默丢弃不是发往该主机的传入数据报。如果数据报的目标地址字段是以下情况之一, 则传入数据报发往该主机:

(1) (其中一个) 主机的 IP 地址; 或

(2) 对连接的网络有效的 IP 广播地址; 或

(3) 在传入物理接口上主机是其成员的组播组的地址。

对于大多数目的, 发往广播或组播目标的数据报的处理就像它被发往主机的 IP 地址之一一样; 我们使用术语 "特定目标地址" (specific-destination address) 来表示主机的等效本地 IP 地址。

特定目标地址定义为 IP 头部中的目标地址, 除非头部包含广播或组播地址, 在这种情况下, 特定目标是分配给数据报到达的物理接口的 IP 地址。

主机必须 (MUST) 静默丢弃包含根据本节规则无效的 IP 源地址的传入数据报。此验证可以在 IP 层或传输层中的每个协议中完成。

讨论 (DISCUSSION): 地址错误的数据报可能是由单播数据报的链路层广播或由混乱或配置错误的网关或主机引起的。

互联网主机的架构目标是允许 IP 地址成为无特征的 32 位数字, 避免需要了解 IP 地址格式的算法。否则, IP 地址格式或解释的任何未来更改都将需要主机软件更改。但是, 广播和组播地址的验证违反了这一目标; 本文档其他地方描述了其他一些违规行为。

实现者应该意识到, 依赖于所有子网定向广播地址 (f) 的应用程序在某些网络上可能无法使用。所有子网广播目前在供应商网关中没有广泛实现, 即使实现了, 特定的网络管理也可能在网关配置中禁用它。

3.2.1.4 分片和重组 (Fragmentation and Reassembly): RFC-791 第 3.2 节​

互联网模型要求每个主机都支持重组。有关分片和重组的要求, 请参见第 3.3.2 和 3.3.3 节。

3.2.1.5 标识 (Identification): RFC-791 第 3.2 节​

当发送早期数据报的相同副本时, 主机可以 (MAY) 选择在副本中保留相同的 Identification 字段。

讨论 (DISCUSSION): 一些互联网协议专家认为, 当主机发送早期数据报的相同副本时, 新副本应包含相同的 Identification 字段值。有两个建议的优点: (1) 如果数据报被分片并且某些分片丢失, 接收方可能能够从原始数据报和副本的分片重建完整的数据报; (2) 拥塞的网关可能使用 IP Identification 字段 (和 Fragment Offset) 从队列中丢弃重复的数据报。

然而, 在互联网中观察到的数据报丢失模式不利于重传分片填充重组间隙的概率, 而其他机制 (例如, TCP 在重传时重新打包) 往往会阻止重传相同的数据报 [IP:9]。因此, 我们认为重传相同的 Identification 字段是没有用的。此外, 像 UDP 这样的无连接传输协议需要应用程序的配合才能在相同的数据报中保留相同的 Identification 值。

3.2.1.6 服务类型 (Type-of-Service): RFC-791 第 3.2 节​

IP 头部中的 "Type-of-Service" 字节分为两个部分: 优先级 (Precedence) 字段 (高 3 位) 和通常称为 "Type-of-Service" 或 "TOS" 的字段 (低 5 位)。在本文档中, 所有对 "TOS" 或 "TOS 字段" 的引用仅指低 5 位。

优先级字段用于美国国防部的互联网协议应用。在此字段中使用非零值超出了本文档和 IP 标准规范的范围。供应商应咨询国防通信局 (Defense Communication Agency, DCA) 以获取有关 IP 优先级字段及其对其他协议层影响的指导。但是, 供应商应注意, 使用优先级很可能需要以与 TOS 字段传递相同的方式在协议层之间传递其值。

IP 层必须 (MUST) 提供一种方法让传输层设置发送的每个数据报的 TOS 字段; 默认值是全零位。IP 层应该 (SHOULD) 将接收到的 TOS 值向上传递给传输层。

RFC-795 中包含的 TOS 的特定链路层映射不应该 (SHOULD NOT) 被实现。

讨论 (DISCUSSION): 虽然 TOS 字段在过去很少使用, 但预计它将在不久的将来发挥越来越重要的作用。TOS 字段预计将用于控制网关操作的两个方面: 路由和排队算法。有关应用程序指定 TOS 值的要求, 请参见 [INTRO:1] 的第 2 节。

TOS 字段也可以映射到链路层服务选择器。例如, 这已被应用于为不同类别的 TCP 流量提供串行线路的有效共享。但是, RFC-795 中针对 1981 年包含在互联网中的网络建议的映射现在已经过时。

3.2.1.7 生存时间 (Time-to-Live): RFC-791 第 3.2 节​

主机绝对不能 (MUST NOT) 发送生存时间 (TTL) 值为零的数据报。

主机绝对不能 (MUST NOT) 仅因为收到的 TTL 小于 2 而丢弃数据报。

IP 层必须 (MUST) 提供一种方法让传输层设置发送的每个数据报的 TTL 字段。当使用固定的 TTL 值时, 它必须 (MUST) 是可配置的。当前建议的值将在 "Assigned Numbers" RFC 中公布。

讨论 (DISCUSSION): TTL 字段有两个功能: 限制 TCP 段的生存期 (参见 RFC-793 [TCP:1], 第 28 页), 以及终止互联网路由循环。尽管 TTL 是以秒为单位的时间, 但它也具有跳数 (hop-count) 的某些属性, 因为每个网关都需要至少将 TTL 字段减 1。

其意图是 TTL 到期将导致数据报被网关丢弃, 但不会被目标主机丢弃; 但是, 通过转发数据报充当网关的主机必须遵循网关的 TTL 规则。

更高层协议可能希望设置 TTL 以实现对某些互联网资源的 "扩展范围" 搜索。这被一些诊断工具使用, 并且预计对使用 IP 组播定位给定类别的 "最近" 服务器很有用。特定的传输协议也可能希望指定自己对最大数据报生存期的 TTL 限制。

固定值必须至少足够大以覆盖互联网 "直径", 即可能的最长路径。合理的值大约是直径的两倍, 以允许互联网的持续增长。

3.2.1.8 选项 (Options): RFC-791 第 3.2 节​

必须 (MUST) 有一种方法让传输层指定要包含在传输的 IP 数据报中的 IP 选项 (参见第 3.4 节)。

在数据报中接收到的所有 IP 选项 (除了 NOP 或 END-OF-LIST) 必须 (MUST) 传递给传输层 (或者当数据报是 ICMP 消息时传递给 ICMP 处理)。IP 和传输层必须 (MUST) 各自解释它们理解的那些 IP 选项并静默忽略其他选项。

本文档的后续部分讨论了 ICMP、TCP 和 UDP 各自所需的特定 IP 选项支持。

讨论 (DISCUSSION): 将所有接收到的 IP 选项传递给传输层是一种故意的 "违反严格分层" 的做法, 旨在简化未来引入新的与传输相关的 IP 选项。每一层必须挑选出与其自身处理相关的任何选项并忽略其余选项。为此, 除了 NOP 和 END-OF-LIST 之外的每个 IP 选项都将包含其自身长度的规范。

本文档没有定义接收方必须处理同一 IP 头部中的多个选项的顺序。发送多个选项的主机必须意识到, 这会在与源路由选项结合时引入某些选项含义的歧义。

实现 (IMPLEMENTATION): IP 层不能因为选项长度超出可能范围而崩溃。例如, 已经观察到错误的选项长度会使某些 IP 实现陷入无限循环。

以下是特定 IP 选项的要求:

(a) 安全选项 (Security Option)

某些环境要求每个数据报中都包含安全选项; 这样的要求超出了本文档和 IP 标准规范的范围。但请注意, RFC-791 和 RFC-1038 中描述的安全选项已过时。对于国防部应用程序, 供应商应咨询 [IP:8] 以获取指导。

(b) 流标识符选项 (Stream Identifier Option)

此选项已过时; 它不应该 (SHOULD NOT) 发送, 如果收到必须 (MUST) 静默忽略。

(c) 源路由选项 (Source Route Options)

主机必须 (MUST) 支持发起源路由并且必须 (MUST) 能够充当源路由的最终目的地。

如果主机接收到包含已完成源路由的数据报 (即指针指向最后一个字段之外), 则数据报已到达其最终目的地; 收到的选项 (记录的路由) 必须 (MUST) 传递给传输层 (或 ICMP 消息处理)。此记录的路由将被反转并用于为应答数据报形成返回源路由 (参见第 4 节中 IP 选项的讨论)。当构建返回源路由时, 即使记录的路由包含源主机 (参见下面讨论中的情况 (B)), 它也必须 (MUST) 被正确形成。

包含多个源路由选项的 IP 头部绝对不能 (MUST NOT) 发送; 多个源路由选项对路由的影响是实现特定的。

第 3.3.5 节介绍了充当源路由中中间跳的主机的规则, 即转发源路由数据报。

讨论 (DISCUSSION): 如果源路由数据报被分片, 每个分片将包含源路由的副本。由于 IP 选项 (包括源路由) 的处理必须在重组之前进行, 因此在到达最终目的地之前不会重组原始数据报。

假设源路由数据报要从主机 S 通过网关 G1, G2, ... Gn 路由到主机 D。规范中存在一个歧义, 即 S 发出的数据报中的源路由选项应该是 (A) 还是 (B):

(A):  {>>G2, G3, ... Gn, D}     <--- 正确

(B):  {S, >>G2, G3, ... Gn, D}  <---- 错误

(其中 >> 表示指针)。如果发送 (A), 在 D 接收到的数据报将包含选项: {G1, G2, ... Gn >>}, S 和 D 作为 IP 源和目标地址。如果发送 (B), 在 D 接收到的数据报将再次包含 S 和 D 作为相同的 IP 源和目标地址, 但选项将是: {S, G1, ...Gn >>}; 即发起主机将是路由中的第一跳。

(d) 记录路由选项 (Record Route Option)

发起和处理记录路由选项的实现是可选的 (OPTIONAL)。

(e) 时间戳选项 (Timestamp Option)

发起和处理时间戳选项的实现是可选的 (OPTIONAL)。如果实现了它, 则适用以下规则:

  • 发起主机必须 (MUST) 在互联网地址字段未预先指定或其第一个预先指定的地址是主机接口地址的时间戳选项中记录时间戳。

  • 目标主机必须 (MUST) (如果可能) 在将选项传递给传输层或 ICMP 处理之前向时间戳选项添加当前时间戳。

  • 时间戳值必须 (MUST) 遵循第 3.2.2.8 节中为 ICMP 时间戳消息给出的规则。

3.2.2 互联网控制消息协议 -- ICMP (Internet Control Message Protocol -- ICMP)​

ICMP 消息分为两类。

ICMP 错误消息:

  • Destination Unreachable (目标不可达) (参见第 3.2.2.1 节)
  • Redirect (重定向) (参见第 3.2.2.2 节)
  • Source Quench (源抑制) (参见第 3.2.2.3 节)
  • Time Exceeded (超时) (参见第 3.2.2.4 节)
  • Parameter Problem (参数问题) (参见第 3.2.2.5 节)

ICMP 查询消息:

  • Echo (回显) (参见第 3.2.2.6 节)
  • Information (信息) (参见第 3.2.2.7 节)
  • Timestamp (时间戳) (参见第 3.2.2.8 节)
  • Address Mask (地址掩码) (参见第 3.2.2.9 节)

如果接收到未知类型的 ICMP 消息, 它必须 (MUST) 被静默丢弃。

每个 ICMP 错误消息都包含互联网头部和触发错误的数据报的至少前 8 个数据八位字节; 可以 (MAY) 发送超过 8 个八位字节; 此头部和数据必须 (MUST) 与接收到的数据报保持不变。

在那些互联网层需要将 ICMP 错误消息传递给传输层的情况下, IP 协议号必须 (MUST) 从原始头部中提取并用于选择适当的传输协议实体来处理错误。

ICMP 错误消息应该 (SHOULD) 以正常 (即零) TOS 位发送。

在以下情况下绝对不能 (MUST NOT) 发送 ICMP 错误消息:

  • 作为接收 ICMP 错误消息的结果, 或
  • 发往 IP 广播或 IP 组播地址的数据报, 或
  • 作为链路层广播发送的数据报, 或
  • 非初始分片, 或
  • 源地址不定义单个主机的数据报 -- 例如, 零地址、环回地址、广播地址、组播地址或 E 类地址。

注意: 这些限制优先于本文档其他地方发送 ICMP 错误消息的任何要求。

讨论 (DISCUSSION): 这些规则将防止由于主机响应广播数据报返回 ICMP 错误消息而导致的 "广播风暴"。例如, 广播 UDP 段到不存在的端口可能会触发来自所有没有该目标端口客户端的机器的 ICMP 目标不可达数据报洪泛。在大型以太网上, 由此产生的冲突可能会使网络在一秒或更长时间内无法使用。

在连接的网络上广播的每个数据报都应该具有有效的 IP 广播地址作为其 IP 目标 (参见第 3.3.6 节)。但是, 某些主机违反了此规则。因此, 为了确定检测到广播数据报, 要求主机检查链路层广播以及 IP 层广播地址。

实现 (IMPLEMENTATION): 这要求链路层在接收到链路层广播数据报时通知 IP 层; 参见第 2.4 节。

3.2.2.1 目标不可达 (Destination Unreachable): RFC-792​

现定义以下附加代码:

6 = destination network unknown (目标网络未知)
7 = destination host unknown (目标主机未知)
8 = source host isolated (源主机隔离)
9 = communication with destination network administratively prohibited (与目标网络的通信被管理禁止)
10 = communication with destination host administratively prohibited (与目标主机的通信被管理禁止)
11 = network unreachable for type of service (服务类型的网络不可达)
12 = host unreachable for type of service (服务类型的主机不可达)

主机应该 (SHOULD) 在以下情况下生成目标不可达消息并使用代码:

2 (Protocol Unreachable, 协议不可达), 当不支持指定的传输协议时; 或

3 (Port Unreachable, 端口不可达), 当指定的传输协议 (例如 UDP) 无法解复用数据报但没有协议机制通知发送方时。

接收到的目标不可达消息必须 (MUST) 报告给传输层。传输层应该 (SHOULD) 适当地使用该信息; 例如, 参见下面的第 4.1.3.3、4.2.3.9 和 4.2.4 节。具有自己机制通知发送方端口不可达的传输协议 (例如 TCP, 它发送 RST 段) 必须 (MUST) 仍然接受 ICMP 端口不可达用于相同目的。

接收到代码为 0 (Net)、1 (Host) 或 5 (Bad Source Route) 的目标不可达消息可能是由路由瞬态引起的, 因此必须 (MUST) 仅解释为提示, 而不是指定目标不可达的证明 [IP:11]。例如, 它绝对不能 (MUST NOT) 用作死网关的证明 (参见第 3.3.1 节)。

3.2.2.2 重定向 (Redirect): RFC-792​

主机不应该 (SHOULD NOT) 发送 ICMP 重定向消息; 重定向仅由网关发送。

接收重定向消息的主机必须 (MUST) 相应地更新其路由信息。每个主机必须 (MUST) 准备好接受主机和网络重定向, 并按照下面第 3.3.1.2 节中的描述处理它们。

如果重定向指定的新网关地址不在重定向到达的同一连接 (子) 网上 [INTRO:2, 附录 A], 或者如果重定向的源不是指定目的地的当前第一跳网关 (参见第 3.3.1 节), 则重定向消息应该 (SHOULD) 被静默丢弃。

3.2.2.3 源抑制 (Source Quench): RFC-792​

如果主机正在接近或已经达到由于缺少重组缓冲区或其他资源而被迫丢弃传入数据报的点, 则主机可以 (MAY) 发送源抑制消息。有关何时发送源抑制的建议, 请参见 [INTRO:2] 的第 2.2.3 节。

如果接收到源抑制消息, IP 层必须 (MUST) 将其报告给传输层 (或 ICMP 处理)。一般来说, 传输或应用层应该 (SHOULD) 实现适当的拥塞控制机制来响应源抑制消息。

Last updated on