4. 互联网层协议
4.1 简介
本章和第 5 章讨论 Internet Layer 使用的协议: IP, ICMP 和 IGMP. 由于转发显然 是讨论路由器的文档中的关键主题, 第 5 章仅限于讨论这些协议中与转发直接相关 的方面. 本章则包含 Internet Layer 协议讨论的其余部分.
4.2 Internet 协议 - IP
4.2.1 简介
路由器必须实现 [INTERNET:1] 所定义的 IP 协议. 它们还必须实现其强制扩展: subnets (定义见 [INTERNET:2]), IP broadcast (定义见 [INTERNET:3]) 和 Classless Inter-Domain Routing (CIDR, 定义见 [INTERNET:15]).
路由器实现者无需考虑是否符合 [INTRO:2] 中题为 "Internet Protocol -- IP" 的 章节, 因为该章节已在本文档中被完全复制或取代. 路由器必须符合 [INTRO:2] 中 题为 "SPECIFIC ISSUES" 且与 IP 相关章节的要求, 并且应该无条件符合这些要求.
在下文中, 某些情况下规定的动作是静默丢弃接收到的数据报. 这意味着该数据报 将被丢弃而不再进一步处理, 并且路由器不会因此发送任何 ICMP 错误消息 (见 Section [4.3]). 但是, 为了诊断问题, 路由器应该提供记录该错误的能力 (见 Section [1.3.3]), 包括被静默丢弃数据报的内容, 并且应该统计被丢弃的数据报.
4.2.2 协议逐节说明
RFC 791 [INTERNET:1] 是 Internet Protocol 的规范.
4.2.2.1 选项: RFC 791 Section 3.2
在路由器自身接收的数据报中, IP 层必须解释它理解的 IP 选项, 并保持其余选项 不变, 供较高层协议使用.
较高层协议可能需要能够在其发送的数据报中设置 IP 选项, 或检查其接收的数据报 中的 IP 选项. 本文档后续章节讨论较高层协议所需的具体 IP 选项支持.
DISCUSSION 本备忘录和 [INTRO:2] 都没有定义接收方必须以何种顺序处理同一 IP 头部中的 多个选项. 发起包含多个选项的数据报的主机和路由器必须意识到, 当这些选项 与 source-route 选项组合时, 某些选项的含义会产生歧义.
以下是针对具体 IP 选项的要求:
(a) Security Option
某些环境要求每个发起或接收的数据包中都带有 Security option. 路由器
应该实现 [INTERNET:5] 中描述的修订后 security option.
DISCUSSION 请注意, [INTERNET:1] 和 RFC 1038 ([INTERNET:16]) 中描述的 security options 已经过时.
(b) Stream Identifier Option
此选项已过时; 路由器不应该在其发起的数据报中放置此选项. 在路由器接收
的数据报中, 必须忽略此选项.
(c) Source Route Options
路由器必须能够作为 source route 的最终目标. 如果路由器收到包含已完成
source route 的数据包, 则该数据包已经到达其最终目标. 在这样的选项中,
pointer 指向最后一个字段之后, 且 IP 头部中的目标地址寻址该路由器. 接收
到的该选项 (记录下来的路由) 必须上传给传输层 (或交给 ICMP 消息处理).
一般情况下, 对 source-routed 数据报的正确响应会经过同一路由. 路由器
必须提供一种手段, 使传输协议和应用能够反转接收数据报中的 source route.
当路由器不了解策略约束时, 这个反转后的 source route 必须插入它们所发起
的数据报中 (详见 [INTRO:2]). 但是, 如果路由器感知策略, 它可以选择另一
条路径.
路由器中的某些应用可以要求用户能够输入 source route.
路由器不得发起包含多个 source route 选项的数据报. 如果被要求转发包含
多个 source route 选项的数据包, 路由器应该如何处理, 见 Section [5.2.4.1].
创建 source route 选项时 (这会发生在路由器发起 source routed 数据报,
或因特殊过滤器插入 source route 选项时), 即使该选项是通过反转一个错误
地包含源主机的 recorded route 创建的, 也必须正确形成 (见下文讨论中的
情形 (B)).
DISCUSSION 假设 source routed 数据报要从源 _S 经由路由器 G1, G2, Gn 路由到目标 D. 源 S 构造一个以 G1 的 IP 地址作为目标地址的数据报, 并携带一个 source route 选项, 以便让该数据报走完到目标的其余路径. 然而, 规范中存在一个 歧义, 即 S 发送出的数据报中的 source route 选项应该是 (A) 还是 (B):
(A): {>>G2, G3, ... Gn, D} <--- 正确
(B): {S, >>G2, G3, ... Gn, D} <---- 错误
(其中 >> 表示 pointer). 如果发送 (A), D 处接收的数据报将包含选项: {G1, G2, ... Gn >>}, 且 S 和 D 分别作为 IP 源地址和目标地址. 如果发送 (B), D 处接收的数据报仍会包含相同的 IP 源地址和目标地址 S 与 D, 但选项 会是: {S, G1, ...Gn >>}; 即, 发起主机会成为路由中的第一跳.
(d) Record Route Option
路由器可以在其发起的数据报中支持 Record Route option.
(e) Timestamp Option
路由器可以在其发起的数据报中支持 timestamp option. 以下规则适用:
o 当发起包含 Timestamp Option 的数据报时, 如果满足以下条件之一, 路由器
必须在该选项中记录 timestamp:
- 其 Internet 地址字段未预先指定; 或
- 其第一个预先指定地址是发送该数据报的逻辑接口的 IP 地址 (如果数据报
通过未编号接口发送, 则为路由器的 router-id).
o 如果路由器自身接收到包含 Timestamp Option 的数据报, 路由器必须在将
该选项传给传输层或传给 ICMP 处理之前, 将当前时间插入 Timestamp
Option (如果该选项中有空间可这样做). 如果没有空间, 路由器必须递增
该选项中的 Overflow Count.
o timestamp 值必须遵循 [INTRO:2] 中定义的规则.
IMPLEMENTATION 为最大化 timestamp option 中所含 timestamp 的效用, 插入的 timestamp 应尽 实际可能接近数据包到达路由器的时间. 对于路由器发起的数据报, 插入的 timestamp 应尽实际可能接近数据报被传给 Link Layer 进行传输的时间.
timestamp option 允许使用非标准时钟, 但使用不同步时钟会限制 timestamp 的 效用. 因此, 强烈建议路由器实现 Network Time Protocol, 以同步其时钟.
4.2.2.2 选项中的地址: RFC 791 Section 3.1
路由器会被要求将其地址插入 Record Route, Strict Source and Record Route, Loose Source and Record Route 或 Timestamp Options. 当路由器将其地址插入 这类选项时, 必须使用正在发送该数据包的逻辑接口的 IP 地址. 如果由于输出接口 没有 IP 地址 (即它是未编号接口) 而无法遵守此规则, 路由器必须改为插入其 router-id. 路由器的 router-id 是该路由器的 IP 地址之一. Router ID 可以按 系统指定, 也可以按链路指定. 除非由网络管理员更改, 用作 router-id 的路由器 地址不得改变 (即使跨重启也不得改变). 相关管理变更包括重新配置路由器, 使得 用作 router-id 的 IP 地址不再是该路由器的 IP 地址之一. 具有多个未编号接口 的路由器可以有多个 router-id. 每个未编号接口必须与特定 router-id 关联. 没有 重新配置路由器时, 此关联不得改变 (即使跨重启也不得改变).
DISCUSSION 本规范不允许没有至少一个 IP 地址的路由器. 我们不认为这是严重限制, 因为 即使路由器只连接到点到点链路, 它也需要 IP 地址来满足 Chapter [8] 的可 管理性要求.
IMPLEMENTATION
满足此要求的一种可能 router-id 选择方法是, 使用分配给路由器的数值最小 (或最大) IP 地址 (将地址视为 32-bit 整数).
4.2.2.3 未使用的 IP 头部比特: RFC 791 Section 3.1
IP 头部包含两个保留 bit: 一个在 Type of Service 字节中, 另一个在 Flags 字段 中. 路由器不得在其发起的数据报中将其中任一 bit 置为一. 路由器不得仅因为 这些保留 bit 中的一个或多个具有非零值而丢弃 (拒绝接收或转发) 数据包; 即, 路由器不得检查这些 bit 的值.
DISCUSSION IP 协议的未来修订可能会使用这些未使用 bit. 这些规则旨在确保未来修订可以 部署, 而不必同时升级 Internet 中的所有路由器.
4.2.2.4 服务类型: RFC 791 Section 3.1
IP 头部中的 Type-of-Service 字节分为三部分: Precedence 字段 (高 3 bit), 一个通常称为 Type of Service 或 TOS 的字段 (接下来的 4 bit), 以及一个保留 bit (低位 bit).
管理保留 bit 的规则已在 Section [4.2.2.3] 中描述.
关于 TOS 字段及其使用的更广泛讨论可见 [ROUTE:11].
IP Precedence 字段的描述由 Section [5.3.3] 取代. RFC 795, Service Mappings, 已过时, 不应该实现.
4.2.2.5 头部校验和: RFC 791 Section 3.1
如 Section [5.2.2] 所述, 路由器必须验证任何接收数据包的 IP checksum, 并且 必须丢弃包含无效 checksum 的消息. 路由器不得提供禁用此 checksum 验证的手段.
当 IP 头部唯一变化是 time to live 时, 路由器可以使用增量 IP 头部 checksum 更新. 这会降低路由器未检测到 IP 头部损坏的可能性. 关于 checksum 增量更新的 讨论见 [INTERNET:6].
IMPLEMENTATION 关于 IP checksum 的更广泛描述, 包括大量实现提示, 可见 [INTERNET:6] 和 [INTERNET:7].
4.2.2.6 无法识别的头部选项: RFC 791 Section 3.1
路由器必须忽略其无法识别的 IP 选项. 该要求的一个推论是, 路由器必须实现 End of Option List option 和 No Operation option, 因为二者都不包含显式长度.
DISCUSSION 所有未来 IP 选项都将包含显式长度.
4.2.2.7 分片: RFC 791 Section 3.2
路由器必须支持 [INTERNET:1] 中描述的分片.
当路由器对 IP 数据报进行分片时, 它应该最小化分片数量. 当路由器对 IP 数据报 进行分片时, 它应该按顺序发送这些分片. 如果某种分片方法可能生成一个显著小于 其他分片的 IP 分片, 则可以让第一个 IP 分片成为较小的那个.
DISCUSSION Internet 中常用若干分片技术. 其中一种技术是将 IP 数据报拆分为 IP 分片, 第一个分片大小等于 MTU, 其他分片大小大致相同且小于 MTU. 这样做有两个 原因. 序列中的第一个 IP 分片将成为主机之间当前路径的有效 MTU, 后续 IP 分片的大小则用于最小化该 IP 数据报的进一步分片. 另一种技术是按照 [INTERNET:1] 中的描述, 将 IP 数据报拆分为 MTU 大小的 IP 分片, 只有最后 一个分片较小.
某些 TCP/IP 实现常用的一个技巧是, 当 IP 数据报要经过路由器时, 将其分片 为不大于 576 字节的 IP 分片. 其意图是让生成的 IP 分片在路径其余部分无需 进一步分片即可通过. 不过, 这会给目标主机带来更多负载, 因为它需要将更多 IP 分片重组为一个 IP 数据报. 在 MTU 只变化一次且仍远大于 576 字节的网络 上, 这也并不高效. 示例包括 IEEE 802.5 网络 (MTU 为 2048) 或 Ethernet 网络 (MTU 为 1500) 这样的 LAN 网络.
讨论过的另一种分片技术是将 IP 数据报拆分为大小大致相等的 IP 分片, 其 大小小于或等于下一跳网络的 MTU. 其意图是最小化路径后续进一步分片所产生 的分片数量, 并确保每个分片具有相等延迟.
路由器应该生成尽可能少的 IP 分片.
使用慢速机器的经验使我们相信, 如果必须对消息进行分片, 先发送较小的 IP 分片会最大化具有慢速接口的主机接收所有分片的机会.
4.2.2.8 重组: RFC 791 Section 3.2
如 [INTRO:2] 对应章节所规定, 路由器必须支持对交付给自身的数据报进行重组.
4.2.2.9 生存时间: RFC 791 Section 3.2
路由器发起或接收的数据包的 Time to Live (TTL) 处理受 [INTRO:2] 管理; 本节 不改变其中任何规定. 但是, 由于 [INTRO:2] 中 IP Protocol 章节的其余部分已被 重写, 本节也一并重写.
特别注意, 路由器不得检查数据包的 TTL, 除非正在转发该数据包.
路由器不得发起或转发 Time-to-Live (TTL) 值为零的数据报.
路由器不得仅因为接收时 TTL 等于零或一就丢弃数据报; 如果该数据报发往该路由器 且在其他方面有效, 路由器必须尝试接收它.
对于路由器发起的消息, IP 层必须为传输层提供一种手段, 使其能够设置所发送 每个数据报的 TTL 字段. 使用固定 TTL 值时, 该值必须可配置. 该数值应该超过 典型互联网直径, 当前经验还建议它应超过互联网直径的两倍以允许增长. 当前建议 值通常发布在 Assigned Numbers RFC 中. TTL 字段有两个功能: 限制 TCP segment 的生存期 (见 RFC 793 [TCP:1], p. 28), 以及终止 Internet 路由环路. 尽管 TTL 是以秒为单位的时间, 它也具有 hop-count 的某些属性, 因为每台路由器都要求将 TTL 字段至少减一.
TTL 到期旨在使数据报被路由器丢弃, 而不是被目标主机丢弃. 因此, 通过转发 数据报而充当路由器的主机必须遵循路由器的 TTL 规则.
较高层协议可能希望设置 TTL, 以实现针对某些 Internet 资源的 "expanding scope" 搜索. 某些诊断工具使用这种方式, 并且预期它对于使用 IP 组播定位给定类别的 "nearest" 服务器等场景很有用. 特定传输协议也可能希望指定自己的最大数据报 生存期 TTL 边界.
固定默认值必须至少足够覆盖 Internet "diameter", 即最长可能路径. 一个合理 值约为该直径的两倍, 以允许 Internet 继续增长. 在撰写本文时, 横跨美国的消息 经常穿越 15 到 20 台路由器; 这支持使用超过 40 的默认 TTL 值, 而 64 是常见值.
4.2.2.10 多子网广播: RFC 922
All-subnets broadcasts ([INTERNET:3] 中称为 multi-subnet broadcasts) 已被废弃. 见 Section [5.3.5.3].
4.2.2.11 寻址: RFC 791 Section 3.2
如 2.2.5.1 所述, 现在有五类 IP 地址: Class A 到 Class E. Class D 地址用于 IP 组播 [INTERNET:4], 而 Class E 地址保留用于实验用途. Class A, B 和 C 地址 之间的区别不再重要; 它们作为通用单播网络前缀使用, 其类别只具有历史意义.
IP 组播地址是一个 28-bit 逻辑地址, 代表一组主机, 可以是永久的, 也可以是 临时的. 永久组播地址由 Internet Assigned Number Authority [INTRO:7] 分配, 而临时地址可以动态分配给临时组. 组成员关系使用 IGMP [INTERNET:4] 动态确定.
下面使用以下 IP 地址表示法总结通用单播 IP 地址的重要特殊情形:
{
并使用 -1 表示包含全 1 bit 的字段, 使用 0 表示包含全 0 bit 的字段.
(a) { 0, 0 }
本网络上的本主机. 路由器不得将其用作源地址, 但作为初始化过程的一部分
(例如, 如果路由器使用 BOOTP 加载其配置信息), 路由器可以将其用作源地址.
如果接收到源地址为 { 0, 0 } 且用于本地交付的数据报 (见 Section [5.2.3]),
并且路由器实现了相关协议且该协议明确定义了应采取的适当动作, 则必须
接受该数据报. 否则, 路由器必须静默丢弃任何源地址为 { 0, 0 } 的本地交付
数据报.
DISCUSSION 某些协议定义了响应源地址为 { 0, 0 } 的接收数据报时应采取的具体动作. 两个示例是 BOOTP 和 ICMP Mask Request. 这些协议的正确运行通常依赖于接收 源地址为 { 0, 0 } 的数据报的能力. 但是, 对多数协议而言, 最好忽略源地址 为 { 0, 0 } 的数据报, 因为它们很可能由配置错误的主机或路由器生成. 因此, 如果路由器知道如何处理具有 { 0, 0 } 源地址的给定数据报, 它必须接受该 数据报. 否则, 路由器必须丢弃它.
另请参见 Section [4.2.3.1], 其中描述了 { 0, 0 } 的非标准用法.
(b) { 0,
本网络上的指定主机. 路由器不得发送该地址, 但作为路由器学习自身 IP 地址
的初始化过程的一部分, 路由器可以将其用作源地址.
(c) { -1, -1 }
有限广播. 不得将其用作源地址.
具有此目标地址的数据报将被连接物理网络上的每台主机和路由器接收, 但不会
转发到该网络之外.
(d) {
Directed Broadcast - 定向到指定网络前缀的广播. 不得将其用作源地址.
路由器可以发起 Network Directed Broadcast 数据包. 路由器必须接收 Network
Directed Broadcast 数据包; 但是, 路由器可以具有一个配置选项来阻止接收
这些数据包. 该选项必须默认为允许接收.
(e) { 127,
内部主机 loopback 地址. 这种形式的地址不得出现在主机之外.
除上述特殊情形外, IP 地址的
DISCUSSION 本文档先前版本还指出, 子网号既不得为 0 也不得为 -1, 且长度必须至少为 two bits. 在 CIDR 世界中, 子网号显然是网络前缀的扩展, 并且不能脱离前缀 的其余部分来解释. 因此, 从 CIDR 角度看, 这种对子网号的限制没有意义, 可以安全忽略.
关于广播地址的进一步讨论见 Section [4.2.3.1].
当路由器发起任何数据报时, IP 源地址必须是它自己的 IP 地址之一 (但不能是广播 或组播地址). 唯一例外是在初始化期间.
对于多数目的而言, 寻址到广播或组播目标的数据报会被处理为如同它寻址到路由器 的某个 IP 地址; 也就是说:
o 路由器必须接收并正常处理任何具有广播目标地址的数据包.
o 路由器必须接收并正常处理任何发送到该路由器已请求接收的组播目标地址的数据包.
术语 specific-destination address 表示主机的等效本地 IP 地址. 如果 IP 头部 不包含广播或组播地址, specific-destination address 定义为 IP 头部中的目标 地址; 如果头部包含广播或组播地址, 则 specific-destination 是分配给该数据报 到达的物理接口的 IP 地址.
路由器必须静默丢弃任何包含按本节规则无效的 IP 源地址的接收数据报. 此验证 可以由 IP 层执行, 或在适当时由传输层中的每个协议执行. 与路由器丢弃的任何 数据报一样, 应该统计该数据报丢弃.
DISCUSSION 地址错误的数据报可能由单播数据报的 Link Layer 广播造成, 也可能由另一个 混乱或配置错误的路由器或主机造成.
4.2.3 具体问题
4.2.3.1 IP 广播地址
出于历史原因, 有若干 IP 地址 (一些是标准的, 一些不是) 用于表示某个 IP 数据包 是 IP 广播. 路由器
(1) 必须将寻址到 255.255.255.255 或 {
(2) 在接收时应该静默丢弃 (即甚至不交付给路由器中的应用) 任何寻址到 0.0.0.0
或 {
(3) 当发起目的地为已连接 (子)网的 IP 广播时, 默认应该使用 limited broadcast address (255.255.255.255), 但发送 ICMP Address Mask Reply 时除外, 见 Section [4.3.3.9]. 路由器必须接收 limited broadcasts.
(4) 不应该发起寻址到 0.0.0.0 或 {
DISCUSSION
在第二个项目中, 如果路由器没有到该网络前缀的接口, 它显然无法识别
{
4.2.3.2 IP 组播
IP 路由器应该满足 [INTRO:2] 中规定的关于 IP 组播的 Host Requirements. IP 路由器应该在所有连接网络上支持本地 IP 组播. 当已指定从 IP 组播地址到链路层 地址的映射时 (见各种 IP-over-xxx 规范), 它应该使用该映射, 并可以配置为改用 链路层广播. 在点到点链路和所有其他接口上, 组播被封装为链路层广播. 对本地 IP 组播的支持包括发起组播数据报, 加入组播组并接收组播数据报, 以及离开组播 组. 这意味着支持 [INTERNET:4] 的全部内容, 包括 IGMP (见 Section [4.4]).
DISCUSSION 虽然 [INTERNET:4] 的标题是 Host Extensions for IP Multicasting, 但它适用 于所有 IP 系统, 包括主机和路由器. 特别是, 由于路由器可以加入组播组, 它们执行 IGMP 的主机部分是正确的, 即向其所连接网络上可能存在的任何组播 路由器报告其组成员关系 (无论它们自身是否为组播路由器).
某些路由器协议可能明确要求支持 IP 组播 (例如 OSPF [ROUTE:1]), 或推荐 支持 IP 组播 (例如 ICMP Router Discovery [INTERNET:13]).
4.2.3.3 Path MTU Discovery
为了消除分片或最小化分片, 最好知道从源到目标路径上的 path MTU 是什么. path MTU 是路径中每一跳 MTU 的最小值. [INTERNET:14] 描述了一种动态发现任意互联网 路径 maximum transmission unit (MTU) 的技术. 对于经过不支持 [INTERNET:14] 的路由器的路径, 该技术可能无法发现正确的 Path MTU, 但它始终会选择一个与 旧技术或当前实践所选择 Path MTU 一样准确, 并且在许多情况下更准确的 Path MTU.
当路由器发起 IP 数据报时, 它应该使用 [INTERNET:14] 中描述的方案来限制数据报 大小. 如果路由器到数据报目标的路由是从提供 Path MTU 信息的路由协议中学习的, 仍使用 [INTERNET:14] 中描述的方案, 但应该将来自路由协议的 Path MTU 信息用作 Path MTU 的初始猜测值, 并同时作为 Path MTU 的上限.
4.2.3.4 子网划分
在某些情况下, 可能希望支持某一特定网络的若干子网仅通过一条不属于该已划分 子网网络的路径互连. 这称为不连续子网支持.
路由器必须支持不连续子网.
IMPLEMENTATION 在传统 IP 网络中, 这非常难以实现; 在 CIDR 网络中, 它是自然副产物. 因此, 路由器不应该对 subnet architecture 作假设, 而应该将每条路由视为通用网络 前缀.
DISCUSSION Internet 近来一直以极快速度增长. 这给 IP 寻址技术带来了严重压力. 造成 这种压力的一个主要因素是严格的 IP Address 类边界. 这些边界使得难以根据 网络规模高效确定网络前缀大小, 并难以将多个网络前缀聚合到单一路由通告中. 通过消除 IP 地址的严格类别边界, 并将每条路由视为通用网络前缀, 可以大幅 减轻这些压力.
当前实现这一点的技术是 Classless Inter Domain Routing (CIDR) [INTERNET:15].
出于类似原因, 与给定网络前缀关联的地址块可以细分为不同大小的子块, 使与这些 子块关联的网络前缀具有不同长度. 例如, 在一个网络前缀长度为 8 bit 的块内, 一个子块可以具有 16 bit 网络前缀, 另一个可以具有 18 bit 网络前缀, 第三个 可以具有 14 bit 网络前缀.
路由器必须在其接口配置和路由数据库中都支持可变长度网络前缀.
4.3 Internet 控制消息协议 - ICMP
4.3.1 简介
ICMP 是一个辅助协议, 为 IP 提供路由, 诊断和错误功能. 它在 [INTERNET:8] 中 描述. 路由器必须支持 ICMP.
ICMP 消息分为两类, 以下章节将讨论这些类别:
ICMP error messages:
Destination Unreachable Section 4.3.3.1 Redirect Section 4.3.3.2 Source Quench Section 4.3.3.3 Time Exceeded Section 4.3.3.4 Parameter Problem Section 4.3.3.5
ICMP query messages: Echo Section 4.3.3.6 Information Section 4.3.3.7 Timestamp Section 4.3.3.8 Address Mask Section 4.3.3.9 Router Discovery Section 4.3.3.10
一般 ICMP 要求和讨论见下一节.
4.3.2 一般问题
4.3.2.1 未知消息类型
如果收到未知类型的 ICMP 消息, 必须将其传递给 ICMP user interface (如果路由器 具有这样的接口), 或静默丢弃 (如果路由器没有这样的接口).
4.3.2.2 ICMP 消息 TTL
发起 ICMP 消息时, 路由器必须初始化 TTL. ICMP 响应的 TTL 不得取自触发该响应 的数据包.
4.3.2.3 原始消息头部
历史上, 每个 ICMP 错误消息都包含触发错误的数据报的 Internet 头部和至少前 8 个数据字节. 由于使用 IP-in-IP tunneling 和其他技术, 这已不再足够. 因此, ICMP 数据报应该在不使 ICMP 数据报长度超过 576 字节的前提下, 包含尽可能多的 原始数据报内容. 返回的 IP 头部 (和用户数据) 必须与接收到的内容相同, 但路由器 无需撤销在检测到错误之前已执行的、转发时通常对 IP 头部执行的任何修改 (例如, 递减 TTL 或更新选项). 请注意, Section [4.3.3.5] 的要求在某些情况下取代此 要求 (即, 对 Parameter Problem 消息而言, 如果问题位于已修改字段中, 路由器 必须撤销该修改). 见 Section [4.3.3.5]).
4.3.2.4 ICMP 消息源地址
除非本文档另有规定, 路由器发起的 ICMP 消息中的 IP 源地址必须是与发送该 ICMP 消息的物理接口关联的 IP 地址之一. 如果该接口没有与之关联的 IP 地址, 则改用 路由器的 router-id (见 Section [5.2.5]).
4.3.2.5 TOS 和 Precedence
ICMP 错误消息的 TOS bit 应该设置为与触发发送该 ICMP 错误消息的数据包中的 TOS bit 相同的值, 除非设置为该值会导致 ICMP 错误消息因为无法路由到其目标而 立即被丢弃. 否则, ICMP 错误消息必须使用普通 (即零) TOS 发送. ICMP reply message 的 TOS bit 应该设置为与触发该回复的 ICMP request 中的 TOS bit 相同 的值.
如果发送 ICMP Source Quench 错误消息, 其 IP Precedence 字段必须设置为与触发 发送该 ICMP Source Quench 消息的数据包中的 IP Precedence 字段相同的值. 所有 其他 ICMP 错误消息 (Destination Unreachable, Redirect, Time Exceeded 和 Parameter Problem) 的 precedence 值应该设置为 6 (INTERNETWORK CONTROL) 或 7 (NETWORK CONTROL). 这些错误消息的 IP Precedence 值可以是可设置的.
ICMP reply message 的 IP Precedence 字段必须设置为与触发该回复的 ICMP request 中的 IP Precedence 字段相同的值.
4.3.2.6 Source Route
如果触发发送 ICMP 错误消息的数据包包含 source route option, ICMP 错误消息也 应该包含同一类型 (strict 或 loose) 的 source route option, 该选项通过反转原始 数据包 source route option 中记录路由在 pointer 之前的部分创建, 除非 ICMP 错误消息是抱怨原始数据包中 source route option 的 ICMP Parameter Problem, 或者除非路由器知道存在会阻止交付该 ICMP 错误消息的策略.
DISCUSSION 在使用 U.S. Department of Defense security option (定义见 [INTERNET:5]) 的环境中, ICMP 消息可能需要包含 security option. 有关此主题的详细信息 应可从 Defense Communications Agency 获得.
4.3.2.7 何时不发送 ICMP 错误
接收到以下内容时, 不得发送 ICMP 错误消息:
o ICMP 错误消息, 或
o 未通过 Section [5.2.2] 中描述的 IP 头部验证测试的数据包 (除非该章节明确 允许发送 ICMP 错误消息), 或
o 目标为 IP broadcast 或 IP multicast 地址的数据包, 或
o 作为 Link Layer broadcast 或 multicast 发送的数据包, 或
o 源地址的网络前缀为零或源地址无效的数据包 (如 Section [5.3.7] 中定义), 或
o 某个数据报中除第一个分片以外的任何分片 (即 IP 头部中的 fragment offset 非零的数据包).
此外, 在本备忘录声明应静默丢弃某个数据包的任何情况下, 都不得发送 ICMP 错误 消息.
NOTE: 这些限制优先于本文档其他位置关于发送 ICMP 错误消息的任何要求.
DISCUSSION 这些规则旨在防止路由器或主机响应广播数据包返回 ICMP 错误消息所导致的 broadcast storm. 例如, 发往不存在端口的广播 UDP 数据包可能触发所有没有 该目标端口客户端的设备泛洪 ICMP Destination Unreachable 数据报. 在大型 Ethernet 上, 由此产生的冲突可能使网络在一秒或更长时间内不可用.
在连接网络上广播的每个数据包都应该具有有效的 IP broadcast 地址作为其 IP 目标地址 (见 Section [5.3.4] 和 [INTRO:2]). 然而, 某些设备违反此规则. 因此, 为了确定检测广播数据包, 路由器除了检查 IP-layer 地址外, 还要求检查 link-layer broadcast.
IMPLEMENTATION 这要求 link layer 在收到 link-layer broadcast 数据包时通知 IP layer; 见 Section [3.1].
4.3.2.8 速率限制
发送 ICMP Source Quench 消息的路由器必须能够限制这些消息的生成速率. 路由器 还应该能够限制其发送其他类型 ICMP 错误消息 (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem) 的速率. 速率限制参数应该可作为路由器配置的 一部分设置. 如何应用这些限制 (例如按路由器或按接口) 留给实现者自行决定.
DISCUSSION 发送 ICMP 错误消息的路由器面临两个问题: (1) 反向路径上的带宽消耗, 以及 (2) 路由器资源使用 (例如内存, CPU 时间)
为帮助解决这些问题, 路由器可以限制其生成 ICMP 错误消息的频率. 出于类似 原因, 路由器可以限制生成某些其他类型消息的频率, 例如 ICMP Echo Replies.
IMPLEMENTATION 已使用或提出了多种机制来限制 ICMP 消息发送速率:
(1) 基于计数 - 例如, 每丢弃 N 个数据包整体发送一个 ICMP 错误消息, 或针对 给定源主机发送一个 ICMP 错误消息. 如果使用 ICMP Source Quench, 此机制 可能适用于它, 但可能不适用于其他类型的 ICMP 消息.
(2) 基于定时器 - 例如, 对给定源主机或整体最多每 T milliseconds 发送一次 ICMP 错误消息.
(3) 基于带宽 - 例如, 将通过特定接口发送 ICMP 消息的速率限制为所连接网络 带宽的某一部分.
4.3.3 具体问题
4.3.3.1 Destination Unreachable
如果路由器因完全没有到数据包指定目标的路由 (包括没有默认路由) 而无法转发 数据包, 则路由器必须生成 Destination Unreachable, Code 0 (Network Unreachable) ICMP 消息. 如果路由器确实有到数据包指定目标网络的路由, 但这些路由指定的 TOS 既不是默认 TOS (0000), 也不是路由器正尝试路由的数据包的 TOS, 则路由器 必须生成 Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP 消息.
如果数据包将被转发到直接连接到该路由器的网络上的主机 (即该路由器是最后一跳 路由器), 且路由器已确定不存在到目标主机的路径, 则路由器必须生成 Destination Unreachable, Code 1 (Host Unreachable) ICMP 消息. 如果数据包将被转发到直接 连接到该路由器的网络上的主机, 且路由器无法转发该数据包, 因为没有到目标的 路由具有等于数据包请求 TOS 或默认 TOS (0000) 的 TOS, 则路由器必须生成 Destination Unreachable, Code 12 (Host Unreachable for TOS) ICMP 消息.
DISCUSSION 其意图是, 如果路由器完全没有到目标的路径 (包括默认路由), 则生成 "generic" host/network unreachable. 如果路由器有一条或多条到目标的路径, 但这些路径 都没有可接受的 TOS, 则路由器生成 "unreachable for TOS" 消息.
4.3.3.2 Redirect
生成 ICMP Redirect 消息是为了通知本地主机, 对某些流量它应该使用不同的下一跳 路由器.
与 [INTRO:2] 不同, 如果路由器正在运行路由协议, 或者如果该路由器和发送数据包 的接口已启用转发, 则在为路由器发起的数据包选择路径时, 路由器可以忽略 ICMP Redirect.
4.3.3.3 Source Quench
路由器不应该发起 ICMP Source Quench 消息. 如 Section [4.3.2] 所规定, 发起 Source Quench 消息的路由器必须能够限制其生成速率.
DISCUSSION 研究似乎表明, Source Quench 消耗网络带宽, 但对于拥塞而言是一种无效 (且 不公平) 的对策. 例如见 [INTERNET:9] 和 [INTERNET:10]. Section [5.3.6] 讨论当前关于路由器应如何处理过载和网络拥塞的思路.
路由器可以忽略其接收到的任何 ICMP Source Quench 消息.
DISCUSSION 路由器自身可能因发起发送给另一个路由器或主机的数据包而收到 Source Quench. 这类数据报可能是例如发送给另一个路由器的 EGP update, 或发送给主机的 telnet stream. 已提出一种机制 ([INTERNET:11], [INTERNET:12]) 使 IP layer 通过控制数据包发送速率直接响应 Source Quench; 但是, 该提案目前是实验性 的, 当前不推荐使用.
4.3.3.4 Time Exceeded
当路由器正在转发数据包且该数据包的 TTL 字段被减为 0 时, 适用 Section [5.2.3.8] 的要求.
当路由器重组一个目标为该路由器的数据包时, 它正作为 Internet 主机运行. 因此, 适用 [INTRO:2] 的重组要求.
当路由器接收 (即目标为该路由器) Time Exceeded 消息时, 它必须符合 [INTRO:2].
4.3.3.5 Parameter Problem
对于任何未由其他 ICMP 消息专门覆盖的错误, 路由器必须生成 Parameter Problem 消息. 包含 pointer 字段所指示字节的 IP 头部字段或 IP 选项, 必须在随此 ICMP 消息返回的 IP 头部中保持不变. Section [4.3.2] 定义了此要求的例外.
[INTRO:2] 中定义了 Parameter Problem 消息的新变体: Code 1 = required option is missing.
DISCUSSION 此变体目前在军事社区中用于缺失 security option 的情形.
4.3.3.6 Echo Request/Reply
路由器必须实现 ICMP Echo server 功能, 该功能接收发送给路由器的 Echo Requests, 并发送相应的 Echo Replies. 路由器必须准备好接收, 重组并回显 ICMP Echo Request 数据报, 其大小至少为 576 与所有连接网络 MTU 中的最大值.
Echo server 功能可以选择不响应寻址到 IP broadcast 或 IP multicast 地址的 ICMP echo request.
路由器应该具有一个配置选项, 如果启用该选项, 则路由器静默忽略所有 ICMP echo request; 如果提供该选项, 它必须默认为允许响应.
DISCUSSION 关于响应 broadcast 和 multicast Echo Requests 的中立规定源自 [INTRO:2] 的 "Echo Request/Reply" 章节.
如 Section [10.3.3] 所述, 路由器还必须实现一个 user/application-layer 接口, 用于诊断目的发送 Echo Request 并接收 Echo Reply. 所有 ICMP Echo Reply 消息 都必须传递给该接口.
ICMP Echo Reply 中的 IP 源地址必须与对应 ICMP Echo Request 消息的 specific-destination address 相同.
在 ICMP Echo Request 中接收的数据必须完整包含在生成的 Echo Reply 中.
如果 ICMP Echo Request 中接收到 Record Route 和/或 Timestamp option, 应该 更新该选项 (这些选项), 以包含当前路由器, 并将其无截断地包含在 Echo Reply 消息的 IP 头部中. 因此, 记录的路由将覆盖整个往返路径.
如果 ICMP Echo Request 中接收到 Source Route option, 必须反转返回路由, 并将 其用作 Echo Reply 消息的 Source Route option, 除非路由器知道存在会阻止交付 该消息的策略.
4.3.3.7 Information Request/Reply
路由器不应该发起或响应这些消息.
DISCUSSION Information Request/Reply 对最初旨在支持无盘工作站等自配置系统, 使它们能 在启动时发现自己的 IP 网络前缀. 但是, 这些消息现在已经过时. RARP 和 BOOTP 协议为主机发现自己的 IP 地址提供了更好的机制.
4.3.3.8 Timestamp and Timestamp Reply
路由器可以实现 Timestamp 和 Timestamp Reply. 如果实现它们, 则:
o ICMP Timestamp server 功能必须对收到的每个 Timestamp message 返回 Timestamp Reply. 它应该被设计为最小化延迟变化.
o 发往 IP broadcast 或 IP multicast 地址的 ICMP Timestamp Request message 可以被静默丢弃.
o ICMP Timestamp Reply 中的 IP 源地址必须与对应 Timestamp Request message 的 specific-destination address 相同.
o 如果 Timestamp Request 中接收到 Source Route option, 必须反转返回路由, 并 将其用作 Timestamp Reply message 的 Source Route option, 除非路由器知道 存在会阻止交付该消息的策略.
o 如果 Timestamp Request 中接收到 Record Route 和/或 Timestamp option, 应该 更新该选项 (这些选项), 以包含当前路由器, 并将其包含在 Timestamp Reply message 的 IP 头部中.
o 如果路由器提供用于发送 Timestamp Request messages 的 application-layer interface, 则传入的 Timestamp Reply messages 必须上传到 ICMP user interface.
timestamp 值的首选形式 (标准值) 是自午夜以来的毫秒数, 采用 Universal Time. 但是, 以毫秒分辨率提供该值可能很困难. 例如, 许多系统使用的时钟只按电源线 频率更新, 每秒 50 或 60 次. 因此, 对标准值允许一定宽容:
(a) 标准值必须至少每秒更新 16 次 (即最多该值的低 6 bit 可以未定义).
(b) 标准值的准确性必须接近由操作员设置的 CPU 时钟, 即在几分钟内正确.
IMPLEMENTATION 为满足第二个条件, 路由器可能需要在启动或重启时查询某个 time server. 推荐为此使用 UDP Time Server Protocol. 更高级的实现会使用 Network Time Protocol (NTP) 来实现接近毫秒级的时钟同步; 但是, 这不是必需的.
4.3.3.9 Address Mask Request/Reply
路由器必须实现对接收 ICMP Address Mask Request 消息并以 ICMP Address Mask Reply 消息响应的支持. 这些消息定义见 [INTERNET:2].
路由器应该为每个逻辑接口提供一个配置选项, 指定路由器是否允许响应该接口的 Address Mask Requests; 此选项必须默认为允许响应. 路由器在知道正确地址掩码 之前, 不得响应 Address Mask Request.
如果 Address Mask Request 的源地址为 0.0.0.0, 且它到达的物理接口关联多个 逻辑接口, 并且这些接口的地址掩码并不全都相同, 则路由器不得响应该 Address Mask Request.
路由器应该检查其收到的所有 ICMP Address Mask Replies, 以确定其中包含的信息 是否与路由器对地址掩码的认知匹配. 如果 ICMP Address Mask Reply 似乎有误, 路由器应该记录该地址掩码和发送方 IP 地址. 路由器不得使用 ICMP Address Mask Reply 的内容来确定正确地址掩码.
由于如果主机启动时路由器关闭, 主机可能无法学习地址掩码, 路由器可以在配置 自己的地址掩码之后, 在每个逻辑接口上广播一个 gratuitous ICMP Address Mask Reply. 但是, 在使用可变长度地址掩码的环境中, 这一特性可能有危险. 因此, 如果实现该特性, gratuitous Address Mask Replies 不得在满足以下任一条件的 逻辑接口上广播:
o 未配置为发送 gratuitous Address Mask Replies. 每个逻辑接口必须有一个配置 参数控制这一点, 且该参数必须默认为不发送 gratuitous Address Mask Replies.
o 共享包含性 (但不相同的) 网络前缀和物理接口.
广播 Address Mask Replies 必须使用 IP broadcast 地址的 {
DISCUSSION 少数站点有意向其主机谎报地址掩码, 因而要求路由器能够禁用发送 Address Mask Replies. 随着越来越多主机符合 Host Requirements 标准, 预计这种需求 会消失.
上述第二个项目以及关于使用哪个 IP broadcast 地址的要求, 都是为了在同一 物理网络上使用多个 IP 网络前缀时防止问题.
4.3.3.10 Router Advertisement and Solicitations
IP 路由器必须在所有连接网络上支持 ICMP Router Discovery Protocol [INTERNET:13] 的路由器部分, 前提是在这些网络上该路由器支持 IP multicast 或 IP broadcast 寻址. 该实现必须包含为路由器指定的所有配置变量及其指定默认值.
DISCUSSION 路由器不要求实现 ICMP Router Discovery Protocol 的主机部分, 但在 IP 转发 被禁用时 (即作为主机运行时), 它们可能会发现该部分对运行有用.
DISCUSSION 我们注意到, 主机使用 RIP Version 1 作为路由器发现协议非常常见. 这类主机 监听 RIP 流量, 并使用从该流量中提取的信息来发现路由器, 以及决定针对给定 目标应使用哪台路由器作为第一跳路由器. 虽然不鼓励这种行为, 但它仍很常见, 实现者应该了解这一点.
4.4 Internet 组管理协议 - IGMP
IGMP [INTERNET:4] 是主机和单个物理网络上的组播路由器之间使用的协议, 用于 建立主机在特定组播组中的成员关系. 组播路由器将这些信息与组播路由协议结合 使用, 以支持跨 Internet 的 IP 组播转发.
路由器应该实现 IGMP 的主机部分.