RFC 1812 - IPv4 路由器需求

• 状态: 未知
• 发布时间: 未知
• 文档流: 未知
• 勘误: 无勘误

---

目录

• 2. 互联网架构
• 3. 链路层
• 4. 互联网层协议

阅读说明

本页提供 RFC 的中文概览和章节入口. 详细协议内容请继续阅读左侧对应章节.

正文译文

本备忘录状态

本文档为 Internet 社区规定了一项 Internet 标准跟踪协议, 并请求对其 改进提出讨论和建议. 关于本协议的标准化阶段和状态, 请参见当前版本的 "Internet Official Protocol Standards" (STD 1). 本备忘录的分发不受限制.

前言

本文档是 RFC 1716 的更新版本, RFC 1716 是历史性的 Router Requirements 文档. 该 RFC 保留了工作组投入其中的重要工作, 但未能充分描述当前技术, 以使 IESG 将其视为当前标准.

当前编辑被要求更新本文档, 使其可作为采购规范和实现者指南使用. 在这项 工作中, 他完全建立在前人工作的基础之上, 并在很大程度上依赖专家贡献者 提供文本. 任何功劳都属于他们; 错误则归于他.

本文档的内容和形式在很大程度上归功于工作组主席, 也是本文档最初的编辑 和作者 Philip Almquist. 同样, 这也在很大程度上归功于前任编辑 Frank Kastenholz 的努力. 没有他们的努力, 本文档就不会存在.

目录

1. 简介 ........................................ 6 1.1 阅读本文档 .................................. 8 1.1.1 组织结构 .................................. 8 1.1.2 要求 ...................................... 9 1.1.3 符合性 .................................... 10 1.2 与其他标准的关系 ............................ 11 1.3 一般考虑事项 ................................ 12 1.3.1 Internet 的持续演进 ........................ 12 1.3.2 健壮性原则 ................................ 13 1.3.3 错误日志 .................................. 14

1.3.4 配置 ...................................... 14 1.4 算法 ........................................ 16 2. Internet 架构 ................................ 16 2.1 简介 ........................................ 16 2.2 架构元素 .................................... 17 2.2.1 协议分层 .................................. 17 2.2.2 网络 ...................................... 19 2.2.3 路由器 .................................... 20 2.2.4 自治系统 .................................. 21 2.2.5 寻址架构 .................................. 21 2.2.5.1 传统 IP 寻址架构 ......................... 21 2.2.5.2 无类域间路由 (CIDR) ...................... 23 2.2.6 IP 组播 ................................... 24 2.2.7 未编号线路和网络前缀 ...................... 25 2.2.8 值得注意的特殊情况 ........................ 26 2.2.8.1 嵌入式路由器 ............................ 26 2.2.8.2 透明路由器 .............................. 27 2.3 路由器特征 .................................. 28 2.4 架构假设 .................................... 31 3. 链路层 ...................................... 32 3.1 简介 ........................................ 32 3.2 链路/Internet 层接口 ......................... 33 3.3 具体问题 .................................... 34 3.3.1 Trailer 封装 ............................... 34 3.3.2 地址解析协议 - ARP ......................... 34 3.3.3 Ethernet 和 802.3 共存 ...................... 35 3.3.4 最大传输单元 - MTU ......................... 35 3.3.5 点到点协议 - PPP ........................... 35 3.3.5.1 简介 ..................................... 36 3.3.5.2 链路控制协议 (LCP) 选项 .................. 36 3.3.5.3 IP 控制协议 (IPCP) 选项 .................. 38 3.3.6 接口测试 .................................. 38 4. Internet 层 - 协议 ............................ 39 4.1 简介 ........................................ 39 4.2 Internet 协议 - IP ........................... 39 4.2.1 简介 ...................................... 39 4.2.2 协议逐节说明 .............................. 40 4.2.2.1 选项: RFC 791 Section 3.2 ................ 40 4.2.2.2 选项中的地址: RFC 791 Section 3.1 ........ 42 4.2.2.3 未使用的 IP 头部比特: RFC 791 Section 3.1 43 4.2.2.4 服务类型: RFC 791 Section 3.1 ............ 44 4.2.2.5 头部校验和: RFC 791 Section 3.1 .......... 44 4.2.2.6 无法识别的头部选项: RFC 791, Section 3.1 .............................. 44 4.2.2.7 分片: RFC 791 Section 3.2 ................ 45 4.2.2.8 重组: RFC 791 Section 3.2 ................ 46 4.2.2.9 生存时间: RFC 791 Section 3.2 ............ 46 4.2.2.10 多子网广播: RFC 922 ..................... 47

4.2.2.11 寻址: RFC 791 Section 3.2 ............... 47 4.2.3 具体问题 .................................. 50 4.2.3.1 IP 广播地址 .............................. 50 4.2.3.2 IP 组播 ................................. 50 4.2.3.3 Path MTU Discovery ....................... 51 4.2.3.4 子网划分 ................................ 51 4.3 Internet 控制消息协议 - ICMP ................. 52 4.3.1 简介 ...................................... 52 4.3.2 一般问题 .................................. 53 4.3.2.1 未知消息类型 ............................ 53 4.3.2.2 ICMP 消息 TTL ............................ 53 4.3.2.3 原始消息头部 ............................ 53 4.3.2.4 ICMP 消息源地址 .......................... 53 4.3.2.5 TOS 和 Precedence ......................... 54 4.3.2.6 Source Route .............................. 54 4.3.2.7 何时不发送 ICMP 错误 ..................... 55 4.3.2.8 速率限制 ................................ 56 4.3.3 具体问题 .................................. 56 4.3.3.1 Destination Unreachable ................... 56 4.3.3.2 Redirect ................................. 57 4.3.3.3 Source Quench ............................. 57 4.3.3.4 Time Exceeded ............................. 58 4.3.3.5 Parameter Problem ......................... 58 4.3.3.6 Echo Request/Reply ........................ 58 4.3.3.7 Information Request/Reply ................. 59 4.3.3.8 Timestamp and Timestamp Reply .............. 59 4.3.3.9 Address Mask Request/Reply ................ 61 4.3.3.10 Router Advertisement and Solicitations ... 62 4.4 Internet 组管理协议 - IGMP .................... 62 5. Internet 层 - 转发 ............................. 63 5.1 简介 ........................................ 63 5.2 转发逐节说明 ................................ 63 5.2.1 转发算法 .................................. 63 5.2.1.1 一般情况 ................................ 64 5.2.1.2 单播 .................................... 64 5.2.1.3 组播 .................................... 65 5.2.2 IP 头部验证 ............................... 67 5.2.3 本地交付决策 .............................. 69 5.2.4 确定下一跳地址 ............................ 71 5.2.4.1 IP 目标地址 .............................. 72 5.2.4.2 本地/远程决策 ........................... 72 5.2.4.3 下一跳地址 .............................. 74 5.2.4.4 管理偏好 ................................ 77 5.2.4.5 负载拆分 ................................ 79 5.2.5 未使用的 IP 头部比特: RFC-791 Section 3.1 ... 79 5.2.6 分片和重组: RFC-791, Section 3.2 ............................... 80 5.2.7 Internet 控制消息协议 - ICMP ............... 80

5.2.7.1 Destination Unreachable ................... 80 5.2.7.2 Redirect ................................. 82 5.2.7.3 Time Exceeded ............................. 84 5.2.8 Internet 组管理协议 - IGMP ................. 84 5.3 具体问题 .................................... 85 5.3.1 生存时间 (TTL) ............................. 85 5.3.2 服务类型 (TOS) ............................. 86 5.3.3 IP Precedence .............................. 87 5.3.3.1 Precedence-Ordered Queue Service .......... 88 5.3.3.2 低层 Precedence 映射 ..................... 89 5.3.3.3 所有路由器的 Precedence 处理 ............. 90 5.3.4 链路层广播的转发 .......................... 92 5.3.5 Internet 层广播的转发 ...................... 92 5.3.5.1 有限广播 ................................ 93 5.3.5.2 定向广播 ................................ 93 5.3.5.3 全子网定向广播 .......................... 94 5.3.5.4 子网定向广播 ............................ 94 5.3.6 拥塞控制 .................................. 94 5.3.7 Martian 地址过滤 ........................... 96 5.3.8 源地址验证 ................................ 97 5.3.9 数据包过滤和访问列表 ...................... 97 5.3.10 组播路由 ................................. 98 5.3.11 转发控制 ................................. 98 5.3.12 状态变化 ................................. 99 5.3.12.1 当路由器停止转发时 ..................... 99 5.3.12.2 当路由器开始转发时 ..................... 100 5.3.12.3 当接口失败或被禁用时 ................... 100 5.3.12.4 当接口被启用时 ......................... 100 5.3.13 IP 选项 ................................... 101 5.3.13.1 无法识别的选项 ......................... 101 5.3.13.2 Security Option ......................... 101 5.3.13.3 Stream Identifier Option ................ 101 5.3.13.4 Source Route Options ..................... 101 5.3.13.5 Record Route Option ...................... 102 5.3.13.6 Timestamp Option ........................ 102 6. 传输层 ...................................... 103 6.1 用户数据报协议 - UDP ......................... 103 6.2 传输控制协议 - TCP ........................... 104 7. 应用层 - 路由协议 ............................ 106 7.1 简介 ........................................ 106 7.1.1 路由安全考虑事项 .......................... 106 7.1.2 Precedence ................................. 107 7.1.3 消息验证 .................................. 107 7.2 内部网关协议 ................................ 107 7.2.1 简介 ...................................... 107 7.2.2 开放最短路径优先 - OSPF ................... 108 7.2.3 中间系统到中间系统 - Dual IS-IS ........... 108

7.3 外部网关协议 ................................ 109 7.3.1 简介 ...................................... 109 7.3.2 边界网关协议 - BGP ........................ 109 7.3.2.1 简介 ..................................... 109 7.3.2.2 协议逐节说明 ............................ 110 7.3.3 不使用外部协议的 AS 间路由 ................ 110 7.4 静态路由 .................................... 111 7.5 路由信息过滤 ................................ 112 7.5.1 路由验证 .................................. 113 7.5.2 基本路由过滤 .............................. 113 7.5.3 高级路由过滤 .............................. 114 7.6 路由协议间信息交换 .......................... 114 8. 应用层 - 网络管理协议 ........................ 115 8.1 简单网络管理协议 - SNMP ...................... 115 8.1.1 SNMP 协议元素 ............................. 115 8.2 Community Table .............................. 116 8.3 标准 MIB ..................................... 118 8.4 厂商特定 MIB ................................ 119 8.5 保存更改 .................................... 120 9. 应用层 - 其他协议 ............................ 120 9.1 BOOTP ........................................ 120 9.1.1 简介 ...................................... 120 9.1.2 BOOTP 中继代理 ............................ 121 10. 操作和维护 ................................. 122 10.1 简介 ....................................... 122 10.2 路由器初始化 ............................... 123 10.2.1 最小路由器配置 ........................... 123 10.2.2 地址和前缀初始化 ......................... 124 10.2.3 使用 BOOTP 和 TFTP 进行网络启动 .......... 125 10.3 操作和维护 ................................. 126 10.3.1 简介 ..................................... 126 10.3.2 带外访问 ................................. 127 10.3.2 路由器 O&M 功能 .......................... 127 10.3.2.1 维护 - 硬件诊断 ........................ 127 10.3.2.2 控制 - 转储和重启 ...................... 127 10.3.2.3 控制 - 配置路由器 ...................... 128 10.3.2.4 系统软件的网络启动 ..................... 128 10.3.2.5 检测并响应配置错误 ..................... 129 10.3.2.6 最小化中断 ............................. 130 10.3.2.7 控制 - 排查问题 ........................ 130 10.4 安全考虑事项 ............................... 131 10.4.1 审计和审计轨迹 ........................... 131 10.4.2 配置控制 ................................. 132 11. 参考文献 .................................... 133 Appendix A. 源路由主机要求 ...................... 145

Appendix B. 术语表 .............................. 146 Appendix C. 未来方向 ............................ 152 Appendix D. 组播路由协议 ........................ 154 D.1 简介 ........................................ 154 D.2 距离向量组播路由协议 - DVMRP ................ 154 D.3 OSPF 组播扩展 - MOSPF ....................... 154 D.4 协议无关组播 - PIM .......................... 155 Appendix E. 其他下一跳选择算法 .................. 155 E.1 一些历史视角 ................................ 155 E.2 其他剪枝规则 ................................ 157 E.3 一些路由查找算法 ............................ 159 E.3.1 修订后的经典算法 .......................... 159 E.3.2 变体 Router Requirements 算法 .............. 160 E.3.3 OSPF 算法 ................................. 160 E.3.4 集成 IS-IS 算法 ........................... 162 安全考虑事项 .................................... 163 Appendix F: 历史路由协议 ........................ 164 F.1 外部网关协议 - EGP .......................... 164 F.1.1 简介 ...................................... 164 F.1.2 协议逐节说明 .............................. 165 F.2 路由信息协议 - RIP .......................... 167 F.2.1 简介 ...................................... 167 F.2.2 协议逐节说明 .............................. 167 F.2.3 具体问题 .................................. 172 F.3 网关到网关协议 - GGP ........................ 173 致谢 ............................................ 173 编辑地址 ........................................ 175

1. 简介

本备忘录替代 RFC 1716, "Requirements for Internet Gateways" ([INTRO:1]).

本备忘录定义并讨论执行 Internet 协议族网络层转发功能的设备所应满足的 要求. Internet 社区通常将这类设备称为 IP 路由器, 或简称路由器; OSI 社区将这类设备称为中间系统. 许多较早的 Internet 文档将这些设备称为 网关, 但近年来这一名称已基本不再受青睐, 以避免与应用网关混淆.

IP 路由器与其他类型的数据包交换设备的区别在于, 路由器在交换过程中会 检查 IP 协议头部. 它通常会移除收到消息时携带的链路层头部, 修改 IP 头部, 并替换为用于重传的链路层头部.

本备忘录的作者承认, 读者也应理解, 许多路由器支持不止一种协议. 未来, Internet 中越来越大的部分将需要支持多个协议族. 然而, 本备忘录并不试图 为 TCP/IP 以外的协议族规定 Internet 要求.

本文档列举了连接到 Internet 的路由器必须使用的标准协议, 并通过引用纳入 描述这些协议当前规范的 RFC 和其他文档. 它更正了被引用文档中的错误, 并为实现者增加了进一步的讨论和指导.

对于每个协议, 本备忘录还包含一组明确的要求, 推荐和选项. 读者必须理解, 本备忘录中的要求列表本身并不完整. Internet 协议路由器的完整要求集合主要 由标准协议规范文档定义, 并由本备忘录中包含的更正, 修订和补充加以完善.

本备忘录应与 Requirements for Internet Hosts RFC ([INTRO:2] 和 [INTRO:3]) 一并阅读. Internet 主机和路由器都必须能够发起 IP 数据报, 并接收发往自身 的 IP 数据报. Internet 主机和路由器之间的主要区别在于, 路由器实现转发 算法, 而 Internet 主机不要求具备转发能力. 任何充当路由器的 Internet 主机都必须遵守本备忘录中的要求.

开放系统互连的目标要求路由器在必要时必须能够作为 Internet 主机正确运行. 为实现这一点, 本备忘录为此类情况提供了指导. 为简化文档并便于更新, 本备 忘录尽量避免与 [INTRO:2] 和 [INTRO:3] 中的主机要求讨论发生重叠, 并通过 引用纳入这些文档中的相关要求. 在某些情况下, [INTRO:2] 和 [INTRO:3] 中 陈述的要求会被本文档取代.

在仔细阅读 RFC 后善意实现这些协议, 该实现与本备忘录要求之间的差异应该 只会是细微差异. 生成这样的实现通常需要与 Internet 技术社区进行一定互动, 并且必须遵循良好的通信软件工程实践. 在许多情况下, 本文档中的要求已经在 标准协议文档中明示或暗示, 因而将其纳入本文在某种意义上是重复的. 之所以 纳入这些要求, 是因为过去某些实现做出了错误选择, 从而造成互操作性, 性能 和/或健壮性问题.

本备忘录包含对许多要求和推荐的讨论与解释. 简单列出要求会有危险, 因为:

o 某些必需特性比其他特性更重要, 某些特性则是可选的.

o 某些特性在某些路由器应用中至关重要, 但在其他应用中无关紧要.

o 针对受限环境设计的特定厂商产品, 可能有正当理由选择使用不同规范.

然而, 为实现任意路由器在 Internet 的多样性和复杂性中互操作这一总体目标, 必须遵循本备忘录的规范. 尽管多数当前实现以不同方式未能满足这些要求, 有些问题较小, 有些问题较大, 但本规范是我们需要迈向的理想目标.

这些要求基于当前 Internet 架构水平. 本备忘录将在需要时更新, 以提供额外 澄清, 或在规范仍在演进的领域纳入额外信息.

1.1 阅读本文档

1.1.1 组织结构

本备忘录仿照 [INTRO:2] 和 [INTRO:3] 使用的分层组织方式. 因此, 第 2 章 描述 Internet 架构中的各层. 第 3 章涵盖链路层. 第 4 章和第 5 章涉及 Internet 层协议和转发算法. 第 6 章涵盖传输层. 上层协议分布在第 7 章, 第 8 章和第 9 章中. 第 7 章讨论路由器用于相互交换路由信息的协议. 第 8 章讨论网络管理. 第 9 章讨论其他上层协议. 最后一章涵盖操作和维护功能. 选择这种组织方式是为了简单, 清晰, 并与 Host Requirements RFC 保持一致. 本备忘录的附录包括参考书目, 术语表, 以及关于路由器标准未来方向的一些 推测.

在描述这些要求时, 我们假定实现严格反映协议分层. 然而, 对协议族和推荐的 实现方法而言, 严格分层都是一个不完美的模型. 不同层中的协议会以复杂且 有时微妙的方式相互作用, 特定功能通常会涉及多层. 实现中存在许多设计选择, 其中许多选择涉及创造性地打破严格分层. 强烈建议每位实现者阅读 [INTRO:4] 和 [INTRO:5].

本备忘录的每个主要章节都组织为以下小节:

(1) 简介

(2) 协议逐节说明 - 逐节考察协议规范文档, 更正错误, 说明可能含糊或定义 不充分的要求, 并提供进一步澄清或解释.

(3) 具体问题 - 讨论逐节说明中未包含的协议设计和实现问题.

在本备忘录的许多单独主题下, 有标记为 DISCUSSION 或 IMPLEMENTATION 的 括号材料. 这些材料旨在为前面的要求文本提供理由, 澄清或解释. IMPLEMENTATION 材料包含实现者可能希望考虑的建议方法. DISCUSSION 和 IMPLEMENTATION 部分不是标准的一部分.

1.1.2 要求

在本备忘录中, 用于定义每项具体要求重要性的词语以大写形式出现. 这些词语 如下:

o MUST 该词表示该事项是规范的绝对要求. 违反此类要求是根本性错误; 不存在可以 合理违反它的情况.

o MUST IMPLEMENT 该短语表示本规范要求实现该事项, 但不要求默认启用它.

o MUST NOT 该短语表示该事项是规范的绝对禁止项.

o SHOULD 该词表示在特定情况下可能存在忽略该事项的正当理由, 但在选择不同做法 之前, 应充分理解其全部影响并仔细权衡该情形.

o SHOULD IMPLEMENT 该短语含义类似于 SHOULD, 但用于表示我们推荐提供某一特定特性, 不一定 推荐默认启用它.

o SHOULD NOT 该短语表示在特定情况下, 所描述的行为可能存在正当理由, 或甚至是有用的. 即便如此, 在实现任何带有此标签描述的行为之前, 应充分理解其全部影响并 仔细权衡该情形.

o MAY 该词表示该事项是真正可选的. 例如, 某个厂商可能因为特定市场需要或因为 它增强了产品而选择包含该事项; 另一个厂商则可以省略同一事项.

1.1.3 符合性

某些要求适用于所有路由器. 其他要求仅适用于实现特定特性或协议的路由器. 在以下段落中, relevant 指适用于所有路由器的要求与由于某一路由器已实现的 特性和协议集合而适用于该路由器的要求集合的并集.

请注意, 并非所有 Relevant 要求都在本备忘录中直接陈述. 本备忘录的各个 部分通过引用纳入了 Host Requirements 规范 [INTRO:2] 和 [INTRO:3] 的若干 章节. 就判定是否符合本备忘录而言, 某项 Relevant 要求是直接陈述在本备忘 录中, 还是仅从这些文档之一通过引用纳入, 并无区别.

如果某个实现满足所有 Relevant MUST, MUST IMPLEMENT 和 MUST NOT 要求, 则称 该实现为有条件符合. 如果某个实现有条件符合, 并且还满足所有 Relevant SHOULD, SHOULD IMPLEMENT 和 SHOULD NOT 要求, 则称该实现为无条件符合. 如果 某个实现不是有条件符合的 (即未能满足一个或多个 Relevant MUST, MUST IMPLEMENT 或 MUST NOT 要求), 则该实现不符合.

本规范有时会指出某个实现 SHOULD 实现一个管理变量, 并且该变量 SHOULD 具有 某个默认值. 无条件符合的实现会实现默认行为, 并且如果还实现了其他行为, 则实现该变量. 有条件符合的实现会清楚记录该变量的默认设置是什么, 或者在 未实现该变量的情况下, 可以被理解为什么. 如果某个实现既没有实现该变量, 又选择了不同的行为, 则该实现不符合.

对于任何 SHOULD 和 SHOULD NOT 要求, 路由器可以提供一个配置选项, 使路由器 采取不同于该要求所规定的行为. 如果该选项具有默认设置, 且该默认设置使 路由器按要求的方式运行, 则提供这样的配置选项不会使路由器关于无条件符合 的声明失效.

同样, 除非本备忘录明确禁止, 路由器可以提供导致其违反 MUST 或 MUST NOT 要求的选项. 提供此类选项的路由器当且仅当每个此类选项都有一个默认设置, 且该默认设置使路由器符合本备忘录的要求时, 才是符合的 (无论是完全符合 还是有条件符合). 请注意, 本备忘录的作者虽然了解市场现实, 但强烈不建议 提供此类选项. 要求被标记为 MUST 或 MUST NOT, 是因为该领域专家认为这些 要求对于 Internet 中的互操作性或正确运行尤其重要. 厂商应该仔细权衡提供 违反这些规则的选项所带来的客户支持成本.

当然, 本备忘录不是 IP 路由器的完整规范, 而更接近于 OSI 领域所称的 profile. 例如, 本备忘录要求实现若干协议. 虽然这些协议规范的大部分内容没有在本备 忘录中重复, 但实现者仍然必须按照那些规范来实现这些协议.

1.2 与其他标准的关系

在检查协议规范和标准化状态时, 有若干值得关注的参考文档:

o INTERNET OFFICIAL PROTOCOL STANDARDS
   本文档描述 Internet 标准流程并列出协议的标准状态. 在撰写本文时,
   本文档的当前版本为 STD 1, RFC 1780, [ARCH:7]. 本文档会定期重新发布.
   应始终查阅 RFC 存储库并使用本文档的最新版本.

o Assigned Numbers
   本文档列出各种协议中使用的参数的已分配值. 例如, 它列出 IP 协议代码,
   TCP 端口号, Telnet Option Code, ARP 硬件类型和 Terminal Type 名称.
   在撰写本文时, 本文档的当前版本为 STD 2, RFC 1700, [INTRO:7]. 本文档
   会定期重新发布. 应始终查阅 RFC 存储库并使用本文档的最新版本.

o Host Requirements
   这一对文档审查适用于主机的规范, 并对任何歧义提供指导和澄清. 请注意,
   除非本备忘录另有规定, 这些要求也适用于路由器. 在撰写本文时, 这些
   文档的当前版本是 RFC 1122 和 RFC 1123 (STD 3), [INTRO:2] 和 [INTRO:3].

o Router Requirements (formerly Gateway Requirements)
   即本备忘录.

请注意, 这些文档会在不同时间修订和更新; 如果这些文档之间存在差异, 最新 文档必须优先.

这些以及其他 Internet 协议文档可以从以下位置获得:

                           The InterNIC
                          DS.INTERNIC.NET
              InterNIC Directory and Database Service
                         [email protected]
                          +1-908-668-6587
                   URL: http://ds.internic.net/

1.3 一般考虑事项

Internet 软件厂商已经吸取了若干重要经验, 新厂商应该认真考虑这些经验.

1.3.1 Internet 的持续演进

Internet 的巨大增长暴露出大型、基于数据报的数据包通信系统在管理和扩展 方面的问题. 这些问题正在被处理, 因而本备忘录所描述的规范将持续演进. 新的路由协议, 算法和架构正在不断开发. 新的 internet layer protocol 以及 对现有协议的修改也在不断设计之中. 路由器在 Internet 中发挥关键作用, 而 部署在 Internet 中的路由器数量远少于主机数量. 因此, 厂商应该预期路由器 标准将继续比主机标准演进得更快. 这些变更将经过仔细规划和控制, 因为厂商 和负责网络运行的组织广泛参与了这种规划.

开发, 演进和修订是当今计算机网络协议的特征, 这种情况还会持续若干年. 如果某个厂商为 Internet 协议族 (或任何其他协议族!) 开发计算机通信软件, 然后未能随着规范变化维护和更新该软件, 就会留下一批不满意的客户. Internet 是一个大型通信网络, 用户通过它保持持续联系. 经验表明, 厂商软件缺陷的 信息会在 Internet 技术社区中迅速传播.

1.3.2 健壮性原则

在协议的每一层, 都有一条通用规则 (来自 Jon Postel 的 [TRANS:2]), 应用 该规则可以在健壮性和互操作性方面带来巨大收益:

                  做自己该做的事时要保守,
            接受他人输入时要宽容.

软件应被编写为能够处理每一种可想象的错误, 无论这种错误多么不可能发生. 最终总会有一个数据包带着那种特定的错误和属性组合到来, 如果软件没有准备 好, 就可能造成混乱. 最好假设网络中充满恶意实体, 它们会发送被设计为造成 最坏可能影响的数据包. 这种假设会引导出适当的保护性设计. Internet 中最 严重的问题是由低概率事件触发的意外机制造成的; 单纯的人类恶意也绝不会 走出如此曲折的路径!

必须在路由器软件的所有层级中设计对变化的适应能力. 举一个简单例子, 假设 某个协议规范包含某一特定头部字段的值枚举, 例如 type 字段, 端口号或错误 代码; 必须假定这个枚举是不完整的. 如果协议规范定义了四个可能的错误代码, 当第五个代码被定义时, 软件不得崩溃. 未定义代码可以被记录到日志中, 但 不得导致失败.

该原则的第二部分几乎同样重要: 主机或其他路由器上的软件可能包含缺陷, 使得利用合法但晦涩的协议特性并不明智. 偏离显而易见且简单的路径太远是 不明智的, 否则可能在别处产生不良影响. 其推论是要注意行为异常的主机; 路由器软件应准备好在存在行为异常主机的情况下继续生存. Internet 中路由器 的一项重要功能, 是限制这类主机可能对共享通信设施造成的破坏程度.

1.3.3 错误日志

Internet 包含种类繁多的系统, 每个系统都实现许多协议和协议层, 其中一些 系统的 Internet 协议软件包含缺陷和误导性特性. 由于功能的复杂性, 多样性 和分布性, 问题诊断往往非常困难.

如果路由器包含一个经过精心设计的设施, 用于记录错误或异常事件, 将有助于 问题诊断. 记录错误时尽可能包含更多诊断信息很重要. 特别是, 记录导致错误 的数据包头部通常很有用. 然而, 必须注意确保错误日志不会消耗过多资源, 或以其他方式干扰路由器运行.

异常但无害的协议事件往往会淹没错误日志文件; 可以通过使用循环日志, 或仅 在诊断已知故障时启用日志来避免这种情况. 对连续重复消息进行过滤和计数 可能有用. 一个看起来效果良好的策略是同时:

o 始终统计异常情况, 并使这些计数可通过管理协议访问 (见第 8 章); 以及

o 允许选择性地启用对多种事件的日志记录. 例如, 能够记录所有内容, 或记录 主机 X 的所有内容, 可能很有用.

[MGT:5] 中进一步讨论了此主题.

1.3.4 配置

在理想世界中, 路由器应易于配置, 甚至可能完全自配置. 然而, 现实世界中的 实践经验表明, 这是一个不可能的目标, 并且厂商许多试图简化配置的尝试, 实际上给客户造成的麻烦多于它们所避免的问题. 举一个极端例子, 一个被设计 为无需任何配置信息即可启动并开始路由数据包的路由器, 几乎必然会选择某个 错误参数, 可能对任何不幸连接到它的网络造成严重问题.

本备忘录经常要求某个参数是可配置选项. 这样做有若干原因. 在少数情况下, 当前对最佳值仍存在一些不确定性或分歧, 将来可能需要更新推荐值. 在其他 情况下, 该值确实取决于外部因素, 例如通信负载分布, 或邻近网络的速度和 拓扑, 而自调优算法不可用且可能不足. 在某些情况下, 由于管理要求而需要 可配置性.

最后, 某些配置选项是为了与过时或错误的协议实现通信所必需的; 这些实现 没有源代码可用, 并且仍存在于 Internet 的许多部分. 为了使正确系统能与 这些有缺陷的系统共存, 管理员偶尔必须错误配置正确系统. 随着有缺陷系统 退役, 这个问题将逐步自行纠正, 但厂商不能忽视它.

当我们说某个参数必须可配置时, 并不意在要求每次启动时都必须从配置文件中 显式读取其值. 对许多参数而言, 存在一个适用于除最特殊情况之外所有情况的 值. 在这类情况下, 如果未显式设置该参数, 让它默认为该值是完全合理的.

在某些情况下, 本备忘录要求这类默认值采用特定值. 当配置项控制对现有有 缺陷系统的兼容时, 默认值的选择是一个敏感问题. 如果 Internet 要成功收敛 到完全互操作, 实现内置的默认值必须实现正式协议, 而不是为了适应有缺陷 实现而采用错误配置. 尽管市场考虑曾使一些厂商选择错误配置作为默认值, 我们仍敦促厂商选择符合标准的默认值.

最后, 我们指出, 厂商需要为所有配置参数及其限制和影响提供充分文档.

1.4 算法

本备忘录在若干位置规定了路由器应遵循的具体算法. 这些算法本身并不是对 路由器的要求. 路由器不必按照本文档中写出的形式实现每个算法. 相反, 实现 必须向外部世界呈现与严格逐字实现指定算法相同的行为.

算法的描述方式不同于优秀实现者实际实现它们的方式. 出于说明目的, 本文 选择了一种强调简洁性, 清晰性以及独立于实现细节的风格. 优秀实现者会选择 能产生与这些算法相同结果的算法和实现方法, 但这些方法可能更高效或适用 范围较窄.

我们指出, 高效路由器实现的技艺超出了本备忘录的范围.

5. Internet 层 - 转发

5.1 简介

本节描述数据包转发过程.

5.2 转发逐节说明

IP 中没有单独的转发功能规范. 相反, 转发由 internet layer protocols 的协议 规范覆盖 ([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8] 和 [ROUTE:11]).

5.2.1 转发算法

由于主要协议文档都没有详细描述转发算法, 我们在此给出该算法. 这只是一个 总体轮廓, 省略了拥塞处理等重要细节, 这些细节将在后续章节处理.

实现不要求完全遵循 Sections [5.2.1.1], [5.2.1.2] 和 [5.2.1.3] 中给出的 算法. 编写路由器软件的一大挑战, 是在仍然达到该算法同等效果的同时, 最大化 路由器转发数据包的速率. 如何做到这一点的细节超出了本文档范围, 部分原因是 这些细节高度依赖路由器架构. 因此, 我们只指出各步骤之间的顺序依赖关系:

(1) 路由器必须在基于 IP 头部内容执行任何动作之前, 按 Section [5.2.2] 中的 描述验证 IP 头部. 这允许路由器在消耗其他资源之前检测并丢弃坏数据包.

(2) 某些 IP 选项的处理要求路由器将其 IP 地址插入选项中. 如 Section [5.2.4] 所述, 插入的地址必须是发送该数据包的逻辑接口地址; 如果数据包通过未编号 接口发送, 则必须是路由器的 router-id. 因此, 这些选项的处理必须等到输出 接口被选定之后才能完成.

(3) 由于 Section [4.2.2.9] 中提到的原因, 路由器不能在检查数据包是否应交付 给路由器自身之前检查并递减 TTL.

(4) 更一般地说, 当数据包被本地交付给路由器时, 其 IP 头部不得以任何方式被 修改 (但路由器可能要求向 IP 头部中的任何 Timestamp options 插入 timestamp). 因此, 在路由器确定数据包是否要本地交付给路由器之前, 它不能以任何自己 没准备撤销的方式更新 IP 头部.

5.2.1.1 一般情况

本节涵盖一般转发算法. 该算法适用于所有形式的待转发数据包: 单播, 组播和广播.

(1) 路由器从 Link Layer 接收 IP 数据包 (以及 Section [3.1] 中描述的关于它的 附加信息).

(2) 路由器按 Section [5.2.2] 中的描述验证 IP 头部. 请注意, 除了在步骤 (4) 中排队等待本地交付的 IP 分片之外, 不执行 IP 重组.

(3) 路由器执行任何 IP 选项的大部分处理. 如 Section [5.2.4] 所述, 某些 IP 选项在作出路由决策后需要额外处理.

(4) 路由器按 Section [5.2.3] 中的描述检查 IP 数据报的目标 IP 地址, 以确定 应如何继续处理该 IP 数据报. 有三种可能:

 o IP 数据报以该路由器为目标, 应该排队等待本地交付, 必要时执行重组.

 o IP 数据报不以该路由器为目标, 应该排队等待转发.

 o IP 数据报应该排队等待转发, 但还必须将其 (一个副本) 排队等待本地交付.

5.2.1.2 单播

由于 [INTRO:2] 已充分覆盖本地交付情形, 以下内容假定 IP 数据报已排队等待转发. 如果目标是 IP 单播地址:

(5) 转发器确定该数据包的下一跳 IP 地址, 通常是通过在路由器路由表中查找数据包 目标来完成. 此过程在 Section [5.2.4] 中有更详细描述. 此过程还决定应使用 哪个网络接口发送该数据包.

(6) 转发器验证是否允许转发该数据包. 源地址和目标地址应该有效, 如 Section [5.3.7] 和 Section [5.3.4] 所述. 如果路由器支持转发管理约束, 例如 Section [5.3.9] 中描述的约束, 则必须满足这些约束.

(7) 转发器递减 (至少递减一) 并检查数据包 TTL, 如 Section [5.3.1] 所述.

(8) 转发器执行步骤 3 中无法完成的任何 IP 选项处理.

(9) 转发器执行任何必要的 IP 分片, 如 Section [4.2.2.7] 所述. 由于此步骤发生 在出站接口选择 (步骤 5) 之后, 同一数据报的所有分片都将通过同一接口传输.

(10) 转发器确定数据包下一跳的 Link Layer 地址. 完成此操作的机制依赖 Link Layer (见第 3 章).

(11) 转发器将 IP 数据报 (或其每个分片) 封装在适当的 Link Layer 帧中, 并将其 排队到步骤 5 中选择的接口上输出.

(12) 如有必要, 转发器按 Section [4.3.3.2] 中的描述发送 ICMP redirect.

5.2.1.3 组播

如果目标是 IP multicast, 则采取以下步骤.

请注意, IP unicast 转发与 IP multicast 转发之间的主要差异是:

o IP multicast 通常同时基于数据报的源 IP 地址和目标 IP 地址进行转发,

o IP multicast 使用 expanding ring search,

o IP multicast 作为 Link Level multicast 转发, 并且

o 对 IP multicast 数据报从不发送 ICMP error.

请注意, IP multicast 转发仍带有一定实验性. 因此, 下面给出的算法不是强制性的, 仅作为示例提供.

(5a) 基于数据报头部中的 IP 源地址和目标地址, 路由器确定该数据报是否是在适合 转发的接口上收到的. 如果不是, 则静默丢弃该数据报. 确定适当接收接口的方法 取决于正在使用的 multicast routing algorithm. 在最简单的算法之一 reverse path forwarding (RPF) 中, 适当接口是用于把 unicast 转发回数据报源的接口.

(6a) 基于数据报头部中的 IP 源地址和目标地址, 路由器确定数据报的出接口. 为了 实现 IP multicast 的 expanding ring search (见 [INTERNET:4]), 为每个 出接口指定一个最小 TTL 值. 对于每个最小 TTL 值小于或等于数据报头部中 TTL 值的出接口, 都通过在该接口上分别应用其余步骤来转发该 multicast 数据报的 一个副本.

(7a) 路由器将数据包的 TTL 递减一.

(8a) 转发器执行步骤 (3) 中无法完成的任何 IP 选项处理.

(9a) 转发器执行任何必要的 IP fragmentation, 如 Section [4.2.2.7] 所述.

(10a) 转发器确定在 Link Level 封装中要使用的 Link Layer 地址. 完成此操作的 机制依赖 Link Layer. 在 LAN 上, 会作为数据报 IP multicast 地址的一种 算法转换, 选择一个 Link Level multicast 或 broadcast. 更多细节见各个 IP-over-xxx 规范.

(11a) 转发器将数据包 (或其每个分片) 封装在适当的 Link Layer 帧中, 并将其 排队到适当接口上输出.

5.2.2 IP 头部验证

在路由器能够处理任何 IP 数据包之前, 它必须对该数据包的 IP 头部执行以下基本 有效性检查, 以确保该头部有意义. 如果数据包未通过以下任一测试, 则必须静默丢弃 它, 并且应该记录该错误.

(1) Link Layer 报告的数据包长度必须足以容纳最小长度的合法 IP 数据报 (20 bytes).

(2) IP checksum 必须正确.

(3) IP version number 必须是 4. 如果 version number 不是 4, 则该数据包可能是 另一版本的 IP, 例如 IPng 或 ST-II.

(4) IP header length 字段必须足以容纳最小长度的合法 IP 数据报 (20 bytes = 5 words).

(5) IP total length 字段必须足以容纳 IP 数据报头部, 该头部长度由 IP header length 字段指定.

路由器不得具有允许禁用这些测试中任何一项的配置选项.

如果数据包通过第二项和第三项测试, IP header length 字段至少为 4, 并且 IP total length 字段以及 Link Layer 报告的数据包长度都至少为 16, 则尽管有上述 规则, 路由器可以用 ICMP Parameter Problem 消息响应, 其 pointer 指向 IP header length 字段 (如果第四项测试失败) 或 IP total length 字段 (如果第五项测试失败). 不过, 它仍必须丢弃该数据包, 并且仍应该记录该错误.

这些规则 (以及本文档整体) 仅适用于 Internet Protocol 的 version 4. 不应将这些 规则解释为禁止路由器支持其他 IP 版本. 此外, 如果路由器确实能够把某个数据包 归类为其他版本的 IP, 则在本备忘录的语境中不应把该数据包视为错误数据包.

实现:

出于错误报告目的, 需要确定头部无效的原因, 尽管这并不总是完全可能. 可能有四种 原因:

o Link Layer 截断了 IP 头部

o 数据报正在使用标准版本 (version 4) 以外的 IP 版本.

o IP 头部在传输过程中被损坏.

o 发送方生成了非法 IP 头部.

按列出的顺序执行这些检查可能是可取的, 因为我们认为此顺序最可能正确地归类错误 原因. 出于错误报告目的, 也可能需要检查未通过这些测试的数据包是否具有表示 IPng 或 ST-II 的 IP version number; 这些情况应该按各自规范处理.

此外, 路由器应该验证 Link Layer 报告的数据包长度至少与该数据包 IP 头部中记录的 IP total length 一样大. 如果看起来数据包已被截断, 则必须丢弃该数据包, 应该记录 该错误, 并且路由器应该用 ICMP Parameter Problem 消息响应, 其 pointer 指向 IP total length 字段.

讨论:

由于任何关注数据损坏的高层协议都会在数据包到达最终目标时检测到数据包数据的截断, 因此为了维持协议正确性, 路由器并非绝对必须执行上面建议的检查. 不过, 通过执行此 检查, 路由器可以大幅简化确定路径中哪一跳正在截断数据包的工作. 这也会减少该路由器 下游的资源消耗, 因为下游系统无需处理该数据包.

最后, 如果 IP 头部中的目标地址不是路由器的某个地址, 路由器应该验证该数据包不包含 Strict Source and Record Route 选项. 如果数据包未通过此测试 (即它包含 strict source route 选项), 路由器应该记录该错误, 并且应该用 ICMP Parameter Problem 错误响应, 其 pointer 指向违规数据包的 IP destination address.

讨论:

有些人可能会建议路由器用 Bad Source Route 消息响应, 而不是用 Parameter Problem 消息. 不过, 当数据包未通过此测试时, 通常表示前一跳路由器存在协议错误; 而 Bad Source Route 会暗示源主机请求了一条不存在或损坏的网络路径.

5.2.3 本地交付决策

当路由器收到 IP 数据包时, 它必须决定该数据包是寻址到该路由器 (并应该本地交付), 还是寻址到另一个系统 (并应该由转发器处理). 还存在一种混合情形, 即某些 IP broadcast 和 IP multicast 既本地交付又被转发. 路由器必须使用以下规则确定这三种 情形中的哪一种适用.

o 未过期的 source route 选项, 是指其 pointer 值没有指过 source route 中最后 一个条目的选项. 如果数据包包含未过期的 source route 选项, 则推进该选项中的 pointer, 直到 pointer 指过选项中的最后一个地址, 或下一个地址不是路由器自己的 某个地址. 在后一种 (正常) 情况下, 不管下面的规则如何, 该数据包都被转发 (而不是本地交付).

o 在以下情况下, 数据包被本地交付, 且不考虑转发:

• 数据包的目标地址与路由器的某个 IP 地址完全匹配,

• 数据包的目标地址是 limited broadcast address ({-1, -1}), 或者

• 数据包的目标是永不转发的 IP multicast 地址 (例如 224.0.0.1 或 224.0.0.2), 并且与该数据包到达的物理接口关联的至少一个逻辑接口是目标 multicast group 的成员.

o 在以下情况下, 数据包被传递给转发器并且本地交付:

• 数据包的目标地址是一个 IP broadcast 地址, 它寻址到路由器的至少一个逻辑接口, 但不寻址到与该数据包到达的物理接口关联的任何逻辑接口.

• 数据包的目标是允许被转发的 IP multicast 地址 (不同于 224.0.0.1 和 224.0.0.2), 并且与该数据包到达的物理接口关联的至少一个逻辑接口是目标 multicast group 的成员.

o 如果数据包的目标地址是一个 IP broadcast 地址 (limited broadcast address 除外), 并且该地址寻址到与该数据包到达的物理接口关联的至少一个逻辑接口, 则该数据包被 本地交付. 该数据包也被传递给转发器, 除非该数据包到达的链路使用一种 IP 封装, 这种封装不会以不同于 unicast 的方式封装 broadcast (例如, 通过使用不同的 Link Layer 目标地址).

o 在所有其他情况下, 数据包被传递给转发器.

讨论:

第四个项目符号最后一句中要求的目的, 是处理发往同一物理电缆上另一个网络前缀的 directed broadcast. 通常, 这会按预期工作: 发送方将 broadcast 作为 Link Layer unicast 发送给路由器. 路由器注意到它是作为 unicast 到达的, 因而它必然以不同于 发送方发送它所在网络前缀的另一个网络前缀为目标. 因此, 路由器可以安全地将其作为 Link Layer broadcast 从它到达的同一 (物理) 接口发出. 不过, 如果路由器无法判断 该数据包是否作为 Link Layer unicast 收到, 这一句会确保路由器执行安全但错误的 行为, 而不是不安全但正确的行为.

实现:

如 Section [5.3.4] 所述, 作为 Link Layer broadcast 收到的数据包通常不被转发. 避免将那些之后会因该节规则而被丢弃的数据包传递给转发器, 可能是有利的.

某些 Link Layer (由于硬件原因, 或由于驱动程序中的特殊代码) 可以向路由器交付它 所发送的所有 Link Layer broadcast 和 multicast 的副本. 使用这一特性可以简化 以下情形的实现: 一个数据包既必须传递给转发器, 又必须本地交付; 因为转发该数据包 会自动使路由器收到该数据包的一个副本, 然后路由器可以将其本地交付. 在这些情况下 必须谨慎, 以防把收到的 loop-back 数据包当作正常收到的数据包处理 (并随后受到转发 规则等约束).

即使没有这样的 Link Layer, 当然也几乎没有必要复制整个数据包, 只为同时将其排队 等待转发和本地交付. 不过, 对于分片必须谨慎, 因为重组是在本地交付的数据包上执行, 而不是在转发的数据包上执行. 一种简单方案是为路由器输出队列中的每个数据包关联一个 标志, 表示它发送之后是否应该排队等待本地交付.

5.2.4 确定下一跳地址

当路由器要转发数据包时, 它必须确定能否直接将其发送到目标, 或者是否需要通过另一个 路由器传递. 如果是后者, 它需要确定使用哪个路由器. 本节说明如何作出这些判断.

本节使用以下定义:

o LSRR - IP Loose Source and Record Route 选项

o SSRR - IP Strict Source and Record Route 选项

o Source Route Option - LSRR 或 SSRR

o Ultimate Destination Address - 数据包要发送到的位置: 对于 source-routed packet, 是 source route 中的最后一个地址; 对于非 source-routed packet, 是 IP 头部中的目标地址

o Adjacent - 无需经过任何 IP 路由器即可到达

o Next Hop Address - 数据包下一步应发送到的相邻主机或路由器的 IP 地址

o IP Destination Address - ultimate destination address, 但在 source routed packet 中, 它是 source route 中指定的下一个地址

o Immediate Destination - 由 IP Destination Address 寻址的节点, System, 路由器, end-system 或其他对象.

5.2.4.1 IP Destination Address

如果:

o IP 头部中的目标地址是路由器的某个地址,

o 数据包包含 Source Route Option, 并且

o Source Route Option 中的 pointer 没有指过该选项末尾,

则下一个 IP Destination Address 是该选项中 pointer 所指向的地址. 如果:

o IP 头部中的目标地址是路由器的某个地址,

o 数据包包含 Source Route Option, 并且

o Source Route Option 中的 pointer 指过该选项末尾,

则该消息寻址到正在分析该消息的系统.

在确定如何处理数据包时, 路由器必须使用 IP Destination Address, 而不是 Ultimate Destination Address (source route 选项中的最后一个地址).

一个数据报中出现多个 source route 选项是错误. 如果路由器收到这样的数据报, 它应该 丢弃该数据包, 并回复 ICMP Parameter Problem 消息, 其 pointer 指向第二个 source route 选项的开头.

5.2.4.2 本地/远程决策

在已经按照 Section [5.2.3] 中指定的规则确定 IP 数据包需要转发之后, 必须使用以下 算法确定 Immediate Destination 是否可直接访问 (见 [INTERNET:2]).

(1) 对于尚未分配任何 IP 地址的每个网络接口 (Section [2.2.7] 中描述的未编号线路), 将线路另一端的 router-id 与 IP Destination Address 进行比较. 如果它们完全相等, 则可以通过此接口传输该数据包.

讨论:

换言之, 线路远端的路由器或主机是数据包的目标, 或者是 source routed packet 的 source route 中的下一步.

(2) 如果第一步未选择任何网络接口, 则对于分配给路由器的每个 IP 地址:

(a) 分离该接口使用的网络前缀.

实现:

此操作的结果通常会在初始化期间计算并保存.

(b) 从数据包的 IP Destination Address 中分离出相应的一组比特.

(c) 比较所得网络前缀. 如果它们彼此相等, 则可以通过相应的网络接口传输该数据包.

(3) 如果目标既不是未编号接口上某个邻居的 router-id, 也不是某个直连网络前缀的成员, 则 IP Destination 只能通过其他某个路由器访问. 路由器和 next hop IP address 的选择在 Section [5.2.4.3] 中描述. 对于不是路由器的主机, 这可能是已配置的 default router.

IETF 中正在进行的工作 [ARCH:9, NRHP] 考虑了某些情况, 例如多个 IP (sub)network 叠加在同一 link layer network 上. 除非受到策略限制, 使用同一 link layer network 的主机和路由器即使不在同一 IP (sub)network 中, 只要存在足够信息, 也可以直接通信. Next Hop Routing Protocol (NHRP) 使 IP 实体能够确定用于穿越此类 link layer network 前往远程目标的 "optimal" link layer address.

(4) 如果选定的 "next hop" 可通过配置为使用 NHRP 的接口到达, 则适用以下附加步骤:

(a) 将 IP Destination Address 与 NHRP cache 中的目标地址进行比较. 如果该地址
    在 cache 中, 则将数据报发送到相应缓存的 link layer address.

(b) 如果该地址不在 cache 中, 则构造一个包含 IP Destination Address 的 NHRP
    request packet. 此消息被发送到为该接口配置的 NHRP server. 这可能是路由器
    自身中的一个逻辑上独立的进程或实体.

(c) NHRP server 将以适当的 link layer address 响应, 该地址用于向同一目标传输
    该数据报以及后续数据报. 在等待 NHRP reply 期间, 系统可以将该数据报发送给
    传统的 "next hop" router.

5.2.4.3 Next Hop Address

编辑者注释:

路由器应用上一节中的算法来确定 IP Destination Address 是否相邻. 如果相邻, 则 next hop address 与 IP Destination Address 相同. 否则, 必须通过另一个路由器转发 该数据包, 以到达其 Immediate Destination. 此路由器的选择是本节主题.

如果数据包包含 SSRR, 路由器必须丢弃该数据包, 并以 ICMP Bad Source Route 错误 响应. 否则, 路由器在其路由表中查找 IP Destination Address, 以确定适当的 next hop address.

讨论:

按照 IP 规范, Strict Source Route 必须指定数据包必须经过的一系列节点; 数据包必须 从 source route 的一个节点到下一个节点, 只穿越中间网络. 因此, 如果路由器并不与 source route 的下一步相邻, 则无法满足 source route. 因而, 路由器用 ICMP Bad Source Route 错误拒绝此类数据包.

next-hop 选择过程的目标, 是检查路由器 Forwarding Information Base (FIB) 中的条目, 并从 FIB 中可用的路由里为该数据包选择最佳路由 (如果存在).

从概念上说, 任何路由查找算法都从一组候选路由开始, 该集合由 FIB 的全部内容组成. 算法由一系列步骤构成, 这些步骤从集合中丢弃路由. 这些步骤称为 Pruning Rules. 通常, 当算法终止时, 集合中恰好剩下一条路由. 如果集合在任何时候变为空, 则由于目标 不可达而丢弃该数据包. 算法也可能在集合中剩余多条路由时终止. 在这种情况下, 路由器 可以任意丢弃除其中一条以外的所有路由, 或者可以通过选择最近最少使用的路由来执行 "load-splitting".

除规则 3 (Weak TOS) 外, 路由器在为数据包选择下一跳时必须使用以下 Pruning Rules. 如果路由器在作出 next-hop 决策时确实考虑 TOS, 则规则 3 必须按下面指定的顺序应用. 这些规则必须按其呈现顺序 (概念上) 应用于 FIB. (有关一些历史视角, 附加 pruning rules 以及其他常用算法, 见 Appendix E.)

讨论:

规则 3 是可选的, 因为 Section [5.3.2] 说明路由器在作出转发决策时只应该考虑 TOS.

(1) Basic Match

 此规则丢弃目标不是数据包 IP Destination Address 的任何路由. 例如, 如果数据包
 的 IP Destination Address 是 10.144.2.5, 此步骤会丢弃到网络 128.12.0.0/16
 的路由, 但会保留到网络前缀 10.0.0.0/8 和 10.144.0.0/16 的任何路由, 以及
 任何 default route.

 更准确地说, 我们假设每条路由都有一个 destination 属性, 称为 route.dest,
 以及一个对应的 prefix length, 称为 route.length, 用于指定 route.dest 的哪些
 比特有意义. 正在转发的数据包的 IP Destination Address 称为 ip.dest. 此规则
 从候选集合中丢弃所有路由, 只保留满足以下条件的路由: route.dest 与 ip.dest 的
 最高有效 route.length 个比特相等.

 例如, 如果数据包的 IP Destination Address 是 10.144.2.5, 并且存在网络前缀
 10.144.1.0/24, 10.144.2.0/24 和 10.144.3.0/24, 此规则只会保留
 10.144.2.0/24; 它是唯一一条其前缀与该数据包 IP Destination Address 中相应
 比特具有相同值的路由.

(2) Longest Match

 Longest Match 是上面描述的 Basic Match 的细化. 在执行 Basic Match 剪枝后,
 算法检查剩余路由, 以确定其中哪些路由具有最大的 route.length 值. 除这些路由
 外的所有路由都被丢弃.

 例如, 如果数据包的 IP Destination Address 是 10.144.2.5, 并且存在网络前缀
 10.144.2.0/24, 10.144.0.0/16 和 10.0.0.0/8, 则此规则只会保留第一条
 (10.144.2.0/24), 因为它的前缀长度最长.

(3) Weak TOS

 每条路由都有一个 type of service 属性, 称为 route.tos, 其可能值假定与 IP
 头部 TOS 字段中使用的值相同. 分发 TOS 信息的路由协议会在它们添加到 FIB 的
 路由中适当地填入 route.tos; 来自其他路由协议的路由被视为具有 default TOS
 (0000). 正在路由的数据包 IP 头部中的 TOS 字段称为 ip.tos.

 检查候选路由集合, 以确定其中是否包含 route.tos = ip.tos 的任何路由. 如果有,
 则丢弃除 route.tos = ip.tos 的路由之外的所有路由. 如果没有, 则从候选路由集合
 中丢弃除 route.tos = 0000 的路由之外的所有路由.

 关于基于 Weak TOS 的路由的更多讨论见 [ROUTE:11].

讨论:

此规则的效果是只选择 TOS 与数据包中请求的 TOS 匹配的路由. 如果不存在这样的路由, 则考虑具有 default TOS 的路由. TOS 非默认且不是数据包中请求 TOS 的路由从不使用, 即使这些路由是通往数据包目标的唯一可用路由.

(4) Best Metric

 每条路由都有一个 metric 属性, 称为 route.metric, 以及一个 routing domain
 identifier, 称为 route.domain. 候选路由集合中的每个成员都与该集合中的每个
 其他成员比较. 如果两条路由的 route.domain 相等, 并且与另一条路由相比其中一条
 的 route.metric 严格较差, 则具有较差 metric 的那条路由从集合中被丢弃.
 较差的判定通常通过简单的算术比较完成, 尽管某些协议可能具有结构化 metric,
 需要更复杂的比较.

(5) Vendor Policy

 Vendor Policy 有点像兜底规则, 用于弥补前述规则通常不足以从可能路由中作出
 选择这一事实. Vendor Policy pruning rules 极其依赖厂商. 见 Section [5.2.4.4].

此算法有两个明显缺点. 可以推测, 路由器实现者可能会开发技术来处理这些缺点, 并将 这些技术作为 Vendor Policy pruning rule 的一部分.

(1) IS-IS 和 OSPF route classes 没有被直接处理.

(2) type of service 以外的路径属性 (例如 MTU) 被忽略.

还值得注意的是 TOS 支持方式中的一个缺陷: 在转发具有非零 TOS 值的数据包时, 支持 TOS 的路由协议会被隐式优先选用.

Basic Match 和 Longest Match pruning rules 概括了若干特定类型路由的处理方式. 这些路由按以下递减的优先顺序选择:

(1) Host Route: 这是到某个特定 end system 的路由.

(2) Hierarchical Network Prefix Routes: 这是到某个特定网络前缀的路由. 请注意, FIB 可能包含若干条彼此包含的网络前缀路由 (一个前缀是另一个前缀再加上额外 比特). 这些路由按前缀长度递减的顺序选择.

(5) Default Route: 这是到所有没有显式路由的网络的路由. 根据定义, 它是前缀长度 为零的路由.

如果在应用 pruning rules 后, 路由集合为空 (即未找到任何路由), 则必须丢弃该数据包, 并生成适当的 ICMP error (如果 IP Destination Address 来自 source route option, 则为 ICMP Bad Source Route; 否则, 按 Section [4.3.3.1] 所述, 生成 ICMP Destination Host Unreachable 或 Destination Network Unreachable 中适当的一个).

5.2.4.4 Administrative Preference

Vendor Policy Pruning Rule 的一种建议机制是使用 administrative preference, 这是一种 简单的优先级算法. 其思想是对可能需要从中选择的路由手工设置优先级.

每条路由都关联一个 preference value, 该值基于该路由的各种属性 (下面建议了分配 preference value 的具体机制). 此 preference value 是范围 [0..255] 内的整数, 其中 0 表示最优先, 254 表示最不优先. 255 是一个特殊值, 表示该路由永远不应被使用. Vendor Policy pruning rule 的第一步会丢弃除最优先路由之外的所有路由 (并且总是 丢弃 preference value 为 255 的路由).

这种策略并不安全, 因为它很容易被误用而造成 routing loops. 由于没有协议能确保为 某个路由器配置的 preferences 与其邻居中配置的 preferences 一致, 网络管理员在配置 preferences 时必须谨慎.

o Address Match

能够为到指定目标集合中任一目标的所有路由 (从同一 routing domain 学习到的路由) 分配单一 preference value 是有用的, 其中该目标集合是所有匹配指定网络前缀的目标.

o Route Class

对于保持这种区分的路由协议, 能够为具有特定 route class 的所有路由 (从同一 routing domain 学习到的路由) 分配单一 preference value 是有用的, 这些类别包括 intra-area, inter-area, external with internal metrics, 或 external with external metrics.

o Interface

能够为所有会使数据包经由路由器上某个特定逻辑接口转发出去的路由 (从特定 routing domain 学习到的路由) 分配单一 preference value 是有用的 (逻辑接口通常 与路由器的网络接口一一映射, 但任何具有多个 IP 地址的网络接口都会关联多个逻辑 接口).

o Source router

能够为从一组路由器中的任一路由器学习到的所有路由 (从同一 routing domain 学习到 的路由) 分配单一 preference value 是有用的, 其中这组路由器是其更新报文的源地址 匹配指定网络前缀的路由器.

o Originating AS

对于提供该信息的路由协议, 能够为起源于另一个特定 routing domain 的所有路由 (从特定 routing domain 学习到的路由) 分配单一 preference value 是有用的. 对于 BGP routes, originating AS 是该路由 AS_PATH 属性中列出的第一个 AS. 对于 OSPF external routes, 如果 tag 的 Automatic bit 已设置且 tag 的 Path Length 不等于 3, 则 originating AS 可以认为是该路由 external route tag 的低 16 位.

o External route tag

能够为 external route tags 匹配指定值列表中任一值的所有 OSPF external routes (从同一 routing domain 学习到的路由) 分配单一 preference value 是有用的. 由于 external route tag 可能包含结构化值, 提供匹配该 tag 中特定子字段的能力可能会有用.

o AS path

能够为 AS path "matches" 一组指定值中任一值的所有 BGP routes (从同一 routing domain 学习到的路由) 分配单一 preference value 可能是有用的. 目前尚不清楚究竟 哪些匹配类型最有用. 一个简单选项是允许匹配所有在路由 AS_PATH 属性任意位置出现 (或者反过来, 不出现) 某个特定 AS number 的路由. 一个更通用但略微更困难的替代 方案是允许匹配所有 AS path 匹配指定 regular expression 的路由.

5.2.4.5 Load Splitting

在 Next-hop 选择过程结束时, 仍可能保留多条路由. 当这种情况发生时, 路由器有若干 选择. 它可以任意丢弃其中一些路由. 它可以通过比较来自不被认为等价的 routing domains 的路由 metric, 来减少候选路由的数量. 它可以保留多于一条路由, 并采用 load-splitting 机制在这些路由之间分配流量. 关于这些选项相对优劣, 或许唯一可以说 的是, load-splitting 在某些情况下有用, 在另一些情况下无用. 因此, 实现 load-splitting 的明智实现者也会提供一种方式, 让网络管理员能够禁用它.

5.2.5 未使用的 IP 头部比特: RFC-791 Section 3.1

IP 头部在 Type of Service 字段和 Flags 字段中包含若干 reserved bits. 路由器不得 仅因为这些 reserved bits 中的一个或多个具有非零值而丢弃数据包.

路由器必须忽略这些 reserved bits 的值, 并且必须不加修改地透传这些值. 如果路由器 对数据包进行分片, 则必须将这些 bits 复制到每个分片中.

讨论:

未来对 IP 协议的修订可能会使用这些未使用的 bits. 这些规则旨在确保此类修订可以 部署, 而无需同时升级 Internet 中的所有路由器.

5.2.6 分片与重组: RFC-791 Section 3.2

如 Section [4.2.2.7] 中所讨论, 路由器必须支持 IP fragmentation.

路由器不得在转发任何数据报之前重组该数据报.

讨论:

有少数人曾提出, 在某些拓扑中, 由路由器重组过境数据报可能会提升性能. 但分片可能 沿不同路径到达目标这一事实, 排除了安全使用此类功能的可能性.

本节中的任何内容都不应被解释为控制或限制路由器作为 link layer 功能执行的 fragmentation 或 reassembly.

类似地, 如果一个 IP 数据报被封装在另一个 IP 数据报中 (例如, 它被 tunnelled), 并且该外层数据报又被分片, 则必须重组这些分片才能转发原始数据报. 本节并不排除 这种情况.

5.2.7 Internet Control Message Protocol - ICMP

ICMP 的一般要求已在 Section [4.3] 中讨论. 本节讨论仅由路由器发送的 ICMP 消息.

5.2.7.1 Destination Unreachable

ICMP Destination Unreachable 消息由路由器发送, 用于响应其无法转发的数据包, 原因是 目标 (或 next hop) 不可达, 或某项服务不可用. 此类情况的示例包括: 发往某个不存在 因而不响应 ARP 请求的主机的消息, 以及发往路由器没有有效路由的网络前缀的消息.

路由器必须能够生成 ICMP Destination Unreachable 消息, 并且应该选择与生成该消息 原因最接近的 response code.

[INTERNET:8] 和 [INTRO:2] 中定义了以下代码:

0 = Network Unreachable - 如果到目标网络的 forwarding path (route) 不可用, 则由 路由器生成;

1 = Host Unreachable - 如果到直接连接网络上目标主机的 forwarding path (route) 不可用 (不响应 ARP), 则由路由器生成;

2 = Protocol Unreachable - 如果数据报中指定的 transport protocol 在最终目标的 transport layer 不受支持, 则生成;

3 = Port Unreachable - 如果指定的 transport protocol (例如 UDP) 无法在最终目标的 transport layer 对该数据报进行 demultiplex, 且没有协议机制可通知发送方, 则生成;

4 = Fragmentation Needed and DF Set - 如果路由器需要对数据报进行分片, 但由于 DF flag 已设置而无法分片, 则生成;

5 = Source Route Failed - 如果路由器无法将数据包转发到 source route option 中的 next hop, 则生成;

6 = Destination Network Unknown - 不应该生成此代码, 因为它会暗示路由器认为目标 网络不存在 (应该使用 net unreachable code 0 代替 code 6);

7 = Destination Host Unknown - 仅当路由器能够 (根据 link layer advice) 确定目标 主机不存在时生成;

11 = Network Unreachable For Type Of Service - 如果到目标网络且满足 requested 或 default TOS 的 forwarding path (route) 不可用, 则由路由器生成;

12 = Host Unreachable For Type Of Service - 如果路由器无法转发数据包, 因为其到目标 的 route(s) 既不匹配数据报请求的 TOS, 也不匹配 default TOS (0), 则生成.

现定义以下附加代码:

13 = Communication Administratively Prohibited - 当路由器由于 administrative filtering 而无法转发数据包时生成;

14 = Host Precedence Violation. 由 first hop router 发送给主机, 用于指示对于特定的 source/destination host 或 network, upper layer protocol, 以及 source/destination port 组合, 所请求的 precedence 不被允许;

15 = Precedence cutoff in effect. 网络运营者已施加运行所需的最低 precedence 级别, 而该数据报使用低于此级别的 precedence 发送;

NOTE: [INTRO:2] 为 source host isolated 定义了 Code 8. 路由器不应该生成 Code 8; 应该改用 Codes 0 (Network Unreachable) 和 1 (Host Unreachable) 中适用的一个. [INTRO:2] 还为 communication with destination network administratively prohibited 定义了 Code 9, 并为 communication with destination host administratively prohibited 定义了 Code 10. 这些代码原本 intended 用于美国军事机构使用的 end-to-end encryption devices. 如果路由器以管理方式过滤数据包, 则应该使用新定义的 Code 13 (Communication Administratively Prohibited).

路由器可以具有一个配置选项, 用于使 Code 13 (Communication Administratively Prohibited) 消息不被生成. 启用该选项时, 对于因其转发被 administratively prohibited 而被丢弃的数据包, 不发送 ICMP error message.

类似地, 路由器可以具有一个配置选项, 用于使 Code 14 (Host Precedence Violation) 和 Code 15 (Precedence Cutoff in Effect) 消息不被生成. 启用该选项时, 对于因 precedence violation 而被丢弃的数据包, 不发送 ICMP error message.

只要同一目标网络上的其他主机可能可达, 路由器就必须使用 Host Unreachable 或 Destination Host Unknown 代码; 否则, 源主机可能错误地断定该网络上的所有主机都 不可达, 而事实可能并非如此.

[INTERNET:14] 描述了包含 Code 4 (Fragmentation needed and DF set) 的 Destination Unreachable 消息形式的一个小修改. 路由器在发起 Code 4 Destination Unreachable 消息时, 必须使用这种修改后的形式.

5.2.7.2 Redirect

ICMP Redirect 消息用于通知本地主机, 对某一类流量应该使用不同的 next hop router.

路由器不得生成 [INTERNET:8] 中规定的 Redirect for Network 或 Redirect for Network and Type of Service 消息 (Codes 0 和 2). 路由器必须能够生成 [INTERNET:8] 中规定的 Redirect for Host 消息 (Code 1), 并且应该能够生成 Redirect for Type of Service and Host 消息 (Code 3).

讨论:

如果直连网络没有被划分子网 (按传统意义), 路由器通常可以生成一个 network Redirect, 适用于指定远程网络上的所有主机. 使用 network Redirect 而不是 host Redirect, 可能 会稍微节省网络流量和主机路由表存储. 然而, 这种节省并不显著, 而子网会造成一个关于 应使用哪一个 subnet mask 来解释 network Redirect 的歧义. 在 CIDR 环境中, 很难精确 说明哪些情况下可以使用 network Redirects. 因此, 路由器必须只发送 host Redirects (或 host and type of service Redirects).

当触发 redirect 的数据包具有一个目标, 且路由器选择的路径会 (部分地) 取决于所请求 的 TOS 时, 生成 Code 3 (Redirect for Host and Type of Service) 消息.

能够生成 Code 3 redirects (Host and Type of Service) 的路由器, 必须具有一个配置选项 (默认开启), 以允许用 Code 1 (Host) redirects 替代 Code 3 redirects. 如果路由器已被 配置为这样做, 则必须发送 Code 1 Redirect 来代替 Code 3 Redirect.

如果路由器不能生成 Code 3 Redirects, 则在需要 Code 3 Redirect 的情况下, 它必须生成 Code 1 Redirects.

除非满足以下所有条件, 否则路由器不得生成 Redirect Message:

o 该数据包正从接收它的同一物理接口转发出去,

o 数据包中的 IP source address 与 next-hop IP address 位于同一 Logical IP (sub)network 上, 并且

o 该数据包不包含 IP source route option.

ICMP Redirect 中使用的 source address 必须属于与 destination address 相同的 logical (sub)net.

使用 routing protocol (static routes 除外) 的路由器, 在转发数据包时不得考虑从 ICMP Redirects 学到的路径. 如果路由器没有使用 routing protocol, 则路由器可以具有 一个配置项, 在设置后允许该路由器在转发数据包时考虑通过 ICMP Redirects 学到的路由.

讨论:

ICMP Redirect 是路由器向主机传递路由信息的一种机制. 路由器使用其他机制学习路由 信息, 因此没有理由遵从 redirects. 相信一个与路由器其他信息相矛盾的 redirect, 很可能会造成 routing loops.

另一方面, 当路由器不作为路由器运行时, 它必须遵守主机所要求的行为.

5.2.7.3 Time Exceeded

当路由器由于 TTL field 过期而丢弃数据包时, 必须生成 Code 0 (In Transit) 的 Time Exceeded 消息. 路由器可以具有一个按接口配置的选项, 用于禁止在该接口上发起这些 消息, 但该选项必须默认允许发起这些消息.

5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP

IGMP [INTERNET:4] 是一种在单个物理网络上的主机与 multicast routers 之间使用的协议, 用于建立主机在特定 multicast groups 中的成员关系. Multicast routers 将该信息与 multicast routing protocol 结合使用, 以支持跨 Internet 的 IP multicast forwarding.

路由器应该实现 IGMP 的 multicast router 部分.

5.3 具体问题

5.3.1 Time to Live (TTL)

IP header 的 Time-to-Live (TTL) 字段被定义为限制数据报生命周期的 timer. 它是一个 8-bit 字段, 单位为秒. 每个处理数据包的路由器 (或其他模块) 都必须将 TTL 至少减 1, 即使经过的时间远小于 1 秒. 由于这种情况非常常见, TTL 实际上成为数据报能够在 Internet 中传播多远的 hop count limit.

当路由器转发数据包时, 必须将 TTL 至少减 1. 如果它持有一个数据包超过 1 秒, 则可以 按每秒 1 的幅度递减 TTL.

如果 TTL 被减至 0 (或更小), 则必须丢弃该数据包; 并且如果目标不是 multicast address, 路由器必须向源发送 ICMP Time Exceeded 消息, Code 0 (TTL Exceeded in Transit). 请注意, 对于具有非零 TTL 的 IP unicast 或 broadcast 数据包, 路由器不得仅仅因为它 能够预测通往该数据包最终目标路径上的另一个路由器会将 TTL 递减至 0 而丢弃该数据包. 然而, 对于 IP multicast, 路由器可以这样做, 以便更高效地实现 IP multicast 的 expanding ring search algorithm (见 [INTERNET:4]).

讨论:

IP TTL 有些分裂地同时被用作 hop count limit 和 time limit. 它的 hop count 功能对于 确保路由问题不会通过导致数据包在网络中无限循环而使网络崩溃至关重要. time limit 功能由 TCP 等 transport protocols 使用, 以确保可靠的数据传输. 许多当前实现将 TTL 视为纯粹的 hop count, 并且在 Internet 社区的一些部分中, 有一种强烈看法认为 time limit 功能应该改由需要它的 transport protocols 执行.

在本规范中, 我们勉强决定遵循路由器厂商中的强烈观点, 即 time limit 功能应该是可选的. 他们认为, 实现 time limit 功能足够困难, 以致目前通常并未实现. 他们还指出, 没有已 记录的案例表明这种简化做法导致 TCP 损坏数据 (当然, 我们预期由此产生的问题会很少见 且难以复现, 因此缺少已记录案例并不能令人安心地证明不存在若干未记录案例).

除非 TTL 被视为纯粹的 hop count, 否则 IP multicast 中诸如 expanding ring search 这样的概念可能无法按预期工作. traceroute 在某种程度上也是如此.

ICMP Time Exceeded 消息是必需的, 因为 traceroute diagnostic tool 依赖它们.

因此, 这里的权衡是在严重削弱甚至消除两个非常有用的工具, 与避免一个非常罕见且短暂, 甚至可能根本不会发生的数据传输问题之间进行取舍. 我们选择保留这些工具.

5.3.2 Type of Service (TOS)

IP 头部中的 Type-of-Service byte 被划分为三个部分: Precedence 字段 (高阶 3 bits), 通常称为 Type of Service 或 TOS 的字段 (接下来的 4 bits), 以及一个 reserved bit (低阶 bit). 管理 reserved bit 的规则已在 Section [4.2.2.3] 中描述. Precedence 字段 将在 Section [5.3.3] 中讨论. 关于 TOS 字段及其使用的更详细讨论可参见 [ROUTE:11].

路由器在决定如何转发数据包时, 应该考虑数据包 IP 头部中的 TOS 字段. 本节其余部分 描述适用于符合此要求的路由器的规则.

路由器必须为其 routing table 中的每条路由维护一个 TOS 值. 通过不支持 TOS 的 routing protocol 学习到的路由必须被赋予 TOS 值 zero (default TOS).

为选择到某个目标的路由, 路由器必须使用等价于以下过程的算法:

(1) 路由器在其 routing table 中定位到该目标的所有可用路由 (见 Section [5.2.4]).

(2) 如果没有可用路由, 路由器丢弃该数据包, 因为目标不可达. 见 Section [5.2.4].

(3) 如果这些路由中有一条或多条路由的 TOS 与数据包中指定的 TOS 完全匹配, 路由器选择 metric 最佳的路由.

(4) 否则, 路由器重复上述步骤, 但只查看 TOS 为 zero 的路由.

(5) 如果上述过程未选择出路由, 路由器丢弃该数据包, 因为目标不可达. 路由器返回一个 ICMP Destination Unreachable 错误, 并指定适当的 code: Network Unreachable with Type of Service (code 11) 或 Host Unreachable with Type of Service (code 12).

讨论:

尽管过去 TOS 很少被使用, 但 Requirements for Internet Hosts RFCs ([INTRO:2] 和 [INTRO:3]) 现在已要求主机使用它. 路由器对 TOS 的支持将来可能成为必须项, 但目前在 获得更多使用经验, 并能更好判断其收益与成本之前, 它仍是应该项.

已有不同人士提出, TOS 应该影响 forwarding function 的其他方面. 例如:

(1) 路由器可以将设置了 Low Delay bit 的数据包放在其输出队列中其他数据包之前.

(2) 当路由器被迫丢弃数据包时, 它可以尝试避免丢弃设置了 High Reliability bit 的 数据包.

这些想法已在 [INTERNET:17] 中作了更详细的探讨, 但我们目前对这些方案还没有足够经验, 无法在此领域制定要求.

5.3.3 IP Precedence

本节规定路由器中对 IP Precedence 字段进行适当处理的要求和指南. Precedence 是一种 根据不同 traffic flows 的相对重要性在网络中分配资源的方案. IP 规范为此字段定义了 用于各种流量类型的具体值.

路由器中进行 precedence 处理的基本机制是优先资源分配, 包括 precedence-ordered queue service 和 precedence-based congestion control, 以及 Link Layer priority features 的选择. 路由器还会为其自身发起的 routing, management 和 control traffic 选择 IP precedence. 关于 IP Precedence 及其实现的更详细讨论, 见 [FORWARD:6].

本节所讨论的 precedence-ordered queue service 包括但不限于 forwarding process 的 队列以及 outgoing links 的队列. 预期支持 precedence 的路由器还应在其处理中涉及有限 资源分配的任何点使用 precedence indication, 例如 packet buffers 或 Link Layer connections. 这些点的集合取决于具体实现.

讨论:

虽然 Precedence 字段最初是为 DOD 系统使用而提供的, 在这些系统中, 大规模流量激增或 网络遭受严重损坏被视为固有威胁, 但它对许多非军事 IP 网络也有有用的应用. 尽管近年来 网络的流量处理能力已大幅增长, 用户产生流量的能力也同样增长, 网络过载条件仍会不时 发生. 随着基于 IP 的 routing 和 management protocols 对 Internet 成功运行变得更加 关键, 过载会给网络带来两个额外风险:

(1) 高延迟可能导致 routing protocol 数据包丢失. 这可能使 routing protocol 错误地 推断出拓扑变化, 并将这种错误信息传播给其他路由器. 这不仅可能导致路由振荡, 还 可能给其他路由器带来额外处理负担.

(2) 高延迟可能干扰 network management tools 的使用, 使其难以分析并可能纠正或缓解 网络中导致过载条件发生的问题.

Precedence 机制的实现和适当使用可以缓解这两个问题.

5.3.3.1 Precedence-Ordered Queue Service

路由器应该实现 precedence-ordered queue service. Precedence-ordered queue service 是指, 当为某条 (logical) link 选择一个数据包输出时, 发送该链路队列中 precedence 最高的数据包. 实现 precedence-ordered queue service 的路由器还必须具有一个配置选项, 用于在 Internet Layer 中抑制 precedence-ordered queue service.

任何路由器可以实现其他基于策略的 throughput management procedures, 这些过程可能产生 并非严格 precedence ordering 的结果, 但它必须可以配置为抑制这些过程 (即使用严格排序).

如 Section [5.3.6] 中所详述, 实现 precedence-ordered queue service 的路由器, 为了 congestion control 目的, 会先丢弃低 precedence 数据包, 再丢弃高 precedence 数据包.

Preemption (中断某个数据包的处理或传输) 不被设想为 Internet Layer 的功能. 其他层的 某些协议可以提供 preemption 功能.

5.3.3.2 Lower Layer Precedence Mappings

实现 precedence-ordered queuing 的路由器必须实现 Lower Layer Precedence Mapping, 其他路由器应该实现 Lower Layer Precedence Mapping.

实现 Lower Layer Precedence Mapping 的路由器:

o 必须能够将 IP Precedence 映射到 Link Layer priority mechanisms, 对于定义了此类 功能的 link layers 适用.

o 必须具有一个配置选项, 用于为所有 IP 流量选择 Link Layer 的 default priority treatment.

o 应该能够为每个接口配置 IP precedence values 到 Link Layer priority values 的特定 nonstandard mappings.

讨论:

有些研究质疑某些 Link Layer 协议的 priority features 是否可行, 并且某些网络可能存在 link layer priority mechanism 的错误实现. 如果这些问题在网络中出现, 提供一种退出 机制似乎是谨慎的做法.

另一方面, 已有人提出使用新的 queuing strategies 来实现 special services, 例如 multimedia bandwidth reservation 或 low-delay service. Special services 以及支持 这些服务的 queuing strategies 是当前研究主题, 并且正处于标准化过程中.

实现者可以考虑这样一点: 对用于 DOD 网络的 TCP/IP 系统, DOD 策略要求正确执行 IP precedence 到 link layer 的映射. 由于这些要求旨在鼓励 (但不强制) 使用 precedence 功能, 希望由此为所有用户提供更好的 Internet service, 因此支持 precedence-ordered queue service 的路由器应默认维持严格 precedence ordering, 而不论所请求的 type of service 为何.

5.3.3.3 所有路由器的 Precedence 处理

路由器 (无论是否采用 precedence-ordered queue service):

(1) 必须正常接受并处理所有 precedence 级别的入站流量, 除非它已被管理配置为其他行为.

(2) 可以实现一个 validation filter, 以管理方式限制特定流量源对 precedence 级别的 使用. 如果提供该 filter, 它不得过滤掉或切断以下类型的 ICMP error messages: Destination Unreachable, Redirect, Time Exceeded, and Parameter Problem. 如果提供 该 filter, 则按地址进行 packet filtering 所要求的过程也适用于此 filter.

讨论:

Precedence filtering 应该适用于特定的 source/destination IP Address 对, 特定协议, 特定端口等.

当 validation filter 丢弃数据包时, 应该发送 code 14 的 ICMP Destination Unreachable 消息, 除非配置选择已抑制此行为.

(3) 可以实现 cutoff function, 允许将路由器设置为拒绝或丢弃低于指定级别的 precedence 流量. 此功能可以由管理动作激活, 也可以由某些依赖实现的启发式机制 激活, 但对于任何无需人工干预即可运行的启发式机制, 必须有一个配置选项可禁用它. 当 cutoff function 丢弃数据包时, 应该发送 code 15 的 ICMP Destination Unreachable 消息, 除非配置选择已抑制此行为.

 路由器不得仅因 precedence cutoff 而拒绝转发 IP precedence 为 6 (Internetwork
 Control) 或 7 (Network Control) 的数据报. 但是, 可以将其他条件与 precedence
 cutoff 结合使用, 以过滤高 precedence 流量.

讨论:

不受限制的 precedence cutoff 可能导致 routing 和 control traffic 被无意 cutoff. 在一般情况下, host traffic 应限制为 5 (CRITIC/ECP) 或更低的值; 这不是一项要求, 并且在某些系统中可能并不正确.

(4) 不得更改并非由自身发起的数据包上的 precedence settings.

(5) 应该能够为所支持的每个 routing 或 management protocol 配置不同的 precedence values (但 OSPF 等指定了必须使用哪个 precedence value 的协议除外).

(6) 可以能够为每个 peer address 独立配置 routing 或 management traffic precedence values.

(7) 对于 Link Layer 提供的 precedence-related error indications, 必须适当地响应. 当数据包因链路由于 precedence-related condition 而无法接受它而被丢弃时, 应该 发送 code 15 的 ICMP Destination Unreachable 消息, 除非配置选择已抑制此行为.

讨论:

(3) 中描述的 precedence cutoff 机制有一定争议. 根据受 cutoff 影响区域的拓扑位置, transit traffic 可能被 routing protocols 导入 cutoff 区域, 并在那里被丢弃. 只有在 通信点之间存在另一条不受 cutoff 影响的路径时, 这才是问题. 避免此问题的建议方法包括: 即使在过载条件下也为所有 precedence 级别提供某种最低带宽, 或者在 routing protocols 中传播 cutoff 信息. 在缺乏被广泛接受 (并实现) 的解决方案时, 推荐在 transit networks 中激活 cutoff mechanisms 时保持高度谨慎.

transport layer relay 可以合法地提供上面 (4) 所禁止的功能. 更改 precedence levels 可能与 TCP 以及其他协议产生微妙交互; 正确设计并非易事.

(5) 和 (6) 的意图 (以及 Section [4.3.2] 中关于 ICMP messages 中 IP Precedence 的 讨论) 是, 无论该路由器是否以其他方式对这些 bits 采取动作, IP precedence bits 都应 被适当地设置. 我们预期未来 routing protocols 和 network management protocols 的规范 将指定这些协议发送的 messages 应如何设置 IP Precedence.

对于 (7), 适当响应取决于正在使用的 link layer protocol. 通常, 路由器应该在一段时间 内停止尝试向该目标发送违规流量, 并且应该向流量源返回 code 15 (service not available for precedence requested) 的 ICMP Destination Unreachable 消息. 它也不应该在一段时间 内尝试重新建立被 preempted 的 Link Layer connection.

5.3.4 Link Layer Broadcasts 的转发

在大多数 Link Layer protocols (PPP 除外) 中对 IP packets 的封装, 允许接收方仅通过 检查 Link Layer protocol headers (最常见的是 Link Layer destination address) 来区分 broadcasts, multicasts 和 unicasts. 本节中涉及 Link Layer broadcasts 的规则仅适用于 允许区分 broadcasts 的 Link Layer protocols; 同样, 涉及 Link Layer multicasts 的规则 仅适用于允许区分 multicasts 的 Link Layer protocols.

路由器不得转发任何作为 Link Layer broadcast 收到的数据包, 除非它指向 IP Multicast address. 在后一种情况下, 可以推定由于缺乏有效的 multicast service, 才使用 link layer broadcast.

路由器不得转发任何作为 Link Layer multicast 收到的数据包, 除非该数据包的 destination address 是 IP multicast address.

路由器应该静默丢弃通过 Link Layer broadcast 收到但未指定 IP multicast 或 IP broadcast destination address 的数据包.

当路由器以 Link Layer broadcast 发送数据包时, IP destination address 必须是合法的 IP broadcast 或 IP multicast address.

5.3.5 Internet Layer Broadcasts 的转发

IP broadcast addresses 有两种主要类型: limited broadcast 和 directed broadcast. 此外, directed broadcast 有三种子类型: 指向指定 network prefix 的 broadcast, 指向 指定 subnetwork 的 broadcast, 以及指向指定 network 的所有 subnets 的 broadcast. 路由器将某个 broadcast 归类为这些类别之一, 取决于 broadcast address 以及路由器对 目标网络 subnet 结构的理解 (如果有). 同一个 broadcast 会被不同路由器不同地归类.

limited IP broadcast address 定义为全一: { -1, -1 } 或 255.255.255.255.

network-prefix-directed broadcast 由 IP address 的 network prefix 和全一的 local part 组成, 即 { , -1 }. 例如, Class A net broadcast address 是 net.255.255.255, Class B net broadcast address 是 net.net.255.255, Class C net broadcast address 是 net.net.net.255, 其中 net 是 network address 的一个 byte.

all-subnets-directed-broadcast 在 CIDR 环境中没有良好定义, 并已在本备忘录 version 1 中废弃.

如 Section [4.2.3.1] 中所述, 路由器可能遇到某些非标准 IP broadcast addresses:

o 0.0.0.0 是 limited broadcast address 的过时形式

o { , 0 } 是 network-prefix-directed broadcast address 的过时形式.

如该节所述, 寻址到这些地址中任何一个的数据包应该被静默丢弃; 但如果没有丢弃, 则必须 按照适用于上述非过时 broadcast address 形式的数据包的相同规则处理. 这些规则在接下来的 几个小节中描述.

5.3.5.1 Limited Broadcasts

Limited broadcasts 不得被转发. Limited broadcasts 不得被丢弃. 在 limited broadcasts 足够的地方, 可以发送 limited broadcasts, 并且应该发送 limited broadcasts 而不是 directed broadcasts.

讨论:

某些路由器包含 UDP servers, 其功能是将请求 (作为 unicasts 或 directed broadcasts) 重新发送给其他 servers. 不应将此要求解释为禁止此类 servers. 但是请注意, 如果配置错误, 此类 servers 很容易导致 packet looping. 因此, 此类 servers 的提供者很可能应仔细记录 其设置, 并仔细考虑所发送数据包的 TTL.

5.3.5.2 Directed Broadcasts

路由器必须把所有发往远程网络或所连接非子网化网络的有效 directed broadcasts 归类为 network-prefix-directed broadcasts. 请注意, 鉴于 CIDR, 这类地址看起来像 network prefix 内的 host addresses; 我们排除了检查此类 network prefixes 的 host part. 因此, 在给定 一条路由且没有覆盖性策略的情况下, 路由器必须转发 network-prefix-directed broadcasts. Network-Prefix-Directed broadcasts 可以被发送.

路由器可以具有一个选项, 用于禁止在某个接口上接收 network-prefix-directed broadcasts, 并且必须具有一个选项, 用于禁止转发 network-prefix-directed broadcasts. 这些选项必须 默认允许接收和转发 network-prefix-directed broadcasts.

讨论:

关于是否转发 directed broadcasts 曾有一些争论. 在本备忘录中, 我们让转发决策取决于 路由器对目标 network prefix 的了解. 除了这种了解之外, 路由器无法确定一条消息是 unicast 还是 directed broadcast. 根据定义, 是否转发该消息的决策只有在最后一跳路由器 上才可能作出.

5.3.5.3 All-subnets-directed Broadcasts

本备忘录第一版描述了一种算法, 用于把 directed broadcast 分发到某个传统 network number 的所有 subnets. 该算法被声明为 "broken", 并指定了若干失败情形.

在 CIDR routing domain 中, 传统 IP network numbers 没有意义, 因而 all-subnets-directed-broadcast 的概念也没有意义. 据工作组所知, 该设施从未实现或部署, 现在已被归入历史尘埃.

5.3.5.4 Subnet-directed Broadcasts

本备忘录第一版详细说明了处理 subnet-directed-broadcasts 的过程. 在 CIDR routing domain 中, 这些广播与 net-directed-broadcasts 无法区分. 因此, 二者在 Section [5.3.5.2 Directed Broadcasts] 中一并处理, 并应被视为 network-prefix directed broadcasts.

5.3.6 Congestion Control

网络中的 congestion 可粗略定义为对资源 (通常是带宽或 CPU time) 的需求超过容量的状态. Congestion avoidance 试图防止需求超过容量, 而 congestion recovery 试图恢复可运行状态. 路由器可能对这两种机制都有贡献. 人们已经投入大量精力研究这一问题. 建议读者阅读 [FORWARD:2] 以了解相关工作的综述. 关于该主题的重要论文包括 [FORWARD:3], [FORWARD:4], [FORWARD:5], [FORWARD:10], [FORWARD:11], [FORWARD:12], [FORWARD:13], [FORWARD:14] 和 [INTERNET:10] 等.

当主机使用合理的 congestion policies (例如 [FORWARD:5] 中描述的策略) 时, 路由器为处理 峰值瞬时需求而应具备的存储量, 是使用该链路的 flows 的链路带宽与路径延迟乘积的函数; 因此, 随着 Bandwidth*Delay product 增大, 存储也应增加. 存储容量与丢弃概率之间的精确 函数尚不清楚.

当路由器收到的数据包超出其存储容量时, 它必须 (按定义, 而非按命令) 丢弃该数据包或其他 一个或多个数据包. 应丢弃哪个数据包是大量研究的主题, 但遗憾的是, 迄今共识很少. 目前 最好的认识建议从最重度使用该链路的数据流中丢弃一个数据包. 但是, 许多其他因素可能相关, 包括流量的 precedence, active bandwidth reservation, 以及选择该数据包所涉及的复杂性.

路由器可以丢弃它刚刚收到的数据包; 这是最简单但不是最佳的策略. 理想情况下, 在适用的 Quality of Service policy 允许的情况下, 路由器应该从最严重滥用该链路的 sessions 之一 中选择一个数据包. 在使用 FIFO queues 的 datagram environments 中, 推荐策略是从队列中 随机选择一个数据包丢弃 (见 [FORWARD:5]). 在使用 fair queues 的路由器中, 等效算法是 从最长队列或使用最大 virtual time 的队列中丢弃 (见 [FORWARD:13]). 路由器可以使用这些 算法来确定应丢弃哪个数据包.

如果路由器实现一种 discard policy (例如 Random Drop), 即从 eligible packets 的池中 选择一个数据包丢弃:

o 如果已实现并启用 precedence-ordered queue service (Section [5.3.3.1] 中描述), 路由器不得丢弃 IP precedence 高于某个未被丢弃数据包的 IP precedence 的数据包.

o 路由器可以保护其 IP headers 请求 maximize reliability TOS 的数据包, 除非这样做会 违反上一条规则.

o 路由器可以保护 fragmented IP packets, 其理论依据是丢弃某个数据报的一个分片可能会 通过导致源重传该数据报的所有分片而增加 congestion.

o 为帮助防止 routing perturbations 或 management functions 被中断, 路由器可以保护用于 routing control, link control 或 network management 的数据包不被丢弃. 专用路由器 (即不同时作为 general purpose hosts, terminal servers 等的路由器) 可以通过保护其源 或目标为路由器自身的数据包来近似实现此规则.

高级 congestion control 方法包含 fairness 概念, 使因丢失数据包而受惩罚的 "user" 是对 congestion 贡献最大的用户. 无论实现何种机制来处理 bandwidth congestion control, 都必须 确保消耗的 CPU effort 足够小, 使路由器不会同时陷入 CPU congestion.

如 Section [4.3.3.3] 所述, 本文档推荐路由器不应该向其正在丢弃的数据包的发送方发送 Source Quench. ICMP Source Quench 是一种非常弱的机制, 因此路由器不需要发送它, host software 也不应只把它作为 congestion 的指示.

5.3.7 Martian Address Filtering

如果 IP source address 是 4.2.2.11 或 5.3.7 中定义的 special IP address, 或者不是 unicast address, 则它无效.

如果 IP destination address 属于 4.2.3.1 中定义为非法目标的地址, 或者是 Class E address (255.255.255.255 除外), 则它无效.

路由器不应该转发任何具有无效 IP source address 或 network 0 上 source address 的数据包. 路由器不应该转发任何具有 network 127 上 source address 的数据包, 但通过 loopback interface 转发的除外. 路由器可以具有一个开关, 允许网络管理员禁用这些检查. 如果提供此 开关, 则默认必须执行这些检查.

路由器不应该转发任何具有无效 IP destination address 或 network 0 上 destination address 的数据包. 路由器不应该转发任何具有 network 127 上 destination address 的数据包, 但通过 loopback interface 转发的除外. 路由器可以具有一个开关, 允许网络管理员禁用这些检查. 如果提供此开关, 则默认必须执行这些检查.

如果路由器因这些规则而丢弃数据包, 它应该至少记录 IP source address, IP destination address, 并且如果问题在 source address 上, 还应该记录接收该数据包的物理接口以及发送该 数据包的主机或路由器的 Link Layer address.

5.3.8 Source Address Validation

路由器应该实现根据数据包 source address 与接收该数据包的 logical interface 的 forwarding table 比较结果来过滤流量的能力. 如果启用此过滤, 当接收该数据包的接口不是到达 source address 中所含地址时数据包将被转发出的接口时, 路由器必须静默丢弃该数据包. 更简单地说, 如果路由器不会通过某个特定接口路由包含此地址的数据包, 那么当此地址作为从该接口读取的 数据包中的 source address 出现时, 它就不应相信该地址.

如果实现此功能, 默认必须禁用它.

讨论:

此功能在某些情况下可以提供有用的安全改进, 但在路径不对称的情况下可能错误地丢弃有效 数据包.

5.3.9 Packet Filtering and Access Lists

作为为网络某些部分提供安全性和/或限制流量的一种手段, 路由器应该提供选择性转发 (或过滤) 数据包的能力. 如果提供此能力, 数据包过滤应该可配置为转发所有数据包, 或基于 source 和 destination prefixes 选择性转发数据包, 并且可以基于其他 message attributes 进行过滤. 每个 source 和 destination address 应该允许指定任意 prefix length.

讨论:

此功能可以提供一定程度的隐私, 例如不允许边界之外的系统与边界之内的系统交换某些协议, 或限制它们可以与哪些系统通信. 它还可以帮助防止某些类别的安全破坏, 例如边界之外的系统 伪装成边界之内的系统并模拟与其建立会话.

如果支持, 路由器应该可配置为允许以下之一:

o Include list - 指定要转发的 message definitions 列表, 或

o Exclude list - 指定不得转发的 message definitions 列表.

在此语境中, "message definition" 指定 source 和 destination network prefix, 并且可以 包括其他标识信息, 例如 IP Protocol Type 或 TCP port number.

路由器可以提供一个配置开关, 允许在指定 include list 或 exclude list 之间选择, 或提供 其他等效控制.

必须允许匹配任何地址的值 (例如 keyword any, mask 全为 0 的地址, 或长度为零的 network prefix) 作为 source 和/或 destination address.

除地址对之外, 路由器可以允许指定 transport 和/或 application protocol 与 source 和 destination ports 的任意组合.

路由器必须允许静默丢弃数据包 (即丢弃时不发送 ICMP error message).

路由器应该允许在丢弃数据包时发送适当的 ICMP unreachable message. ICMP message 应该将 Communication Administratively Prohibited (code 13) 指定为目标不可达的原因.

路由器应该允许针对其可指定的 address pairs, protocol types 和 ports 的每种组合, 配置 是否发送 ICMP destination unreachable messages (code 13).

路由器应该计数未转发的数据包, 并且应该允许选择性记录这些数据包.

5.3.10 Multicast Routing

IP 路由器应该支持 IP multicast packets 的转发, 既可以基于 static multicast routes, 也可以基于 multicast routing protocol (例如 DVMRP [ROUTE:9]) 动态确定的路由. 转发 IP multicast packets 的路由器称为 multicast router.

5.3.11 Controls on Forwarding

对于每个物理接口, 路由器应该具有一个配置选项, 指定该接口上是否启用 forwarding. 当某个 接口上的 forwarding 被禁用时, 路由器:

o 必须静默丢弃在该接口上收到但并非寻址到该路由器的任何数据包

o 不得从该接口发出数据包, 但由该路由器发起的数据报除外

o 不得通过任何 routing protocols 宣告经由该接口的路径可用

讨论:

此功能允许网络管理员实质上关闭某个接口, 但仍使其可用于 network management.

理想情况下, 此控制应适用于逻辑接口而不是物理接口. 但它不能这样做, 因为在逻辑接口和 物理接口之间不存在一一对应关系时, 目前没有已知方法可让路由器确定数据包到达的是哪个 逻辑接口.

5.3.12 State Changes

在路由器运行期间, 接口可能失败或被手工禁用, 或者可能变得可供路由器使用. 类似地, forwarding 可能针对特定接口或整个路由器被禁用, 也可能被 (重新) 启用. 虽然此类转换 (通常) 不常见, 但路由器正确处理它们很重要.

5.3.12.1 When a Router Ceases Forwarding

当路由器停止 forwarding 时, 它必须停止通告所有路由, third party routes 除外. 它可以 继续接收并使用来自其 routing domains 中其他路由器的路由. 如果保留 forwarding database, 路由器不得停止对 forwarding database 中的路由计时. 如果记住了从其他路由器收到的路由, 路由器不得停止对其记住的路由计时. 对于 forwarding 被禁用期间 timer 过期的任何路由, 它必须像 forwarding 启用时那样丢弃.

讨论:

当路由器停止 forwarding 时, 它实质上不再是路由器. 它仍然是主机, 并且必须遵循 Host Requirements [INTRO:2] 的所有要求. 但是, 该路由器仍可以是一个或多个 routing domains 的被动成员. 因此, 它允许通过监听其 routing domain 中的其他路由器来维护其 forwarding database. 但是, 它不得通告 forwarding database 中的任何路由, 因为它自身并不执行 forwarding. 此规则的唯一例外是路由器正在通告一条仅使用其他路由器的路由, 且该路由器已 被要求通告这条路由.

路由器可以向它无法转发的数据包的发送方发送 ICMP destination unreachable (host unreachable) messages. 它不应该发送 ICMP redirect messages.

讨论:

请注意, 发送 ICMP destination unreachable (host unreachable) 是路由器动作. 主机不应发送 此消息. 允许这种对主机规则的例外, 是为了让数据包可以在尽可能短的时间内重新路由, 并避免 black holes.

5.3.12.2 When a Router Starts Forwarding

当路由器开始 forwarding 时, 它应该加快向通常与其交换 routing information 的所有路由器 发送新的 routing information.

5.3.12.3 When an Interface Fails or is Disabled

如果接口失败或被禁用, 路由器必须移除并停止通告其 forwarding database 中所有使用该接口 的路由. 它必须禁用所有使用该接口的 static routes. 如果路由器学习到或记住了通往同一 destination 和 TOS 的其他路由, 则路由器必须选择最佳替代路由, 并将其加入 forwarding database. 对于所有因接口不可用而无法转发的数据包, 路由器应该根据适用情况回复 ICMP destination unreachable 或 ICMP redirect messages.

5.3.12.4 When an Interface is Enabled

如果先前不可用的接口变为可用, 路由器必须重新启用所有使用该接口的 static routes. 如果 路由器学习到会使用该接口的路由, 则必须将这些路由与所有其他已学习路由一起评估, 并且 路由器必须决定哪些路由应放入 forwarding database. 关于如何作出该决策, 实现者可参见 Chapter [7], Application Layer - Routing Protocols.

路由器应该加快向其通常交换 routing information 的所有路由器发送新的 routing information.

5.3.13 IP Options

若干选项, 例如 Record Route 和 Timestamp, 包含一些 slots, 路由器在转发数据包时会将其 地址插入这些 slots. 然而, 每个这样的选项都只有有限数量的 slots, 因此路由器可能会发现 没有可用 slot 可供插入其地址. 下列任何要求都不应被解释为要求路由器将其地址插入一个已 无剩余 slot 的选项. Section [5.2.5] 讨论了路由器必须如何选择要插入选项中的自身地址.

5.3.13.1 Unrecognized Options

转发数据包中未识别的 IP options 必须不加修改地透传.

5.3.13.2 Security Option

某些环境要求每个数据包都包含 Security option; 这种要求超出了本文档和 IP 标准规范的范围. 但需注意, [INTERNET:1] 和 [INTERNET:16] 中描述的 security options 已经过时. 路由器应该 实现 [INTERNET:5] 中描述的修订版 security option.

讨论:

供多安全级别网络使用的路由器应该支持基于 IPSO (RFC-1108) labels 的 packet filtering. 为实现这种支持, 路由器需要允许路由器管理员在每个接口上配置下限 sensitivity limit (例如 Unclassified) 和上限 sensitivity limit (例如 Secret). 两个限制通常相同, 但并不 总是如此 (例如 single-level interface). 被 IPSO filter 捕获为超出范围的数据包应该被 静默丢弃, 并且应通过 counter 记录因 IPSO labels 超出范围而被丢弃的数据包数量.

5.3.13.3 Stream Identifier Option

此选项已过时. 如果路由器转发的数据包中存在 Stream Identifier option, 则必须忽略该选项, 并不加修改地透传.

5.3.13.4 Source Route Options

路由器必须实现对转发数据包中 source route options 的支持. 路由器可以实现一个配置选项, 启用后会丢弃所有 source-routed packets. 然而, 这样的选项不得默认启用.

讨论:

通过 Internet 对数据报进行 source route 的能力对多种网络诊断工具很重要. 然而, source routing 可能被用来绕过网络内的管理和安全控制. 具体而言, 在那些通过操纵 routing tables 来提供管理隔离, 而非采用 packet filtering 等其他方法的场景中, source routed packets 可能造成脆弱性.

编辑者注释:

如果 packet filtering 应用于 source routed path 上除最后一跳之外的任何路由器, source routing 也可能绕过 packet filtering. route filters 和 packet filters 都不能构成完整的 安全解决方案.

5.3.13.5 Record Route Option

路由器必须支持转发数据包中的 Record Route option.

路由器可以提供一个配置选项, 启用后会使路由器忽略转发数据包中的 Record Route options (即不加修改地透传). 如果提供该选项, 默认值必须是启用 record-route. 此选项不应影响对 路由器自身接收的数据报中 Record Route options 的处理 (特别是, ICMP echo requests 中的 Record Route options 仍将按 Section [4.3.3.6] 处理).

讨论:

有些人认为 Record Route 是一个安全问题, 因为它会披露关于网络拓扑的信息. 因此, 本文档 允许禁用它.

5.3.13.6 Timestamp Option

路由器必须支持转发数据包中的 timestamp option. timestamp value 必须遵循 [INTRO:2] 中 给出的规则.

如果 flags field = 3 (timestamp and prespecified address), 当下一个 prespecified address 匹配路由器的任一 IP address 时, 路由器必须加入其 timestamp. 该 prespecified address 不必是数据包到达接口的地址, 也不必是数据包将要发出接口的地址.

实现:

为最大化 timestamp option 中所含 timestamps 的效用, 建议插入的 timestamp 尽可能接近 数据包到达路由器的时间. 对于由路由器发起的数据报, 插入的 timestamp 应尽可能接近该数据报 被传递给 network layer 以进行传输的时间.

路由器可以提供一个配置选项, 启用后会使路由器在 flag word 设置为 zero (timestamps only) 或 one (timestamp and registering IP address) 时, 忽略转发数据报中的 Timestamp options (即不加修改地透传). 如果提供该选项, 默认必须为关闭 (即路由器不忽略 timestamp). 此选项 不应影响对路由器自身接收的数据报中 Timestamp options 的处理 (特别是, 路由器会向路由器 接收的数据报中的 Timestamp options 插入 timestamps, 并且 ICMP echo requests 中的 Timestamp options 仍将按 Section [4.3.3.6] 处理).

讨论:

与 Record Route option 一样, Timestamp option 可能泄露关于网络拓扑的信息. 有些人认为 这是一个安全顾虑.

6. TRANSPORT LAYER

除支持路由器所支持的 Application Layer protocols 所需的 Transport Layer protocols 外, 路由器不要求实现任何 Transport Layer protocols. 实际上, 这意味着多数路由器同时实现 Transmission Control Protocol (TCP) 和 User Datagram Protocol (UDP).

6.1 USER DATAGRAM PROTOCOL - UDP

User Datagram Protocol (UDP) 在 [TRANS:1] 中规定.

实现 UDP 的路由器必须符合 [INTRO:2] 的要求, 并且应该无条件符合这些要求, 但以下情况除外:

o 本规范不规定各协议层之间的接口. 因此, 路由器的接口不需要符合 [INTRO:2], 除非路由器 所支持的 Application Layer protocols 为正确运行而要求符合.

o 与 [INTRO:2] 相反, 应用程序不应该禁用 UDP checksums 的生成.

讨论:

虽然某个特定 application protocol 可能要求其接收的 UDP datagrams 必须包含 UDP checksum, 但不存在接收的 UDP datagrams 必须包含 UDP checksums 的一般要求. 当然, 如果接收的数据报 中存在 UDP checksum, 则必须验证该 checksum, 并在 checksum 不正确时丢弃该数据报.

6.2 TRANSMISSION CONTROL PROTOCOL - TCP

Transmission Control Protocol (TCP) 在 [TRANS:2] 中规定.

实现 TCP 的路由器必须符合 [INTRO:2] 的要求, 并且应该无条件符合这些要求, 但以下情况除外:

o 本规范不规定各协议层之间的接口. 因此, 路由器不需要符合 [INTRO:2] 的以下要求 (当然, 除非路由器所支持的 Application Layer protocols 为正确运行而要求符合):

Use of Push: RFC-793 Section 2.8: 将接收到的 PSH flag 传递给 application layer 现在是可选的.

Urgent Pointer: RFC-793 Section 3.1: TCP 在收到 Urgent pointer 且此前没有挂起的 urgent data 时, 或者在 Urgent pointer 在数据流中前移时, 必须异步通知 application layer. 必须有一种方式让应用程序获知 连接中还剩多少 urgent data 待读, 或者至少能够确定是否还有更多 urgent data 待读.

TCP Connection Failures: 应用程序必须能够为某个特定连接设置 R2 的值. 例如, 交互式应用程序可以将 R2 设置为 ``infinity,'' 从而让用户控制何时断开连接.

TCP Multihoming: 如果 multihomed host 上的应用程序在主动打开 TCP 连接时未指定本地 IP address, 则 TCP 必须在发送 (第一个) SYN 之前请求 IP layer 选择一个本地 IP address. 见 Section 3.4 中的函数 GET_SRCADDR().

IP Options: 应用程序在主动打开 TCP 连接时必须能够指定 source route, 并且该 source route 必须 优先于数据报中接收到的 source route.

o 出于类似原因, 路由器不需要符合 [INTRO:2] 中的任何要求.

o [INTRO:2] 中关于 Maximum Segment Size Option 的要求修订如下: 实现 MTU discovery 的 host portion (见本备忘录 Section [4.2.3.3]) 的路由器, 仅在 path MTU 未知时才使用 536 作为 SendMSS 的默认值; 如果 path MTU 已知, 则 SendMSS 的默认值为 path MTU - 40.

o [INTRO:2] 中关于 Maximum Segment Size Option 的要求修订如下: ICMP Destination Unreachable codes 11 和 12 是附加的 soft error conditions. 因此, 这些 messages 不得 导致 TCP 中止连接.

讨论:

需要特别注意, 路由器中的 TCP 实现必须符合 [INTRO:2] 的以下要求:

o 提供可配置的 TTL. [Time to Live: RFC-793 Section 3.9]

o 如果使用 keep-alives, 则提供用于配置 keep-alive 行为的接口. [TCP Keep-Alives]

o 提供 error reporting mechanism, 以及管理该机制的能力. [Asynchronous Reports]

o 指定 type of service. [Type-of-Service]

所采用的一般范式是: 如果某个特定接口在路由器外部可见, 则必须遵循该接口的所有要求. 例如, 如果路由器提供 telnet 功能, 则它将生成可能在外部网络中被路由的流量. 因此, 它必须 能够正确设置 type of service, 否则 telnet 流量可能无法通过.

7. APPLICATION LAYER - ROUTING PROTOCOLS

7.1 INTRODUCTION

出于技术, 管理, 有时也包括政治方面的原因, Internet routing system 由两个组件组成: interior routing 和 exterior routing. 本文档 Section 2.2.4 中定义的 Autonomous System (AS) 概念, 在将 interior routing 与 exterior routing 分离时发挥关键作用, 因为该概念 允许界定发生从 interior routing 到 exterior routing 转换的一组路由器. 一个 IP datagram 可能必须穿越两个或更多 Autonomous Systems 的路由器才能到达其目标, 并且这些 Autonomous Systems 必须相互提供 topology information, 以允许这种转发. Interior gateway protocols (IGPs) 用于在 AS 内分发 routing information (即 intra-AS routing). Exterior gateway protocols 用于在 AS 之间交换 routing information (即 inter-AS routing).

7.1.1 Routing Security Considerations

Routing 是少数几个不适用 Robustness Principle (be liberal in what you accept) 的场景之一. 路由器在接受来自其他 routing systems 的 routing data 时应该相对谨慎.

路由器应该提供一种能力, 可按从最可信到最不可信的顺序对 routing information sources 进行 排序, 并优先接受最可信来源关于任何特定目标的 routing information. 这在使用 EGP 和各种 interior routing protocols 的原始 core/stub autonomous system routing model 中是隐含的. 随着集中式可信 core 的消亡, 这一点更加重要.

路由器应该提供一种机制, 用于过滤明显无效的路由 (例如 net 127 的路由).

默认情况下, 路由器不得重新分发其自身不使用, 不信任或不认为有效的 routing data. 在少数 情况下, 可能需要重新分发可疑信息, 但这只应在人为直接干预下发生.

路由器在接受来自任何人的 routing data 时必须至少保持一定程度的谨慎, 并且在分发由另一方 提供给它们的 routing information 时必须特别小心. 具体指南见下文.

7.1.2 Precedence

除非特定 routing protocol 的规范另有规定, 路由器应该将其发起的承载 routing traffic 的 IP datagrams 的 IP Precedence 值设置为 6 (INTERNETWORK CONTROL).

讨论:

除极少数例外外, routing traffic 应该是任何网络上 precedence 最高的流量. 如果系统的 routing traffic 无法通过, 很可能其他任何流量也无法通过.

7.1.3 Message Validation

Peer-to-peer authentication 涉及若干测试. 过去, 应用 message passwords 和显式 acceptable neighbor lists 提升了 route database 的鲁棒性. 路由器应该实现 management controls, 以便 能够显式列出有效的 routing neighbors. 对于支持 peer-to-peer authentication 的 routing protocols, 路由器应该实现 peer-to-peer authentication.

路由器应该根据 routing neighbors 的 source address 以及接收消息的接口来验证它们; 对于 directly attached subnet 中的 neighbors, 应该限制其只能通过该 subnet 所在的接口或通过 unnumbered interfaces 与路由器通信. 在其他接口上收到的 messages 应该被静默丢弃.

讨论:

这种基本测试可避免安全漏洞和大量 routing problems.

7.2 INTERIOR GATEWAY PROTOCOLS

7.2.1 INTRODUCTION

Interior Gateway Protocol (IGP) 用于在特定 AS 内的各路由器之间分发 routing information. 无论用于实现某个特定 IGP 的算法是什么, 它都应该执行以下功能:

(1) 快速响应 AS 内部拓扑的变化

(2) 提供一种机制, 使 circuit flapping 不会导致持续的 routing updates

(3) 提供快速收敛到无环路由的能力

(4) 使用最小带宽

(5) 提供 equal cost routes, 以支持 load-splitting

(6) 提供用于 routing updates 认证的手段

当前 Internet 中使用的 IGPs 通常被归类为基于 distance-vector 算法或 link-state 算法.

本节详细说明若干 IGPs, 包括最常用的协议以及一些最近开发, 将来可能被广泛使用的协议. Internet 社区中还存在许多其他 intended for use in intra-AS routing 的协议.

实现任何 routing protocol (static routes 除外) 的路由器必须实现 OSPF (见 Section [7.2.2]). 路由器可以实现其他 IGPs.

7.2.2 OPEN SHORTEST PATH FIRST - OSPF

基于 Shortest Path First (SPF) 的 routing protocols 是一类 link-state algorithms, 基于 Dijkstra 的 shortest-path algorithm. 虽然基于 SPF 的算法自 ARPANET 初期以来就已存在, 但直到最近才在 IP 和 OSI 社区内部都获得流行. 在基于 SPF 的系统中, 每台路由器通过称为 flooding 的过程获得完整的 topology database. Flooding 确保信息可靠传输. 随后, 每台 路由器在其 database 上运行 SPF algorithm, 以构建 IP routing table. OSPF routing protocol 是 SPF algorithm 的一种实现. 当前版本 OSPF version 2 在 [ROUTE:1] 中规定. 注意, 描述 OSPF version 1 的 RFC-1131 已过时.

注意, 为符合本备忘录 Section [8.3], 实现 OSPF 的路由器必须实现 OSPF MIB [MGT:14].

7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS-IS

American National Standards Institute (ANSI) X3S3.3 委员会定义了一种 intra-domain routing protocol. 该协议名为 Intermediate System to Intermediate System Routeing Exchange Protocol.

其在 IP network 中的应用已在 [ROUTE:2] 中定义, 并称为 Dual IS-IS (有时也称为 Integrated IS-IS). IS-IS 基于 link-state (SPF) routing algorithm, 并共享此类协议的所有优势.

7.3 EXTERIOR GATEWAY PROTOCOLS

7.3.1 INTRODUCTION

Exterior Gateway Protocols 用于 inter-Autonomous System routing, 以便将某个特定 autonomous system 内部一组网络的 reachability information 交换给相邻 autonomous system.

inter-AS routing 领域是 Internet Engineering Task Force 内当前的研究主题. Section [Appendix F.1] 中描述的 Exterior Gateway Protocol (EGP) 传统上一直是首选的 inter-AS protocol, 但现在已成为 historical. Border Gateway Protocol (BGP) 消除了 EGP 的许多约束 和限制, 因而正迅速变得流行. 路由器不要求实现任何 inter-AS routing protocol. 然而, 如果 路由器确实实现 EGP, 它也必须实现 BGP. 尽管 RIP (见 Section [7.2.4]) 并非被设计为 exterior gateway protocol, 但有时也用于 inter-AS routing.

7.3.2 BORDER GATEWAY PROTOCOL - BGP

7.3.2.1 Introduction

Border Gateway Protocol (BGP-4) 是一种 inter-AS routing protocol, 用于与其他 BGP speakers 交换 network reachability information. 某个网络的信息包括流量到达该网络必须经过的完整 AS 列表. 随后可使用这些信息来确保 loop-free paths. 这些信息足以构造 AS connectivity graph, 从中可剪除 routing loops, 并可在 AS 级别执行某些 policy decisions.

BGP 由 [ROUTE:4] 定义. [ROUTE:5] 规定了 BGP 在 Internet 中的正确用法, 并提供了一些有用的 实现提示和指南. [ROUTE:12] 和 [ROUTE:13] 提供了额外的有用信息.

为符合本备忘录 Section [8.3], 实现 BGP 的路由器要求实现 BGP MIB [MGT:15].

要刻画可使用 BGP 执行的一组 policy decisions, 必须关注这样一条规则: AS 只向其 neighbor ASs 通告它自身使用的那些路由. 该规则反映了当前整个 Internet 中通常采用的 hop-by-hop routing paradigm. 注意, 某些策略无法由 hop-by-hop routing paradigm 支持, 因而需要 source routing 等技术来执行. 例如, BGP 不能使一个 AS 将流量发送给相邻 AS, 同时要求该流量采用 与源自该相邻 AS 的流量不同的路由. 另一方面, BGP 可以支持任何符合 hop-by-hop routing paradigm 的策略.

强烈鼓励 BGP 实现者遵循 [ROUTE:5] Section 6 中概述的建议.

7.3.2.2 Protocol Walk-through

虽然 BGP 支持相当复杂的 routing policies (示例见 [ROUTE:5] Section 4.2), 但并不要求所有 BGP 实现者都支持此类策略. 不过, BGP 实现至少:

(1) 应该允许 AS 控制向相邻 AS's 通告通过 BGP 学习到的路由. 实现应该至少支持以单个网络 为粒度的这种控制. 实现还应该支持以 autonomous system 为粒度的这种控制, 其中 autonomous system 可以是发起该路由的 autonomous system, 也可以是向本地系统通告该 路由的 autonomous system (adjacent autonomous system).

(2) 应该允许 AS 偏好到某个目标的特定路径 (当存在多条路径时). 该功能应该通过允许 system administrator 为 Autonomous Systems 分配 weights, 并使 route selection process 选择 weight 最低的路由来实现 (其中路由的 weight 定义为与该路由关联的 AS_PATH path attribute 中所有 AS's 的 weights 之和).

(3) 应该允许 AS 忽略 AS_PATH path attribute 中包含某些 AS's 的路由. 该功能可以使用 (2) 中概述的技术来实现, 即为这些 AS's 分配 infinity 作为 weights. route selection process 必须忽略 weight 等于 infinity 的路由.

7.3.3 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL

可以在两个 autonomous systems 或 routing domains 之间交换 routing information, 而不在两个 独立的标准 interior routing protocols 之间使用标准 exterior routing protocol. 最常见的 方式是在其中一个 border routers 中独立运行两个 interior protocols, 并在两个进程之间交换 route information.

与从 EGP 到 IGP 的信息交换一样, 如果没有适当控制, 单个路由器中两个 IGPs 之间的这些 routing information 交换也可能造成 routing loops.

7.4 STATIC ROUTING

Static routing 提供了一种显式定义从路由器到特定目标的 next hop 的方式. 路由器应该提供 一种方式, 用于定义到某一目标的 static route, 其中该目标由 network prefix 定义. 该机制 还应该允许为每条 static route 指定 metric.

支持 dynamic routing protocol 的路由器必须允许使用所采用 routing protocol 中有效的任何 metric 来定义 static routes. 路由器必须提供能力, 使用户能够指定一个 static routes 列表, 这些路由可以通过 routing protocol 传播, 也可以不传播. 此外, 如果路由器支持某个能够使用 以下信息的 routing protocol, 则应该支持以下附加信息. 这些信息是:

o TOS,

o Subnet Mask, 或

o Prefix Length, 或

o 某个能够导入该路由的特定 routing protocol 专用的 metric.

讨论:

我们的意图是, 只需要支持对给定 routing protocol 有用的内容. 对 TOS 的需求不应要求供应商 实现其他未被使用的部分.

路由器是否优先选择 static route 而不是 dynamic route (或反之), 或是否使用关联的 metrics 在相互冲突的 static 和 dynamic routes 之间进行选择, 应该可以针对每条 static route 进行 配置.

路由器必须允许为其支持的每个 routing domain 向 static route 分配一个 metric. 每个此类 metric 都必须被显式分配给一个特定 routing domain. 例如:

 route 10.0.0.0/8 via 192.0.2.3 rip metric 3

 route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27

 route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99

讨论:

有人建议, 理想情况下, static routes 应该具有 preference values 而不是 metrics (因为 metrics 只能与同一 routing domain 中其他路由的 metrics 比较, static route 的 metric 只能 与其他 static routes 的 metrics 比较). 这与某些当前实现相反, 在这些实现中 static routes 确实具有 metrics, 且这些 metrics 用于确定某条特定 dynamic route 是否覆盖到同一目标的 static route. 因此, 本文档使用术语 metric, 而不是 preference.

该技术本质上将 static route 变成 RIP route, 或 OSPF route (或其他形式, 取决于 metric 所属的 domain). 因此, 该 domain 的 route lookup algorithm 适用. 然而, 这并不是 route leaking, 因为将 static route 强制纳入 dynamic routing domain, 并不授权路由器将该路由重新 分发到 dynamic routing domain 中.

对于未放入特定 routing domain 的 static routes, route lookup algorithm 为:

(1) Basic match

(2) Longest match

(3) Weak TOS (如果支持 TOS)

(4) Best metric (其中 metric 由实现定义)

最后一步可能并非必需, 但在希望通过一个接口拥有一条 primary static route, 并通过另一个 备用接口拥有一条 secondary static route, 且在 primary route 的接口失效时 failover 到备用 路径的情况下, 它很有用.

7.5 FILTERING OF ROUTING INFORMATION

网络中的每台路由器都基于其 forwarding database 中包含的信息作出转发决策. 在简单网络中, 该 database 的内容可以静态配置. 随着网络变得更复杂, forwarding database 的动态更新需求 对于网络高效运行变得至关重要.

如果希望网络中的 data flow 尽可能高效, 就必须提供一种机制来控制路由器用于构建 forwarding database 的信息传播. 这种控制表现为选择应信任哪些 routing information 源, 以及选择应相信 其中哪些信息. 由此得到的 forwarding database 是可用 routing information 的一个过滤版本.

除效率之外, 控制 routing information 的传播还可以通过防止错误或不良 routing information 的扩散来减少不稳定性.

在某些情况下, local policy 可能要求完整的 routing information 不被广泛传播.

这些过滤要求仅适用于 non-SPF-based protocols (因此完全不适用于未实现任何 distance vector protocols 的路由器).

7.5.1 Route Validation

除非接收该 update 的 routing protocol 使用这些值来编码特殊路由 (例如 default routes), 否则路由器应该将任何通告违反本备忘录规范的路由的 routing update 记录为错误.

7.5.2 Basic Route Filtering

routing information 的过滤允许控制路由器用于转发其接收数据包的路径. 路由器应该选择性地 决定监听哪些 routing information 源, 以及相信哪些路由. 因此, 路由器必须提供能力来指定:

o 将在哪些 logical interfaces 上接受 routing information, 以及从每个 logical interface 接受哪些路由.

o 是在某个 logical interface 上通告所有路由, 还是只通告 default route.

某些 routing protocols 并不将 logical interfaces 识别为 routing information 的来源. 在 这种情况下, 路由器必须提供能力来指定:

o 将从哪些其他路由器接受 routing information.

例如, 假设有一台路由器将一个或多个 leaf networks 连接到较大网络的主要部分或 backbone. 由于每个 leaf network 只有一条进出路径, 该路由器可以简单地向它们发送 default route. 它向主网络通告这些 leaf networks.

7.5.3 Advanced Route Filtering

随着网络拓扑变得更复杂, 对更复杂 route filtering 的需求也会出现. 因此, 路由器应该提供 能力, 针对每个 routing protocol 独立指定:

o 将从哪些 logical interfaces 或路由器接受 routing information (routes), 以及从每个其他 路由器或 logical interface 相信哪些路由,

o 哪些路由将通过哪些 logical interface(s) 发送, 以及

o 如果正在使用的 routing protocol 支持, routing information 将发送给哪些路由器.

在许多情况下, 希望为从另一台路由器接收的 routing information 分配一个 reliability ordering, 而不是上面第一项中列出的简单相信或不相信选择. 路由器可以提供能力来指定:

o 分配给每条接收路由的 reliability 或 preference. 无论每条路由关联的 routing metric 如何, reliability 较高的路由都将优先于 reliability 较低的路由被选择.

如果路由器支持分配 preferences, 则路由器不得将其不优先选择的任何路由作为 first party information 传播. 如果用于传播这些路由的 routing protocol 不支持区分 first party information 与 third party information, 则路由器不得传播其不优先选择的任何路由.

讨论:

例如, 假设某台路由器从路由器 R 接收到到网络 C 的路由, 并从路由器 S 接收到到同一网络的 路由. 如果路由器 R 被认为比路由器 S 更可靠, 则发往网络 C 的流量将转发到路由器 R, 而不论 从路由器 S 接收到的路由如何.

路由器未使用的路由的 routing information (上例中的路由器 S) 不得传递给任何其他路由器.

7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE

如果同一路由器中可以运行独立的 IP routing processes, 路由器必须能够在不同的 IP interior routing protocols 之间交换 routing information. 当路由器被配置为在两个不同的 interior routing processes 之间双向交换 routing information 时, 路由器必须提供某种机制来避免 routing loops. 路由器必须提供某种优先级机制, 用于从独立 routing processes 中选择路由. 当跨 administrative boundaries 使用 IGP-IGP 交换时, 路由器应该提供 administrative control.

路由器应该提供某种机制, 用于按网络转换或变换 metrics. 路由器 (或 routing protocols) 可以 允许对导入 IGP 的 exterior routes 设置 global preference.

讨论:

不同 IGP 使用不同 metrics, 因此在将信息从一种协议引入另一种具有不同 metric 形式的协议时, 需要某种转换技术. 某些 IGP 可以在同一路由器或同一组路由器内运行多个实例. 在这种情况下, metric information 可以被精确保留或被转换.

在不同 routing processes 之间至少有两种转换技术. static (或 reachability) 方法使用一个 IGP 中 route advertisement 的存在, 在另一个 IGP 中以给定 metric 生成 route advertisement. translation 或 tabular 方法使用一个 IGP 中的 metric, 通过函数 (例如加上常量) 或查表在 另一个 IGP 中创建 metric.

如果没有控制机制来限制反馈, 双向交换 routing information 是危险的. 这与 distance vector routing protocols 必须通过 split horizon 技术处理的问题相同, 也与 EGP 通过 third-party rule 处理的问题相同. routing loops 可以通过使用允许/拒绝路由的表或列表来显式避免, 也可以 通过使用 split horizon rule, no-third-party rule, 或 route tagging mechanism 来隐式避免. 鼓励供应商在可能的情况下使用隐式技术, 以便网络运营者更易于管理.

8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS

注意, 本章取代 [INTRO:3] 中 "REMOTE MANAGEMENT" 下陈述的任何要求.

8.1 The Simple Network Management Protocol - SNMP

8.1.1 SNMP Protocol Elements

路由器必须能够通过 SNMP [MGT:3] 管理. SNMP 必须使用 UDP/IP 作为其 transport 和 network protocols 运行. 其他协议可以被支持 (例如, 见 [MGT:25, MGT:26, MGT:27, and MGT:28]). SNMP management operations 必须像 SNMP 在路由器自身上实现一样运行. 具体而言, 必须通过向 分配给路由器任一接口的任一 IP address 发送 SNMP management requests 来执行 management operations. 实际的 management operation 可以由路由器执行, 也可以由路由器的 proxy 执行.

讨论:

这一表述旨在允许通过 proxy 进行管理, 即 proxy device 响应 destination address field 中 包含该路由器某个 IP address 的 SNMP packets; 也允许 SNMP 直接在路由器自身实现, 并以适当 方式接收和响应数据包.

重要的是, management operations 能够发送到路由器的某个 IP Addresses. 在诊断网络问题时, 可用于识别路由器的唯一信息可能就是该路由器的某个 IP address; 该地址也许是通过查看另一台 路由器的 routing table 获得的.

必须实现所有 SNMP operations (get, get-next, get-response, set, and trap).

路由器必须提供一种机制, 用于对 SNMP trap messages 的生成进行速率限制. 路由器可以通过 [MGT:5] 中描述的 asynchronous alert management 算法提供该机制.

讨论:

尽管关于需要对 traps 进行速率限制已存在普遍共识, 但关于最佳实现方式尚无共识. 所引用的 参考文献被认为是 experimental.

8.2 Community Table

就本规范而言, 我们假定路由器中存在一个抽象的 `community table'. 该表包含多个条目, 每个 条目对应一个特定 community, 并包含完全定义该 community 属性所需的参数. 抽象 community table 的实际实现方法当然是 implementation specific.

路由器的 community table 必须允许至少一个条目, 并且应该允许至少两个条目.

讨论:

容量为零的 community table 没有用处. 这意味着路由器不会识别任何 communities, 因而所有 SNMP operations 都将被拒绝.

因此, 一个条目是该表的最小有用大小. 两个条目则允许一个条目被限制为 read-only access, 而另一个条目具有 write capabilities.

路由器必须允许用户手动 (即不使用 SNMP) 检查, 添加, 删除和更改 SNMP community table 中的 条目. 用户必须能够设置 community name 或构造 MIB view. 用户必须能够将 communities 配置为 read-only (即它们不允许 SETs) 或 read-write (即它们允许 SETs).

如果使用 traps, 用户必须能够为每个 community 或 MIB view 定义至少一个用于发送 notifications 的 IP address. 这些地址应该可以按 community 或 MIB view 定义. 应该能够按 community 或 MIB view 启用或禁用 notifications.

路由器应该提供能力, 用于为任何特定 community 指定有效 network managers 列表. 如果启用, 路由器必须根据该列表验证 SNMP datagram 的 source address, 并且如果其地址未出现于该列表中, 则必须丢弃该 datagram. 如果丢弃该 datagram, 路由器必须执行与 SNMP authentication failure 相适应的所有动作.

讨论:

这是一个相当有限的 authentication system, 但结合各种形式的 packet filtering, 可能提供一定 程度的安全性提升.

community table 必须保存在 non-volatile storage 中.

community table 的初始状态应该包含一个条目, 其 community name string 为 public, 且访问权限 为 read-only. 该条目的默认状态不得发送 traps. 如果实现了该条目, 则该条目必须保留在 community table 中, 直到管理员更改或删除它.

讨论:

默认情况下, traps 不发送到该 community. Trap PDUs 被发送到 unicast IP addresses. 该地址 必须以某种方式配置到路由器中. 在配置发生之前, 并不存在这样的地址, 那么 trap 应该发送给谁? 因此, 向 public community 发送 trap 默认被禁用. 当然, 一旦路由器开始运行, 可以通过管理 操作更改此设置.

8.3 Standard MIBS

所有与路由器配置相关的 MIBS 都应实现. 也就是说:

o MIB-II [MGT:2] 的 System, Interface, IP, ICMP, and UDP groups 必须实现.

o Interface Extensions MIB [MGT:18] 必须实现.

o IP Forwarding Table MIB [MGT:20] 必须实现.

o 如果路由器实现 TCP (例如用于 Telnet), 则 MIB-II [MGT:2] 的 TCP group 必须实现.

o 如果路由器实现 EGP, 则 MIB-II [MGT:2] 的 EGP group 必须实现.

o 如果路由器支持 OSPF, 则 OSPF MIB [MGT:14] 必须实现.

o 如果路由器支持 BGP, 则 BGP MIB [MGT:15] 必须实现.

o 如果路由器具有 Ethernet, 802.3, 或 StarLan interfaces, 则 Ethernet-Like MIB [MGT:6] 必须实现.

o 如果路由器具有 802.4 interfaces, 则 802.4 MIB [MGT:7] 必须实现.

o 如果路由器具有 802.5 interfaces, 则 802.5 MIB [MGT:8] 必须实现.

o 如果路由器具有实现 ANSI SMT 7.3 的 FDDI interfaces, 则 FDDI MIB [MGT:9] 必须实现.

o 如果路由器具有实现 ANSI SMT 6.2 的 FDDI interfaces, 则 FDDI MIB [MGT:29] 必须实现.

o 如果路由器具有使用 V.24 signalling 的 interfaces, 例如 RS-232, V.10, V.11, V.35, V.36, 或 RS-422/423/449, 则 RS-232 [MGT:10] MIB 必须实现.

o 如果路由器具有 T1/DS1 interfaces, 则 T1/DS1 MIB [MGT:16] 必须实现.

o 如果路由器具有 T3/DS3 interfaces, 则 T3/DS3 MIB [MGT:17] 必须实现.

o 如果路由器具有 SMDS interfaces, 则 SMDS Interface Protocol MIB [MGT:19] 必须实现.

o 如果路由器在其任一 interface 上支持 PPP, 则 PPP MIBs [MGT:11], [MGT:12], and [MGT:13] 必须实现.

o 如果路由器支持 RIP Version 2, 则 RIP Version 2 MIB [MGT:21] 必须实现.

o 如果路由器在其任一 interface 上支持 X.25, 则 X.25 MIBs [MGT:22, MGT:23 and MGT:24] 必须实现.

8.4 Vendor Specific MIBS

Internet Standard and Experimental MIBs 并未覆盖 network element 中可能可用的全部统计, 状态, 配置和控制信息. 然而, 这些信息极其有用. 路由器 (以及其他网络设备) 的供应商通常 已经开发了覆盖这些信息的 MIB extensions. 这些 MIB extensions 称为 Vendor Specific MIBs.

路由器的 Vendor Specific MIB 必须提供对所有统计, 状态, 配置和控制信息的访问, 这些信息 无法通过已实现的 Standard and Experimental MIBs 获得. 这些信息必须可用于 monitoring 和 control operations.

讨论:

本要求的意图是提供一种能力, 使通过 console 能在路由器上完成的任何操作都能通过 SNMP 完成, 反之亦然. 在 SNMP 能够运行之前, 需要一定的最小配置 (例如, 路由器必须具有 IP address). 这种初始配置无法通过 SNMP 完成. 然而, 一旦完成初始配置, 完整能力就应可通过 network management 获得.

供应商应该提供所有 Vendor Specific MIB variables 的规范. 这些规范必须符合 SMI [MGT:1], 且 descriptions 必须采用 [MGT:4] 中指定的形式.

讨论:

向用户提供 Vendor Specific MIB 是必要的. 如果没有这些信息, 用户将无法配置其 network management systems 以访问 Vendor Specific parameters. 这些参数随后也就没有用处.

注 2 MIB specification 的格式也已被规定. 可读取 MIB specifications 并生成 network management station 所需表的 parsers 已经可用. 这些 parsers 通常只理解标准 MIB specification format.

8.5 Saving Changes

通过 SNMP 更改的参数可以保存到 non-volatile storage.

讨论:

本要求为 MAY 的原因包括:

o 本文档未规定 non-volatile storage 的确切物理性质. 因此, 参数可以保存在 NVRAM/EEPROM, 本地软盘或硬盘, 或某个 TFTP file server 或 BOOTP server 等中. 假设这些信息位于通过 TFTP 获取的文件中. 在这种情况下, 对路由器上 configuration parameter 所做的更改需要传播 回保存 configuration file 的 file server. 或者, SNMP operation 需要定向到 file server, 然后再以某种方式将更改传播到路由器. 该问题的答案并不明显.

这也对保存配置信息的主机提出了比仅具有可用 TFTP server 更多的要求, 多到供应商假设任何 潜在客户都会有合适主机可用可能并不安全.

o 将已更改参数提交到 non-volatile storage 的时机仍是一个有待讨论的问题. 有些人倾向于立即 提交所有更改. 另一些人则倾向于仅在显式命令下将更改提交到 non-volatile storage.

9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS

对于路由器实现的所有附加 application protocols, 路由器必须符合 [INTRO:3] 的相关要求, 并且应该无条件符合这些要求.

9.1 BOOTP

9.1.1 Introduction

Bootstrap Protocol (BOOTP) 是一种基于 UDP/IP 的协议, 它允许正在启动的主机动态且无需用户 监督地配置自身. BOOTP 提供一种方式, 用于通知主机其被分配的 IP address, boot server host 的 IP address, 以及要载入内存并执行的文件名 ([APPL:1]). 其他配置信息, 例如本地 prefix length 或 subnet mask, 本地 time offset, default routers 的地址, 以及各种 Internet servers 的地址, 也可以使用 BOOTP 传达给主机 ([APPL:2]).

9.1.2 BOOTP Relay Agents

在许多情况下, BOOTP clients 及其关联的 BOOTP server(s) 并不位于同一 IP (sub)network 上. 在这种情况下, 需要 third-party agent 在 clients 与 servers 之间传输 BOOTP messages. 这样的 agent 最初称为 BOOTP forwarding agent. 然而, 为避免与路由器的 IP forwarding function 混淆, 后来采用了 BOOTP relay agent 这一名称.

讨论:

BOOTP relay agent 执行的任务不同于路由器通常的 IP forwarding function. 虽然路由器通常或 多或少透明地在网络之间切换 IP datagrams, 但更恰当地说, BOOTP relay agent 接收 BOOTP messages 时可被视为最终目标, 然后由此生成新的 BOOTP messages. 不应认为只需像普通数据包 一样直接转发 BOOTP message.

这种 relay-agent 功能最方便地位于互连 clients 与 servers 的路由器中 (虽然它也可以位于 直接连接到 client (sub)net 的主机中).

路由器可以提供 BOOTP relay-agent capability. 如果提供, 则必须符合 [APPL:3] 中的规范.

Section [5.2.3] 讨论了数据包在何种情况下被本地递送 (递送到路由器). 所有本地递送的 UDP messages, 如果其 UDP destination port number 为 BOOTPS (67), 都会被路由器的 logical BOOTP relay agent 考虑进行特殊处理.

Sections [4.2.2.11] 和 [5.3.7] 讨论了无效 IP source addresses. 根据这些规则, 路由器不得 转发任何 IP source address 为 0.0.0.0 的已接收 datagram. 然而, 支持 BOOTP relay agent 的 路由器必须接受 IP source address 为 0.0.0.0 的 BOOTREQUEST messages, 并将其本地递送给 relay agent.

10. OPERATIONS AND MAINTENANCE

本章取代 [INTRO:3] 中与 "Extensions to the IP Module" 相关的任何要求.

支持 operation and maintenance (O&M) 活动的设施是任何路由器实现的重要组成部分. 尽管这些 功能似乎并不直接关系到互操作性, 但它们对网络管理员至关重要, 因为网络管理员必须使路由器 实现互操作, 并且在互操作失败时追踪问题. 本章还包括对路由器初始化的若干讨论, 以及帮助 网络管理员保护其网络和进行计费的设施.

10.1 Introduction

以下活动类型包含在路由器 O&M 中:

o 诊断路由器处理器, 网络接口, 或其连接的网络, modems 或通信线路中的硬件问题.

o 安装新硬件

o 安装新软件.

o 在崩溃后重新启动或 reboot 路由器.

o 配置 (或重新配置) 路由器.

o 检测和诊断 Internet 问题, 例如 congestion, routing loops, bad IP addresses, black holes, packet avalanches, 以及行为不当的主机.

o 临时 (例如绕过通信线路问题) 或永久更改网络拓扑.

o 监控路由器及其连接网络的状态和性能.

o 收集流量统计, 供 (Inter-)network planning 使用.

o 与适当的供应商和电信专家协调上述活动.

路由器及其连接的通信线路通常由集中式 O&M 组织作为一个系统运行. 该组织可以维护一个 (Inter-)network operation center, 或 NOC, 来执行其 O&M 功能. 路由器必须支持从此类 NOC 通过 Internet path 进行远程控制和监控, 因为路由器可能并未连接到其 NOC 所在的同一网络. 由于网络故障可能临时阻止网络访问, 许多 NOC 坚持要求路由器可通过替代方式进行网络管理 访问, 常见方式是连接到路由器 console ports 的 dial-up modems.

由于穿越 internet 的 IP packet 往往会使用受多个 NOC 控制的路由器, Internet 问题诊断通常 会涉及多个 NOC 人员的协作. 在某些情况下, 同一台路由器可能需要由多个 NOC 监控, 但只有在 必要时才应这样做, 因为过度监控可能影响路由器性能.

NOC 可用的监控工具可能覆盖很宽的复杂度范围. 当前实现包括整个路由器系统的 multi-window, dynamic displays. 未来建议使用 AI 技术进行自动问题诊断.

此处讨论的 Router O&M facilities 只是 Internet management 这一庞大而困难问题的一部分. 这些问题不仅涵盖多个管理组织, 也涵盖多个协议层. 例如, 在当前 Internet 架构演进阶段, host TCP implementations 与路由器系统中最终出现的 IP-level congestion 之间存在强耦合 [OPER:1]. 因此, 诊断 congestion problems 有时需要监控主机中的 TCP statistics. 目前在 Internet management, 更具体地说在 router O&M 领域, 正在进行若干 R&D 工作. 这些 R&D 工作 已经产生了 router O&M 标准. 这也是供应商创造力能够作出重要贡献的领域.

10.2 Router Initialization

10.2.1 Minimum Router Configuration

在路由器可以转发数据包之前, 存在一组必须满足的最小条件. 除非满足以下任一条件, 路由器不得 在任何物理接口上启用 forwarding:

(1) 路由器知道与该物理接口关联的至少一个逻辑接口的 IP address 以及关联的 subnet mask 或 network prefix length, 或者

(2) 路由器知道该接口是 unnumbered interface, 并且知道其 router-id.

这些参数必须显式配置:

o 路由器不得为其 IP addresses, prefix lengths 或 router-id 使用出厂配置的默认值, 并且

o 路由器不得假定未配置的接口是 unnumbered interface.

讨论:

曾经有路由器随接口的 vendor-installed default addresses 一起发货的情况. 在少数情况下, 这导致路由器将这些默认地址通告到活动网络中.

10.2.2 Address and Prefix Initialization

路由器必须允许其 IP addresses 及其 address masks 或 prefix lengths 被静态配置并保存到 non-volatile storage 中.

路由器可以在系统初始化过程的副作用中动态获取其 IP addresses 及其对应的 address masks (见 Section 10.2.3]).

如果提供动态方法, 则必须能够配置特定路由器中要使用的方法选择.

如 Section [4.2.2.11] 中所述, IP addresses 不允许在 或 字段中具有值 0 或 -1. 因此, 路由器不应该允许将 IP address 或 address mask 设置为会使上述 任何字段具有 zero 或 -1 值的值.

讨论:

使用任意 address masks 可能产生 routing 歧义的情况 (即两个具有不同但同等具体 subnet masks 的路由匹配某个特定 destination address). 这是使用 network prefixes 的最有力理由之一, 也是不允许使用 discontiguous subnet masks 的原因.

路由器应该对它安装的任何 address mask 执行以下检查:

o mask 既不是全 1, 也不是全 0 (prefix length 既不是 zero, 也不是 32).

o 与 address 的 network prefix 部分对应的 bits 全部设置为 1.

o 与 network prefix 对应的 bits 是连续的.

讨论:

与路由关联的 masks 有时也称为 subnet masks, 此测试不应应用于它们.

10.2.3 Network Booting using BOOTP and TFTP

关于路由器可以以及应该如何从网络启动, 已有大量讨论. 这些讨论围绕 BOOTP 和 TFTP 展开. 目前, 已有路由器通过 TFTP 从网络启动. 没有理由不能使用 BOOTP 来定位应从中加载 boot image 的服务器.

BOOTP 是一种用于启动 end systems 的协议, 要适应其在路由器中的使用需要一些扩展. 如果路由器 使用 BOOTP 定位当前 boot host, 它应该发送一个 BOOTP Request, 使用其第一个接口的 hardware address; 或者, 如果此前另有配置, 则使用另一个接口的 hardware address, 或另一个放入 BOOTP packet 的 hardware address field 中的编号. 这是为了允许没有 hardware addresses 的路由器 (例如仅有同步线路的路由器) 使用 BOOTP 发现 bootload. 随后可以使用 TFTP 获取 BOOTP Reply 中找到的 image. 如果没有可使用的已配置接口或编号, 路由器可以循环使用它所拥有的接口 hardware addresses, 直到 BOOTP server 找到匹配项.

路由器应该实现将通过 BOOTP 学到的参数保存到本地 non-volatile storage 的能力. 路由器可以 实现将通过网络加载的 system image 保存到本地 stable storage 的能力.

路由器可以具有一种设施, 允许远程用户请求路由器获取新的 boot image. 应区分从以下三个位置 之一获取新的 boot image: 请求中包含的位置, 上一次 boot image server, 以及使用 BOOTP 定位 server.

10.3 Operation and Maintenance

10.3.1 Introduction

在路由器上执行 O&M 功能有一系列可能的模型. 一个极端是 local-only model, 在该模型下 O&M 功能只能本地执行 (例如从插入路由器机器的终端执行). 另一个极端是 fully remote model, 只允许本地执行绝对最少的功能 (例如强制 boot), 大多数 O&M 都从 NOC 远程完成. 也存在中间 模型, 例如 NOC 人员可以使用 Telnet protocol 作为主机登录路由器, 以执行也可本地调用的功能. local-only model 可能足以用于少数路由器安装场景, 但通常需要从 NOC 远程操作, 因而大多数 路由器都需要 remote O&M provisions.

Remote O&M functions 可以通过 control agent (program) 执行. 在直接方法中, 路由器将使用标准 Internet protocols (例如 SNMP, UDP 或 TCP) 直接支持从 NOC 远程执行 O&M 功能; 在间接方法中, control agent 将支持这些协议, 并使用 proprietary protocols 控制路由器本身. 推荐直接方法, 但两种方法都可接受. 不鼓励使用需要显著额外投资的专用 host hardware 和/或 software; 不过, 某些供应商可能选择将 control agent 作为路由器所属网络的集成部分提供. 如果是这种情况, 则要求有一种方式可从远程站点使用 Internet protocols 和 paths 操作 control agent, 且相对于 本地 agent terminal 具有等效功能.

供应商提供的 control agent 和任何其他 NOC software tools 最好作为标准 operating system 中的 user programs 运行. 使用标准 Internet protocols UDP 和 TCP 与路由器通信应该有助于做到这一点.

远程路由器监控以及 (尤其是) 远程路由器控制带来必须处理的重要 access control 问题. 还必须 注意确保控制这些功能对路由器资源的使用. 例如, 不希望让路由器监控占用超过路由器 CPU time 中某个有限比例. 另一方面, O&M 功能必须获得优先级, 以便在路由器拥塞时仍能执行, 因为这往往 正是最需要 O&M 的时候.

10.3.2 Out Of Band Access

路由器必须支持 Out-Of-Band (OOB) access. OOB access 应该提供与 in-band access 相同的功能. 此访问应该实现 access controls, 以防止未经授权的访问.

讨论:

这种 Out-Of-Band access 将允许 NOC 在网络访问不可用时访问孤立的路由器.

Out-Of-Band access 是网络管理员的重要管理工具. 它允许独立于网络连接访问设备. 实现这种访问 有许多方式. 无论使用哪一种方式, 重要的是该访问独立于网络连接. Out-Of-Band access 的一个 示例是连接到 modem 的 serial port, 该 modem 为路由器提供 dial up access.

OOB access 提供与 in-band access 相同的功能很重要. In-band access, 即通过现有网络连接访问 设备, 是有限的, 因为大多数时候管理员需要访问设备来弄清楚它为什么不可达. In-band access 对于配置路由器以及排查更微妙的问题仍然非常重要.

10.3.2 Router O&M Functions

10.3.2.1 Maintenance - Hardware Diagnosis

每台路由器都应该作为独立设备运行, 以用于本地硬件维护. 应该有办法仅使用现场工具在路由器 站点运行 diagnostic programs. 路由器应该能够在故障情况下运行 diagnostics. 建议的硬件和 软件 diagnostics 见 Section [10.3.3].

10.3.2.2 Control - Dumping and Rebooting

路由器必须包含 in-band 和 out-of-band 两种机制, 以允许网络管理员 reload, stop 和 restart 路由器. 路由器还应该包含一种机制 (例如 watchdog timer), 该机制会在路由器因软件或硬件故障 挂起时自动 reboot 路由器.

路由器应该实现一种机制, 用于 dump 路由器内存内容 (和/或崩溃后对供应商调试有用的其他状态), 并将其保存到路由器本地的 stable storage device 上, 或通过 TFTP 等 up-line dump 机制保存到 另一台主机上 (见 [OPER:2], [INTRO:3]).

10.3.2.3 Control - Configuring the Router

每台路由器都有可能需要设置的 configuration parameters. 应该可以在不 reboot 路由器的情况下 更新这些参数; 最坏情况下, 可以要求 restart. 有些情况下可能无法在不 reboot 路由器的情况下 更改参数 (例如更改接口的 IP address). 在这些情况下, 应谨慎尽量减少对路由器及周边网络的 干扰.

应该有一种方式可通过网络手动或自动配置路由器. 路由器应该能够从主机或另一台路由器 upload 或 download 其参数. 应该提供一种手段, 可以作为 application program 或 router function, 在参数格式与 human-editable format 之间转换. 路由器应该具有某种 stable storage 来保存其 配置. 路由器不应该相信 RARP, ICMP Address Mask Reply 等协议, 并且可以不相信 BOOTP.

讨论:

这里有必要指出, 未来可能需要 RARP, ICMP Address Mask Reply, BOOTP 和其他机制来允许路由器 auto-configure. 虽然路由器未来可能能够自动配置, 但这里的意图是在 auto-configuration 得到 更充分测试之前, 不鼓励在生产环境中采用这种做法. 其意图并不是完全不鼓励 auto-configuration. 在预期路由器自动获取配置的情况下, 允许路由器在启动时相信这些信息, 并在获得配置后忽略它们, 可能是明智的.

10.3.2.4 Net Booting of System Software

路由器应该将其 system image 保存在本地 non-volatile storage 中, 例如 PROM, NVRAM 或 disk. 它也可以能够通过网络从主机或另一台路由器加载其 system software.

能够将其 system image 保存在本地 non-volatile storage 中的路由器, 可以配置为通过网络启动 其 system image. 提供此选项的路由器应该可以配置为在无法通过网络启动 system image 时, 启动其 non-volatile local storage 中的 system image.

讨论:

路由器能够自行启动并运行很重要. 对于大型网络中使用的路由器, NVRAM 可能是一种特别的解决 方案, 因为更换 PROMs 对负责众多或地理上分散路由器的网络管理员来说可能非常耗时. 能够 netboot system image 很重要, 因为路由器应有一种简单方式比安装 PROMs 更快地获得 bug fix 或新功能. 此外, 如果路由器使用 NVRAM 而不是 PROMs, 它将 netboot 该 image, 然后将其放入 NVRAM.

路由器应该对加载的任何 image 执行一些基本 consistency check, 以检测并可能防止错误 image.

路由器还可以能够基于其正在运行的软件区分不同配置. 如果 configuration commands 从一个软件 版本到另一个版本发生变化, 路由器能够使用与该软件兼容的配置将很有帮助.

10.3.2.5 Detecting and responding to misconfiguration

必须有机制来检测并响应 misconfigurations. 如果命令执行不正确, 路由器应该给出 error message. 路由器不应该像接受正确命令那样接受格式不良的命令.

讨论:

有些情况下无法检测错误: 命令格式正确, 但相对于网络而言不正确. 路由器可能检测到这一点, 但也可能无法检测.

另一种 misconfiguration 形式是路由器所连接网络的误配置. 路由器可以检测网络中的 misconfigurations. 路由器可以将这些发现记录到文件中, 该文件可以位于路由器上或主机上, 以便网络管理员看到网络上可能存在问题.

讨论:

此类 misconfigurations 的示例可能包括另一台路由器具有与相关路由器相同的地址, 或路由器使用 错误的 address mask. 如果路由器检测到此类问题, 让路由器尝试修复情况很可能不是最佳想法. 那可能弊大于利.

10.3.2.6 Minimizing Disruption

更改路由器配置应该对网络产生最小影响. 对路由器进行简单更改时, 不应该不必要地刷新 routing tables. 如果路由器正在运行多个 routing protocols, 停止一个 routing protocol 不应该干扰其他 routing protocols, 但同一网络由多个 routing protocol 学到的情况除外.

讨论:

网络管理员的目标是运行网络, 使网络用户获得尽可能好的连通性. 因简单配置更改而重新加载路由器 可能导致 routing 中断, 并最终导致网络及其用户中断. 例如, 如果 routing tables 被不必要地刷新, default route 会丢失, 网络内站点的 specific routes 也会丢失. 这种中断会给用户造成显著停机. 本节的目的就是指出, 只要可能, 应避免这些中断.

10.3.2.7 Control - Troubleshooting Problems

(1) 路由器必须提供 in-band network access, 但出于安全考虑, 除 Section [8.2] 要求外, 此访问 应该默认禁用. 供应商必须记录任何 in-band access 的默认状态. 此访问应该实现 access controls, 以防止未经授权的访问.

讨论:

In-band access 主要指通过正常网络协议进行的访问, 这些访问可能影响也可能不影响路由器的永久 运行状态. 这包括但不限于 Telnet/RLOGIN console access 和 SNMP operations.

这是开箱即可运行阵营与开箱安全阵营之间的争议点. 对路由器的任何 automagic access 都可能引入 不安全性, 但对客户来说, 路由器一插上就能通过网络访问可能更重要. 至少有一家供应商提供没有 任何外部 console access 的路由器, 并依赖通过网络访问路由器来完成配置.

in-band access 是否默认启用由供应商决定; 但供应商也有责任让客户了解可能的不安全性.

(2) 路由器必须提供发起 ICMP echo 的能力. 应该实现以下选项:

 o Choice of data patterns

 o Choice of packet size

 o Record route

 并且可以实现以下附加选项:

 o Loose source route

 o Strict source route

 o Timestamps

(3) 路由器应该提供发起 traceroute 的能力. 如果提供 traceroute, 则应该实现 3rd party traceroute.

上述三种设施 (如果实现) 都应该设置访问限制, 以防止未经授权人员滥用.

10.4 Security Considerations

10.4.1 Auditing and Audit Trails

Auditing 和 billing 是网络运营者的苦差事, 但也是负责网络安全者以及负责付账者最常要求的 两个特性. 在安全语境中, 如果 auditing 能帮助保持网络工作并保护资源免遭滥用, 且代价不超过 这些资源本身的价值, 那么 auditing 是可取的.

(1) Configuration Changes

 路由器应该提供一种方法来 audit 路由器的 configuration change, 即使只是记录操作员缩写
 和更改时间这样简单的方式.

讨论:

Configuration change logging (谁做了配置更改, 更改了什么, 以及何时更改) 非常有用, 尤其是 当跨城流量突然经由 Alaska 路由时. 能够恢复到先前配置也同样有用.

(2) Packet Accounting

 强烈建议供应商考虑提供一种系统, 用于跟踪主机对或网络对之间的 traffic levels. 也强烈
 鼓励提供一种机制, 用于将这些信息的收集限制到特定主机对或网络对.

讨论:

如上所述的 host traffic matrix 可以让网络运营者看到其他统计中不明显的流量趋势. 它还可以 识别正在探测所连接网络结构的主机或网络, 例如某个外部主机尝试向连接网络的网络地址范围内 每个 IP address 发送数据包.

(3) Security Auditing

 路由器必须提供一种方法来 audit 与安全相关的 failures 或 violations, 包括:

 o Authorization Failures: bad passwords, invalid SNMP communities, invalid
    authorization tokens,

 o Violations of Policy Controls: Prohibited Source Routes, Filtered Destinations, and

 o Authorization Approvals: good passwords - Telnet in-band access, console access.

 路由器必须提供一种限制或禁用此类 auditing 的方法, 但 auditing 应该默认开启. 可能的
 auditing 方法包括: 如有 console, 将 violations 列出到 console; 在内部记录或计数;
 或通过 SNMP trap mechanism 或 Unix logging mechanism (视情况而定) 将其记录到远程
 security server. 路由器必须实现这些 reporting mechanisms 中的至少一种, 也可以实现多种.

10.4.2 Configuration Control

供应商有责任在为其路由器创建 software/firmware loads 时使用良好的 configuration control practices. 特别是, 如果供应商提供可通过 Internet 获取的 updates 和 loads, 则供应商还应该 提供一种方式, 让客户确认该 load 有效, 例如通过验证该 load 的 checksum.

讨论:

许多供应商目前通过 Internet 提供其软件产品的短期通知 updates. 这是一个好趋势, 应该鼓励, 但它在 configuration control process 中提供了一个脆弱点.

如果供应商提供让客户远程更改路由器 configuration parameters 的能力, 例如通过 Telnet session, 则这种能力应该可配置, 并且应该默认关闭. 路由器在允许 remote reconfiguration 之前应该要求 有效 authentication. 此 authentication procedure 不应该通过网络传输 authentication secret. 例如, 如果实现 telnet, 供应商应该实现 Kerberos, S-Key 或类似 authentication procedure.

讨论:

允许已正确识别的网络运营者调整路由器是必要的; 允许其他任何人这样做则是鲁莽的.

路由器不得具有未记录的 back door access 和 master passwords. 供应商必须确保为调试或产品 开发目的添加的任何此类访问, 在产品分发给客户之前被删除.

讨论:

供应商有责任确保客户了解其代码中有意存在的 vulnerabilities, 例如 in-band access. 无论是有意 还是无意的 trap doors, back doors 和 master passwords, 都可能把相对安全的路由器变成运行网络 中的重大问题. 所谓运行收益与潜在问题并不匹配.

11. REFERENCES

实现者应该知道, Internet protocol standards 偶尔会更新. 这些参考文献在本文撰写时是最新的, 但谨慎的实现者总会检查 RFC index 的较新版本, 以确保某个 RFC 尚未被另一个更新的 RFC 更新或 取代. Reference [INTRO:6] 说明了获取当前 RFC index 的各种方式.

APPL:1. Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford University, Sun Microsystems, September 1985.

APPL:2. Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993.

APPL:3. Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993.

ARCH:1. DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three volumes), DDN Network Information Center, SRI International, Menlo Park, California, USA, December 1985.

ARCH:2. V. Cerf and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communication, May 1974. Also included in [ARCH:1].

ARCH:3. J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet Protocol", Computer Networks, volume 5, number 4, July 1981. Also included in [ARCH:1].

ARCH:4. B. Leiner, J. Postel, R. Cole, and D. Mills, :The DARPA Internet Protocol Suite", Proceedings of INFOCOM '85, IEEE, Washington, DC, March 1985. Also in: IEEE Communications Magazine, March 1985. Also available from the Information Sciences Institute, University of Southern California as Technical Report ISI-RS-85-153.

ARCH:5. D. Comer, "Internetworking With TCP/IP Volume 1: Principles, Protocols, and Architecture", Prentice Hall, Englewood Cliffs, NJ, 1991.

ARCH:6. W. Stallings, "Handbook of Computer-Communications Standards Volume 3: The TCP/IP Protocol Suite", Macmillan, New York, NY, 1990.

ARCH:7. Postel, J., "Internet Official Protocol Standards", STD 1, RFC 1780, Internet Architecture Board, March 1995.

ARCH:8. Information processing systems - Open Systems Interconnection - Basic Reference Model, ISO 7489, International Standards Organization, 1984.

ARCH:9 R. Braden, J. Postel, Y. Rekhter, "Internet Architecture Extensions for Shared Media", 05/20/1994

FORWARD:1. IETF CIP Working Group (C. Topolcic, Editor), "Experimental Internet Stream Protocol", Version 2 (ST-II), RFC 1190, October 1990.

FORWARD:2. Mankin, A., and K. Ramakrishnan, Editors, "Gateway Congestion Control Survey", RFC 1254, MITRE, Digital Equipment Corporation, August 1991.

FORWARD:3. J. Nagle, "On Packet Switches with Infinite Storage", IEEE Transactions on Communications, volume COM-35, number 4, April 1987.

FORWARD:4. R. Jain, K. Ramakrishnan, and D. Chiu, "Congestion Avoidance in Computer Networks With a Connectionless Network Layer", Technical Report DEC-TR-506, Digital Equipment Corporation.

FORWARD:5. V. Jacobson, "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Association for Computing Machinery, August 1988.

FORWARD:6. W. Barns, "Precedence and Priority Access Implementation for Department of Defense Data Networks", Technical Report MTR- 91W00029, The Mitre Corporation, McLean, Virginia, USA, July 1991.

FORWARD:7 Fang, Chen, Hutchins, "Simulation Results of TCP Performance over ATM with and without Flow Control", presentation to the ATM Forum, November 15, 1993.

FORWARD:8 V. Paxson, S. Floyd "Wide Area Traffic: the Failure of Poisson Modeling", short version in SIGCOMM '94.

FORWARD:9 Leland, Taqqu, Willinger and Wilson, "On the Self-Similar Nature of Ethernet Traffic", Proceedings of SIGCOMM '93, September, 1993.

FORWARD:10 S. Keshav "A Control Theoretic Approach to Flow Control", SIGCOMM 91, pages 3-16

FORWARD:11 K.K. Ramakrishnan and R. Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions of Computer Systems, volume 8, number 2, 1980.

FORWARD:12 H. Kanakia, P. Mishara, and A. Reibman]. "An adaptive congestion control scheme for real-time packet video transport", In Proceedings of ACM SIGCOMM 1994, pages 20-31, San Francisco, California, September 1993.

FORWARD:13 A. Demers, S. Keshav, S. Shenker, "Analysis and Simulation of a Fair Queuing Algorithm", 93 pages 1-12

FORWARD:14 Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism", 92 pages 14-26

INTERNET:1. Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

INTERNET:2. Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, Stanford, USC/Information Sciences Institute, August 1985.

INTERNET:3. Mogul, J., "Broadcasting Internet Datagrams in the Presence of Subnets", STD 5, RFC 922, Stanford University, October 1984.

INTERNET:4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.

INTERNET:5. Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991.

INTERNET:6. Braden, R., Borman, D., and C. Partridge, "Computing the Internet Checksum", RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Communications, September 1988.

INTERNET:7. Mallory T., and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, BBN Communications, January 1990.

INTERNET:8. Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.

INTERNET:9. A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder, and R. Zahavi, "Evaluation of Internet Performance - FY89", Technical Report MTR-89W00216, MITRE Corporation, February, 1990.

INTERNET:10. G. Finn, A "Connectionless Congestion Control Algorithm", Computer Communications Review, volume 19, number 5, Association for Computing Machinery, October 1989.

INTERNET:11. Prue, W., and J. Postel, "The Source Quench Introduced Delay (SQuID)", RFC 1016, USC/Information Sciences Institute, August 1987.

INTERNET:12. McKenzie, A., "Some comments on SQuID", RFC 1018, BBN Labs, August 1987.

INTERNET:13. Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.

INTERNET:14. Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.

INTERNET:15 Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy" RFC 1519, BARRNet, cisco, Merit, OARnet, September 1993.

INTERNET:16 St. Johns, M., "Draft Revised IP Security Option", RFC 1038, IETF, January 1988.

INTERNET:17 Prue, W., and J. Postel, "Queuing Algorithm to Provide Type- of-service For IP Links", RFC 1046, USC/Information Sciences Institute, February 1988.

INTERNET:18 Postel, J., "Address Mappings", RFC 796, USC/Information Sciences Institute, September 1981.

INTRO:1. Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.

INTRO:2. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.

INTRO:3. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

INTRO:4. Clark, D., "Modularity and Efficiency in Protocol Implementations", RFC 817, MIT Laboratory for Computer Science, July 1982.

INTRO:5. Clark, D., "The Structuring of Systems Using Upcalls", Proceedings of 10th ACM SOSP, December 1985.

INTRO:6. Jacobsen, O., and J. Postel, "Protocol Document Order Information", RFC 980, SRI, USC/Information Sciences Institute, March 1986.

INTRO:7. Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. This document is periodically updated and reissued with a new number. It is wise to verify occasionally that the version you have is still current.

INTRO:8. DoD Trusted Computer System Evaluation Criteria, DoD publication 5200.28-STD, U.S. Department of Defense, December 1985.

INTRO:9 Malkin, G., and T. LaQuey Parker, Editors, "Internet Users' Glossary", FYI 18, RFC 1392, Xylogics, Inc., UTexas, January 1993.

LINK:1. Leffler, S., and M. Karels, "Trailer Encapsulations", RFC 893, University of California at Berkeley, April 1984.

LINK:2 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer July 1994.

LINK:3 McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, Merit May 1992.

LINK:4 Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, May 1992.

LINK:5 Simpson, W., "PPP Link Quality Monitoring", RFC 1333, Daydreamer, May 1992.

MGT:1. Rose, M., and K. McCloghrie, "Structure and Identification of Management Information of TCP/IP-based Internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.

MGT:2. McCloghrie, K., and M. Rose (Editors), "Management Information Base of TCP/IP-Based Internets: MIB-II", STD 16, RFC 1213, Hughes LAN Systems, Inc., Performance Systems International, March 1991.

MGT:3. Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990.

MGT:4. Rose, M., and K. McCloghrie (Editors), "Towards Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.

MGT:5. Steinberg, L., "Techniques for Managing Asynchronously Generated Alerts", RFC 1224, IBM Corporation, May 1991.

MGT:6. Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., January 1993.

MGT:7. McCloghrie, K., and R. Fox "IEEE 802.4 Token Bus MIB", RFC 1230, Hughes LAN Systems, Inc., Synoptics, Inc., May 1991.

MGT:8. McCloghrie, K., Fox R., and E. Decker, "IEEE 802.5 Token Ring MIB", RFC 1231, Hughes LAN Systems, Inc., Synoptics, Inc., cisco Systems, Inc., February 1993.

MGT:9. Case, J., and A. Rijsinghani, "FDDI Management Information Base", RFC 1512, The University of Tennesse and SNMP Research, Digital Equipment Corporation, September 1993.

MGT:10. Stewart, B., Editor "Definitions of Managed Objects for RS-232- like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992.

MGT:11. Kastenholz, F., "Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP Software, Inc., June 1992.

MGT:12. Kastenholz, F., "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol", RFC 1472, FTP Software, Inc., June 1992.

MGT:13. Kastenholz, F., "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", RFC 1473, FTP Software, Inc., June 1992.

MGT:14. Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991.

MGT:15. Willis, S., and J. Burruss, "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet Communications Inc., October 1991.

MGT:16. Baker, F., and J. Watt, "Definitions of Managed Objects for the DS1 and E1 Interface Types", RFC 1406, Advanced Computer Communications, Newbridge Networks Corporation, January 1993.

MGT:17. Cox, T., and K. Tesink, Editors "Definitions of Managed Objects for the DS3/E3 Interface Types", RFC 1407, Bell Communications Research, January 1993.

MGT:18. McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, August 1992.

MGT:19. Cox, T., and K. Tesink, "Definitions of Managed Objects for the SIP Interface Type", RFC 1304, Bell Communications Research, February 1992.

MGT:20 Baker, F., "IP Forwarding Table MIB", RFC 1354, ACC, July 1992.

MGT:21. Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, Xylogics, Inc., Cisco Systems, November 1994

MGT:22. Throop, D., "SNMP MIB Extension for the X.25 Packet Layer", RFC 1382, Data General Corporation, November 1992.

MGT:23. Throop, D., and F. Baker, "SNMP MIB Extension for X.25 LAPB", RFC 1381, Data General Corporation, ACC, November 1992.

MGT:24. Throop, D., and F. Baker, "SNMP MIB Extension for MultiProtocol Interconnect over X.25", RFC 1461, Data General Corporation, May 1993.

MGT:25. Rose, M., "SNMP over OSI", RFC 1418, Dover Beach Consulting, Inc., March 1993.

MGT:26. Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419, Novell, Inc., Apple Computer, Inc., March 1993.

MGT:27. Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.

MGT:28. Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, NYSERNet, Inc., University of Tennessee at Knoxville, February 1989.

MGT:29. Case, J., "FDDI Management Information Base", RFC 1285, SNMP Research, Incorporated, January 1992.

OPER:1. Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, FACC, January 1984.

OPER:2. Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July 1992.

ROUTE:1. Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994.

ROUTE:2. Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, DEC, December 1990.

ROUTE:3. Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988.

ROUTE:4. Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco, T.J. Watson Research Center, IBM Corp., October 1991.

ROUTE:5. Gross, P, and Y. Rekhter, "Application of the Border Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.

ROUTE:6. Mills, D., "Exterior Gateway Protocol Formal Specification", RFC 904, UDEL, April 1984.

ROUTE:7. Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827, BBN, October 1982.

ROUTE:8. Seamonson, L, and E. Rosen, "STUB" "Exterior Gateway Protocol", RFC 888, BBN, January 1984.

ROUTE:9. Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, BBN, Stanford, November 1988.

ROUTE:10. Deering, S., Multicast Routing in Internetworks and Extended LANs, Proceedings of '88, Association for Computing Machinery, August 1988.

ROUTE:11. Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, Consultant, July 1992.

ROUTE:12. Rekhter, Y., "Experience with the BGP Protocol", RFC 1266, T.J. Watson Research Center, IBM Corp., October 1991.

ROUTE:13. Rekhter, Y., "BGP Protocol Analysis", RFC 1265, T.J. Watson Research Center, IBM Corp., October 1991.

TRANS:1. Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.

TRANS:2. Postel, J., "Transmission Control Protocol", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.

APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS

在符合下面给出的限制条件时, 主机可以能够作为 source route 中的中间跳, 将 source-routed datagram 转发到下一个指定跳.

但是, 在执行这种类似路由器的功能时, 主机必须遵守路由器转发 source-routed datagrams 的所有 相关规则 [INTRO:2]. 这包括以下具体规定:

(A) TTL

 TTL 字段必须按 [INTRO:2] 中对路由器的规定递减, 并且数据报可能被丢弃.

(B) ICMP Destination Unreachable

 主机必须能够生成具有以下 codes 的 Destination Unreachable messages:

 4 (Fragmentation Required but DF Set), 当 source-routed datagram 无法被分片以适配
   target network 时;

 5 (Source Route Failed), 当 source-routed datagram 无法被转发时, 例如由于 routing
   problem, 或者 strict source route 的 next hop 不在 connected network 上.

(C) IP Source Address

 正在转发的 source-routed datagram 可以 (并且通常会) 具有一个并非 forwarding host 的
 IP addresses 之一的 source address.

(D) Record Route Option

 如果主机正在转发包含 Record Route option 的 source-routed datagram, 且该 option 有空间,
 则必须更新该 option.

(E) Timestamp Option

 如果主机正在转发包含 Timestamp Option 的 source-routed datagram, 则必须根据该 option
 的规则向其中加入当前 timestamp.

为定义限制主机转发 source-routed datagrams 的规则, 如果 next hop 将通过该数据报到达时所经 的同一物理接口, 我们使用术语 local source-routing; 否则, 它是 non-local source-routing.

允许主机不受限制地执行 local source-routing.

支持 non-local source-routing 的主机必须具有一个可配置开关来禁用 forwarding, 并且该开关 必须默认禁用.

主机必须满足针对限制 non-local forwarding 的 configurable policy filters 的所有路由器要求 [INTRO:2].

如果主机收到带有 incomplete source route 的数据报, 但出于某种原因未转发它, 则主机应该返回 ICMP Destination Unreachable (code 5, Source Route Failed) 消息, 除非该数据报本身是 ICMP error message.

APPENDIX B. GLOSSARY

本附录定义本备忘录中使用的特定术语. 它还定义了一些可能有用的通用术语. 更通用的定义集合 另见 [INTRO:9].

Autonomous System (AS)

 Autonomous System (AS) 是网络拓扑的一个连通片段, 由一组 subnetworks (附有 hosts) 以及
 将它们互连的一组 routes 组成. 这些 subnetworks 和 routers 预期由单一 operations and
 maintenance (O&M) 组织控制. 在一个 AS 内, 路由器可以使用一个或多个 interior routing
 protocols, 有时还使用多组 metrics. 预期 AS 向其他 AS 呈现出一致的内部 routing plan
 外观, 以及可通过该 AS 到达的 destinations 的一致图景. AS 由 Autonomous System number
 标识.

Connected Network

 路由器所接入的 network prefix 通常称为 local network 或该路由器的 subnetwork. 但是,
 这些术语可能造成混淆, 因此本备忘录使用术语 Connected Network.

Connected (Sub)Network

 Connected (Sub)Network 是路由器所接入的 IP subnetwork, 或者如果 connected network
 未子网化, 则为 connected network. 另见 Connected Network.

Datagram

 在一对 internet modules 之间传输的单位. 数据, 称为 datagrams, 从源到目标传输. Internet
 Protocol 不提供可靠通信设施. 既没有端到端 acknowledgments, 也没有 hop-by-hop
 acknowledgments. 没有 error retransmissions. 没有 flow control. 见 IP.

Default Route

 routing table entry, 用于引导任何寻址到 routing table 中未显式列出的 network prefixes
 的数据.

Dense Mode

 在 multicast forwarding 中, 可能有两种范式: 在 Dense Mode forwarding 中, network
 multicast 会作为 data link layer multicast 转发到除接收接口之外的所有接口, 除非且直到
 multicast routing neighbor 指示路由器不要这样做. 见 Sparse Mode.

EGP

 Exterior Gateway Protocol. 一种向连接 autonomous systems 的 gateways (routers) 分发
 routing information 的协议. 见 IGP.

EGP-2

 Exterior Gateway Protocol version 2. 这是一种 EGP routing protocol, 开发用于处理
 Internet 中 Autonomous Systems 之间的流量.

Forwarder

 路由器内负责在路由器接口之间 switching packets 的逻辑实体. Forwarder 还作出决策:
 将 packet 排队等待 local delivery, 将 packet 排队从另一个接口传输, 或二者都做.

Forwarding

 Forwarding 是路由器对收到的每个 packet 执行的过程. 该 packet 可以被路由器消费, 可以
 从路由器的一个或多个接口输出, 或二者都发生. Forwarding 包括决定如何处理该 packet 的
 过程, 以及将其排队等待 (可能的) 输出或内部消费.

Forwarding Information Base (FIB)

 在本文档中, 包含转发 IP Datagrams 所需信息的表称为 Forwarding Information Base.
 至少, 它为每个可达 destination network prefix 包含 interface identifier 和 next hop
 information.

Fragment

 一个 IP datagram, 表示较高层 packet 的一部分, 该 packet 过大而无法通过 output network
 整体发送.

General Purpose Serial Interface

 一种物理介质, 能够精确连接两个系统, 因而可配置为 point to point line, 但也可配置为
 使用 X.25 或 Frame Relay 等协议支持 link layer networking. link layer network 将另一个
 系统连接到 switch, 而较高通信层在该连接上复用 virtual circuits. 见 Point to Point Line.

IGP

 Interior Gateway Protocol. 一种在 Autonomous System (AS) 内分发 routing information 的
 协议. 见 EGP.

Interface IP Address

 分配给路由器某个特定接口的 IP Address 和 network prefix length.

Internet Address

 标识 internet 中某台主机的 assigned number. 它有两部分: IP address 和 prefix length.
 prefix length 指示该 address 中有多少个最具体 bits 构成 network prefix.

IP

 Internet Protocol. Internet 的 network layer protocol. 它是 RFC 791 中定义的 packet
 switching, datagram protocol. IP 不提供可靠通信设施; 也就是说, 没有端到端或 hop-by-hop
 acknowledgments.

IP Datagram

 IP Datagram 是 Internet Protocol 中的端到端传输单位. IP Datagram 由 IP header 后跟所有
 higher-layer data (例如 TCP, UDP, ICMP 等) 组成. IP Datagram 是 IP header 后跟 message.

 IP Datagram 是完整的 IP 端到端传输单位. IP Datagram 由一个或多个 IP Fragments 组成.

 在本备忘录中, 未限定的术语 Datagram 应理解为指 IP Datagram.

IP Fragment

 IP Fragment 是 IP Datagram 的组成部分. IP Fragment 由 IP header 后跟原始 IP Datagram
 的全部或部分 higher-layer 组成.

 一个或多个 IP Fragments 构成单个 IP Datagram.

 在本备忘录中, 未限定的术语 Fragment 应理解为指 IP Fragment.

IP Packet

 IP Datagram 或 IP Fragment.

 在本备忘录中, 未限定的术语 Packet 通常应理解为指 IP Packet.

Logical [network] interface

 我们将 logical [network] interface 定义为到 connected network 的一条逻辑路径, 该路径
 由唯一 IP address 区分.

Martian Filtering

 包含无效 source 或 destination address 的 packet 被认为是 martian 并被丢弃.

MTU (Maximum Transmission Unit)

 可以通过 logical interface 传输或接收的最大 packet 的大小. 此大小包括 IP header, 但不
 包括任何 Link Layer headers 或 framing 的大小.

Multicast

 以多个 hosts 为目标的 packet. 见 broadcast.

Multicast Address

 一种特殊类型的 address, 可由多个 hosts 识别.

 Multicast Address 有时称为 Functional Address 或 Group Address.

Network Prefix

 IP Address 中表示一组系统的部分. 它通过将 subnet mask 与 address 进行逻辑 AND 从 IP
 Address 中选出, 或者等价地, 将 address 中不属于最重要 <prefix-length> bits 的 bits
 设置为 zero.

Originate

 路由器传输 packets 可能有两个原因: 1) packet 已被接收且正在转发, 或 2) 路由器自身创建
 该 packet 用于传输 (例如 route advertisements). 由路由器创建用于传输的 packets 称为在
 该路由器处 originate.

Packet

 Packet 是跨 Internet Layer 与 Link Layer 之间接口传递的数据单位. 它包括 IP header 和
 data. Packet 可以是完整 IP datagram, 也可以是 IP datagram 的一个 fragment.

Path

 packet 从某个特定路由器到某个特定 destination host 所穿越的 routers 和 (sub-)networks
 序列. 注意, path 是单向的; 给定 host pair 两个方向上具有不同 paths 并不少见.

Physical Network

 Physical Network 是在 Link Layer 上连续的网络 (或 internet 的一部分). 其内部结构
 (如果有) 对 Internet Layer 透明.

 在本备忘录中, 使用 bridges 或 repeaters 等设备连接的若干 media components 被视为单个
 Physical Network, 因为这类设备对 IP 透明.

Physical Network Interface

 这是到 Connected Network 的物理接口, 并具有一个 (可能唯一的) Link-Layer address.
 单台路由器上的多个 Physical Network Interfaces 可以共享同一个 Link-Layer address,
 但同一 Physical Network 上不同路由器的该 address 必须唯一.

Point to Point Line

 一种能够精确连接两个系统的物理介质. 在本文档中, 仅在用于连接 IP entities 时才用它
 指此类线路. 见 General Purpose Serial Interface.

router

 一种特殊用途的专用计算机, 用于连接多个网络. 路由器通过称为 forwarding 的过程在这些
 网络之间切换 packets. 多个路由器可以对单个 packet 重复此过程, 直到该 packet 能够交付
 给最终目标, 即 packet 从 router 到 router 再到 router... 直到到达其目标.

RPF

 Reverse Path Forwarding - 一种用于推导 broadcast 和 multicast packets 的 next hops 的方法.

Silently Discard

 本备忘录规定了若干路由器要 Silently Discard 收到的 packet (或 datagram) 的情况. 这表示
 路由器应丢弃该 packet 而不进一步处理, 并且路由器不会因此发送任何 ICMP error message
 (见 Section [4.3.2]). 但是, 为诊断问题, 路由器应该提供记录该错误的能力 (见 Section
 [1.3.3]), 包括 silently discarded packet 的内容, 并且应该在 statistics counter 中记录
 该事件.

Silently Ignore

 如果路由器对某个 error 或 condition 不采取任何动作, 除了可能在 error log 或通过某种
 network management protocol 生成 error report, 并丢弃或忽略该 error 的 source, 则称该
 路由器 Silently Ignore 该 error 或 condition. 特别是, 路由器不生成 ICMP error message.

Sparse Mode

 在 multicast forwarding 中, 可能有两种范式: 在 Sparse Mode forwarding 中, network layer
 multicast datagram 会作为 data link layer multicast frame 转发给已请求它的 routers 和
 hosts. 初始 forwarding state 与 dense-mode 相反, 因为它假设网络中没有任何部分需要这些
 data. 见 Dense Mode.

Specific-destination address

 除非 IP header 包含 IP broadcast 或 IP multicast address, 否则它定义为 IP header 中的
 destination address; 在包含 IP broadcast 或 IP multicast address 的情况下,
 specific-destination 是分配给该 packet 到达的物理接口的 IP address.

subnet

 网络的一部分, 可以是物理上独立的网络, 它与网络的其他部分共享一个 network address,
 并由 subnet number 区分. subnet 之于 network, 如同 network 之于 internet.

subnet number

 internet address 中指定 subnet 的部分. 它在 internet routing 中被忽略, 但用于 intranet
 routing.

TOS

 Type Of Service. IP header 中的一个字段, 表示 transport layer 或 application 对 network
 layer 期望的可靠性程度.

TTL

 Time To Live. IP header 中的一个字段, 表示 packet 被认为有效的时长. 它是 hop count 和
 timer value 的组合.

APPENDIX C. FUTURE DIRECTIONS

本附录列出本文档未来修订可能希望处理的工作.

在准备 Router Requirements 时, 我们偶然遇到了若干其他架构问题. 文档中已在一定程度上处理了 这些问题中的每一个, 但它们仍应被归类为 IP architecture 中的开放问题.

这里给出的大多数主题通常表示技术仍相对较新, 不适合制定具体要求, 因为社区仍在积累运行经验.

其他主题代表正在进行的研究领域, 并指出谨慎的开发者会密切跟踪的领域.

(1) SNMP Version 2

(2) Additional SNMP MIBs

(7) 关于 routing protocols 之间 leaking routes 的更详细要求

(8) Router system security

(9) Routing protocol security

(10) Internetwork Protocol layer security. 自最初编写本文档以来, 已经有大量工作在完善 IP 的安全性. 这些安全工作应该包含在这里.

(12) Load Splitting

(13) 沿不同路径发送 fragments

(15) 同一 wire 上的多个 logical (sub)nets. Router Requirements 不要求支持这一点. 我们曾尝试 识别架构中的若干部分 (例如 directed broadcasts 的转发以及 Redirects 的发出), 在这些 部分中必须谨慎措辞规则, 以便发生正确的行为, 并尝试清楚地区分 logical interfaces 与 physical interfaces. 然而, 我们没有详细研究此问题, 也完全没有信心认为在同一 wire 上 存在多个 logical (sub)nets 时, 本文档中的所有规则都是正确的.

(15) Congestion control and resource management. 根据 IETF 专家 (Mankin 和 Ramakrishnan) 的 建议, 我们废弃了 (SHOULD NOT) Source Quench, 除此之外很少给出具体内容 (Section 5.3.6).

(16) 制定一个 routers 和 hosts 共用的 Link-Layer requirements document.

(17) 制定一个通用 PPP LQM algorithm.

(18) 调查除 Section [3.2] 以外在各层之间传递的其他信息, 例如 physical network MTU, IP precedence 到 Link Layer priority values 的映射等.

(19) 如果 address resolution 失败, Link Layer 是否应该通知 IP (就像存在 Link Layer priority value problem 时通知 IP 一样)?

(20) 是否应该要求所有路由器实现 DNS resolver?

(21) 配置路由器时, 人类用户是否应该能够在任何可使用 IP address 的地方使用 host name? 即使 在 ping 和 traceroute 中也是如此?

(22) Almquist 关于 next hop 的 draft ruminations 和关于 route leaking 的 ruminations 需要 审查, 更新并发布.

(23) 需要调查是否需要针对 precedence 的 redirect message. 如果不需要, type-of-service redirects 是否可接受?

(24) RIPv2 和 RIP+CIDR 以及 variable length network prefixes.

(25) BGP-4 CIDR 将很重要, 并且所有人都押注于 BGP-4. 我们无法避免提及它. 可能需要描述 BGP-3 和 BGP-4 之间的差异, 并探讨升级问题...

(26) Loose Source Route Mobile IP 和某些 multicasting 可能需要这一点. 也许它应提升为 SHOULD (按 Fred Baker 的建议).

APPENDIX D. Multicast Routing Protocols

Multicasting 是 Internet Protocol family 中相对较新的技术. 它尚未广泛部署或普遍使用. 但是, 预期其重要性将在未来几年增长.

本附录描述了一些正在研究的技术, 用于在 Internet 中路由 multicasts.

勤勉的实现者将持续关注该领域的发展, 以便正确开发 multicast facilities.

本附录不规定任何标准或要求.

D.1 Introduction

Multicast routing protocols 使 IP multicast datagrams 能够在整个 TCP/IP internet 中转发. 通常, 这些算法基于数据报的 source 和 destination addresses 转发该数据报. 此外, 数据报可能 需要转发给多个 multicast group members, 有时需要复制该数据报并从多个接口发出.

multicast routing protocols 的状态不如 IP unicasts 转发所可用的协议成熟. 已经为 TCP/IP 记录了三种实验性 multicast routing protocols. 每种协议都使用 IGMP protocol (Section [4.4] 中讨论) 来监控 multicast group membership.

D.2 Distance Vector Multicast Routing Protocol - DVMRP

[ROUTE:9] 中记录的 DVMRP 基于 Distance Vector 或 Bellman-Ford 技术. 它仅路由 multicast datagrams, 并且在单个 Autonomous System 内执行此操作. DVMRP 是 [ROUTE:10] 中描述的 Truncated Reverse Path Broadcasting algorithm 的一种实现. 此外, 它还规定了通过不具备 multicast-routing-capable 的 IP domains 隧道化 IP multicasts.

D.3 Multicast Extensions to OSPF - MOSPF

MOSPF 目前正在开发中, 是对 OSPF 的一种向后兼容扩展, 允许在 Autonomous System 内转发 IP multicasts 和 unicasts. MOSPF routers 可以与 OSPF routers 混合在同一 routing domain 内, 并且它们将在 unicasts 转发中互操作. OSPF 是一种 link-state 或基于 SPF 的协议.

通过添加精确标识 group membership 的 link state advertisements, MOSPF routers 可以将 multicast datagram 的路径计算为一棵以数据报源为根的树. 随后可以丢弃不包含 group members 的分支, 从而消除不必要的数据报转发跳.

D.4 Protocol Independent Multicast - PIM

PIM 目前正在开发中, 是一种运行在现有 unicast infrastructure 之上的 multicast routing protocol. PIM 支持 dense 和 sparse 两种 group membership. 它不同于其他协议, 因为它对 sparse groups 使用显式 join model. 加入发生在 shared tree 上, 并且可以切换到 per-source tree. 在带宽充足且 group membership 稠密的地方, 可以通过向所有链路 flood 数据, 再随后 prune 没有 group members 的例外情况, 来降低开销.

APPENDIX E Additional Next-Hop Selection Algorithms

Section [5.2.4.3] 规定了路由器在为 packet 选择 next-hop 时应使用的算法.

本附录为 next-hop selection problem 提供历史视角. 它还给出了 Internet 中可能存在的若干附加 pruning rules 和 next-hop selection algorithms.

本附录给出的材料来自 Philip Almquist 较早但未发布的作品: Ruminations on the Next Hop.

本附录不规定任何标准或要求.

E.1. Some Historical Perspective

简要回顾该主题的历史是有用的, 可从有时称为路由器如何作出 routing decisions 的 "classic model" 开始. 该模型早于 IP. 在此模型中, 路由器运行某种单一 routing protocol, 例如 RIP. 该协议完全决定路由器 Forwarding Information Base (FIB) 的内容. route lookup algorithm 很 简单: 路由器在 FIB 中查找 destination attribute 与 packet 中 destination address 的 network prefix 部分完全匹配的路由. 如果找到, 则使用它; 如果未找到, 则 destination unreachable. 由于 routing protocol 对每个 destination 最多保留一条路由, 因此不会出现有多条 routes 匹配 同一 destination 时该怎么办的问题.

多年来, 该 classic model 已以小幅方式扩展. 随着 default routes, subnets 和 host routes 的 部署, 某种意义上可能有多个 routing table entry 匹配 destination. 这很容易通过以下共识解决: 存在路由层次结构: host routes 应优先于 subnet routes, subnet routes 优先于 net routes, net routes 优先于 default routes.

随着支持 variable length subnet masks (variable length network prefixes) 的技术部署, 总体 方法保持不变, 尽管其描述变得稍微复杂; network prefixes 被有意识地引入, 作为架构上的简化和 规范化. 现在我们说每条到 network prefix 的 route 都有关联的 prefix length. 此 prefix length 表示 prefix 中的 bit 数. 这也可以使用传统 subnet mask 表示. 除非 route 的 network prefix 中每个 significant bit 都匹配 packet 的 destination address 中相应的 bit, 否则该 route 不能用于路由 packet. mask 中设置更多 bits 的 routes 优先于 mask 中设置较少 bits 的 routes. 这只是上述路由层次结构的一般化, 在本备忘录其余部分中称为通过偏好 longest match 来选择路由.

classic model 的另一种扩展方式, 是稍微放松 routing protocol 完全控制 routing table 内容这一 观念. 首先, 引入了 static routes. 这是首次可能同时拥有到同一 destination 的两条 routes (一条 dynamic, 一条 static). 当这种情况发生时, 路由器必须有一项 policy (某些情况下可配置, 其他情况下由路由器软件作者选择), 用于确定优先使用 static route 还是 dynamic route. 但是, 只有当 longest match 不能唯一确定应使用哪条 route 时, 才使用此 policy 作为 tie-breaker. 因此, 例如, 即使 policy 偏好 static routes 而不是 dynamic routes, static default route 也 永远不会优先于 dynamic net route.

当 inter-domain routing protocols 被发明时, classic model 必须进一步扩展. 传统 routing protocols 被称为 "interior gateway protocols" (IGPs), 并且在每个 Internet site 中出现了一种 奇怪的新生物, 称为 "exterior gateway": 一台同时与若干 "BBN Core Gateways" (当时构成 Internet backbone 的路由器) 运行 EGP, 又与其站点内其他路由器运行 IGP 的路由器. 两个协议都 想决定路由器 routing table 的内容. 理论上, 这可能导致路由器拥有到同一 destination 的三条 routes (EGP, IGP 和 static). 由于当时的 Internet topology, 几乎没有争论就确定了路由器最好 采用优先 IGP routes 而非 EGP routes 的策略. 然而, longest match 的神圣性仍未受到质疑: 从 IGP 学到的 default route 永远不会优先于从 EGP 学到的 net route.

尽管 Internet topology 以及 Internet 中的 routing 自那以后已显著演化, 但这种略微扩展的 classic model 至今仍在 Internet 中完整保留 (只是 BGP 已取代 EGP). 从概念上说 (并且通常在 实现中), 每台路由器都有一个 routing table 和一个或多个 routing protocol processes. 这些 processes 中每一个都可以添加其想添加的任何 entry, 并可以删除或修改其创建的任何 entry. 在路由 packet 时, 路由器使用 longest match 选择最佳 route, 并辅以 policy mechanism 来打破 平局. 虽然这种扩展的 classic model 很好地服务了我们, 但它有若干缺点:

o 它忽略了 (尽管可扩展为考虑) path characteristics, 例如 quality of service 和 MTU.

o 它不支持需要不同于纯 longest match 的 route lookup algorithms 的 routing protocols (例如 OSPF 和 Integrated IS-IS).

o 对于 tie-breaking mechanism 应该是什么, 一直没有坚定共识. 人们经常发现 tie-breaking mechanisms 难以甚至不可能配置为使路由器总能选择 network manager 认为 "correct" 的 route.

E.2. Additional Pruning Rules

Section [5.2.4.3] 定义了若干 pruning rules, 用于从 FIB 中选择 routes. 也可以使用其他规则.

o OSPF Route Class

具有 areas 或区分 internal 和 external routes 的 routing protocols, 按计算 route 所用信息 的类型将其 routes 划分为 classes. 除非没有最优先 class 的 route 可用, 否则总是从最优先 class 中选择 route; 如果没有, 则从第二优先 class 中选择, 依此类推. 在 OSPF 中, classes (从最优先到最不优先) 为 intra-area, inter-area, type 1 external (external routes with internal metrics), 以及 type 2 external. 另一个细节是, 路由器被配置为知道哪些 addresses 应该可通过 intra-area routes 访问, 并且即使没有 intra-area route 可用, 也不会使用 inter-area 或 external routes 到达这些 destinations.

更准确地说, 我们假设每条 route 都有一个 class attribute, 称为 route.class, 由 routing protocol 分配. 检查 candidate routes 集合, 以确定其中是否包含 route.class = intra-area 的 route. 如果有, 则丢弃除 route.class = intra-area 的 routes 以外的所有 routes. 否则, 路由器 检查 packet 的 destination 是否落入为 local area 配置的 address ranges 内. 如果是, 则删除 整个 candidate routes 集合. 否则, 检查 candidate routes 集合, 以确定其中是否包含 route.class = inter-area 的 route. 如果有, 则丢弃除 route.class = inter-area 的 routes 以外 的所有 routes. 否则, 检查 candidate routes 集合, 以确定其中是否包含 route.class = type 1 external 的 route. 如果有, 则丢弃除 route.class = type 1 external 的 routes 以外的所有 routes.

o IS-IS Route Class

IS-IS route classes 的工作方式与 OSPF 的相同. 但是, Integrated IS-IS 定义的 classes 集合 不同, 因而 IS-IS route classes 与 OSPF route classes 之间不存在一一映射. Integrated IS-IS 使用的 route classes (从最优先到最不优先) 为 intra-area, inter-area 和 external.

Integrated IS-IS internal class 等价于 OSPF internal class. 同样, Integrated IS-IS external class 等价于 OSPF 的 type 2 external class. 但是, Integrated IS-IS 不区分 inter-area routes 和 external routes with internal metrics, 二者都被视为 inter-area routes. 因此, OSPF 偏好 真正的 inter-area routes, 而不是 external routes with internal metrics; 而 Integrated IS-IS 对这两类 routes 给予相同 preference.

o IDPR Policy

Policy 的一个具体情形. IETF 的 Inter-domain Policy Routing Working Group 正在设计一种名为 Inter-Domain Policy Routing (IDPR) 的 routing protocol, 以支持 Internet 中真正的 policy-based routing. 具有某些 header attributes 组合 (例如特定 source 和 destination addresses 组合, 或特殊 IDPR source route options) 的 packets 被要求使用 IDPR protocol 提供 的 routes. 因此, 不同于其他 Policy pruning rules, IDPR Policy 必须在除 Basic Match 外的 任何其他 pruning rules 之前应用.

具体而言, IDPR Policy 检查正在转发的 packet, 以确定其 attributes 是否要求使用 policy-based routes 转发. 如果是, IDPR Policy 删除所有并非由 IDPR protocol 提供的 routes.

E.3 Some Route Lookup Algorithms

本节考察若干正在使用或已被提议的 route lookup algorithms. 每个算法都通过给出其使用的 pruning rules 序列来描述. 同时给出每个算法的优势和劣势.

E.3.1 The Revised Classic Algorithm

Revised Classic Algorithm 是 Section [E.1] 中讨论的传统算法形式. 此算法的步骤是:

1. Basic match
2. Longest match
3. Best metric
4. Policy

某些实现省略 Policy 步骤, 因为只有当 routes 可能具有不可比较的 metrics (因为它们是从不同 routing domains 学到的) 时才需要此步骤.

此算法的优势是:

(1) 它已被广泛实现.

(2) 除 Policy 步骤外 (实现者可以选择使其任意复杂), 该算法既易于理解也易于实现.

其劣势是:

(1) 它不处理 IS-IS 或 OSPF route classes, 因此不能用于 Integrated IS-IS 或 OSPF.

(2) 它不处理 TOS 或其他 path attributes.

(3) policy mechanisms 没有以任何方式标准化, 因此通常依赖具体实现. 这给实现者 (必须发明适当 policy mechanisms) 和用户 (必须学习如何使用这些 mechanisms) 都带来额外工作. 缺乏标准化 mechanism 也使得为来自不同供应商的路由器构建一致配置变得困难. 这对 multi-vendor interoperability 构成显著实际障碍.

(4) 供应商当前提供的 proprietary policy mechanisms 在 Internet 的复杂部分通常并不充分.

(5) 该算法没有写入任何普遍可用的文档或标准. 实际上, 它是 Internet Folklore 的一部分.

E.3.2 The Variant Router Requirements Algorithm

一些 Router Requirements Working Group 成员提出了 Section [5.2.4.3] 中描述算法的一个小变体. 在此变体中, 匹配所请求的 type of service 被认为比尽可能多地匹配 destination address 更重要, 而不是更不重要. 例如, 该算法会偏好具有正确 type of service 的 default route, 而不是具有 default type of service 的 network route; 而 [5.2.4.3] 中的算法会作出相反选择.

该算法的步骤是:

1. Basic match
2. Weak TOS
3. Longest match
4. Best metric
5. Policy

此算法的支持者与常规 Router Requirements Algorithm 的支持者之间的争论表明, 双方都能展示 其算法比对方算法导致更简单, 更直观 routing 的情形. 除了在 Longest Match 之前对 Weak TOS 进行 pruning 使该算法比标准 Router Requirements Algorithm 更不兼容 OSPF 和 Integrated IS-IS 之外, 此变体具有与 [5.2.4.3] 中规定算法相同的一组优势和劣势.

E.3.3 The OSPF Algorithm

OSPF 使用的算法几乎与 Router Requirements Algorithm 完全相同, 只有一个关键差异: OSPF 考虑 OSPF route classes.

该算法是:

1. Basic match
2. OSPF route class
3. Longest match
4. Weak TOS
5. Best metric
6. Policy

Type of service 支持并不总是存在. 如果不存在, 当然会省略第四步.

与 Revised Classic Algorithm 相比, 此算法有一些优势:

(1) 它支持 type of service routing.

(2) 它的规则已被写下, 而不仅仅是 Internet folklore 的一部分.

(3) 它 (显然) 适用于 OSPF.

但是, 此算法也保留了 Revised Classic Algorithm 的一些劣势:

(1) type of service 以外的 path properties (例如 MTU) 被忽略.

(2) 与 Revised Classic Algorithm 一样, Policy 步骤的细节 (甚至是否存在) 留给实现者自行决定.

OSPF Algorithm 还有一个进一步的劣势 (Revised Classic Algorithm 没有这一点). OSPF internal (intra-area 或 inter-area) routes 总是被认为优于从其他 routing protocols 学到的 routes, 即使 OSPF route 匹配的 destination address bits 更少. 这是一个在某些网络中不适当的 policy decision.

最后, 值得注意的是, OSPF Algorithm 的 TOS 支持存在一个缺陷: 在转发具有非零 TOS 值的 packets 时, 支持 TOS 的 routing protocols 会被隐式优先选用. 在某些情况下这可能并不适当.

E.3.4 The Integrated IS-IS Algorithm

Integrated IS-IS 使用的算法与 OSPF Algorithm 类似, 但并不完全相同. Integrated IS-IS 使用一组 不同的 route classes, 并且在处理 type of service 时略有不同. 该算法是:

1. Basic Match
2. IS-IS Route Classes
3. Longest Match
4. Weak TOS
5. Best Metric
6. Policy

尽管 Integrated IS-IS 使用 Weak TOS, 该协议只能携带 IP header 中 TOS 字段可能值的一小部分 特定子集的 routes. TOS 字段中包含其他值的 packets 使用 default TOS 路由.

Type of service 支持是可选的; 如果禁用, 则省略第四步. 与 OSPF 一样, 规范不包含 Policy 步骤.

与 Revised Classic Algorithm 相比, 此算法有一些优势:

(1) 它支持 type of service routing.

(2) 它的规则已被写下, 而不仅仅是 Internet folklore 的一部分.

(3) 它 (显然) 适用于 Integrated IS-IS.

但是, 此算法也保留了 Revised Classic Algorithm 的一些劣势:

(1) type of service 以外的 path properties (例如 MTU) 被忽略.

(2) 与 Revised Classic Algorithm 一样, Policy 步骤的细节 (甚至是否存在) 留给实现者自行决定.

(3) 由于 IS-IS route classes 与 OSPF route classes 之间存在差异, 它不适用于 OSPF. 此外, 由于 IS-IS 只支持可能 TOS values 的一个子集, Integrated IS-IS algorithm 的某些明显实现 不会支持 OSPF 对 TOS 的解释.

Integrated IS-IS Algorithm 还有一个进一步的劣势 (Revised Classic Algorithm 没有这一点): IS-IS internal (intra-area 或 inter-area) routes 总是被认为优于从其他 routing protocols 学到的 routes, 即使 IS-IS route 匹配的 destination address bits 更少, 且不提供所请求的 type of service. 这是一个并非在所有情况下都适当的 policy decision.

最后, 值得注意的是, Integrated IS-IS Algorithm 的 TOS 支持存在与 OSPF Algorithm 所述相同的 缺陷.

Security Considerations

尽管本文档的重点是互操作性而非安全性, 但本文档显然有许多章节对网络安全有一定影响.

不同的人对 security 有不同理解. 从路由器的角度看, security 是任何有助于保持自身网络运行, 并且还帮助保持整个 Internet 健康的东西. 就本文档而言, 我们关注的 security services 是 denial of service, integrity, 以及适用于前两者的 authentication. Privacy 作为 security service 很重要, 但至少截至本文档日期, 它只是路由器的边缘关注点.

本文档中有若干位置包含题为 ... Security Considerations 的章节. 这些章节讨论适用于正在讨论的 一般主题的具体考虑事项.

本文档很少会说: 做这件事, 你的路由器/网络就会安全. 更可能的说法是: 这是个好主意, 如果这样做, 它 may 总体上改善 Internet 和你的本地系统的安全性.

遗憾的是, 这就是目前的技术水平. 路由器关注的网络协议中, 很少甚至没有具有合理内建安全特性的 协议. 业界和协议设计者过去一直并且仍在继续努力处理这些问题. 已有进展, 但只是很小的 baby steps, 例如 BGP 和 OSPF routing protocols 中可用的 peer-to-peer authentication.

特别是, 本文档注意到当前正在开展的网络安全开发和增强研究. 截至本文撰写时 (December 1993), 正在进行的具体 research, development, and engineering 领域包括 IP Security, SNMP Security, 以及通用 authentication technologies.

尽管如此, 供应商和用户都可以采取一些措施来提高其路由器的安全性. 供应商应该获取 Trusted Computer System Interpretation [INTRO:8] 的副本. 即使供应商决定不按这些指南提交其设备进行 正式验证, 该出版物也为计算设备的一般安全设计和实践提供了优秀指导.

APPENDIX F: HISTORICAL ROUTING PROTOCOLS

某些 routing protocols 在 Internet 中很常见, 但本文档作者无法真诚地推荐使用它们. 这并不是 因为它们不能正确工作, 而是因为其设计所假定的 Internet 特性 (简单 routing, 无 policy, 共同 管理下的单一 "core router" network, 有限复杂性, 或有限 network diameter) 并不是今日 Internet 的属性. Internet 中仍在使用它们的部分通常是复杂性有限的 "fringe" domains.

出于诚信, 本节记录了关于其实现的汇集智慧.

F.1 EXTERIOR GATEWAY PROTOCOL - EGP

F.1.1 Introduction

Exterior Gateway Protocol (EGP) 规定了一种 EGP, 用于在相同或不同 autonomous systems 的路由器 之间交换 reachability information. EGP 不被认为是一种 routing protocol, 因为 EGP update message 中 distance fields 没有标准解释 (即 metric), 因此 distances 只在同一 AS 的路由器之间 可比较. 不过, 它旨在提供高质量的 reachability information, 包括关于 neighbor routers 的信息 以及关于到 non-neighbor routers 的 routes 的信息.

EGP 由 [ROUTE:6] 定义. 实现者几乎肯定还想阅读 [ROUTE:7] 和 [ROUTE:8], 因为它们包含有用的 解释和背景材料.

讨论:

现行 EGP 规范有严重限制, 最重要的是一项限制: 路由器只能通告可从该路由器 autonomous system 内部到达的网络. 这种反对传播 third party EGP information 的限制是为了防止长期存在的 routing loops. 这实际上将 EGP 限制为两级层次结构.

RFC-975 不是 EGP 规范的一部分, 应予忽略.

F.1.2 Protocol Walk-through

Indirect Neighbors: RFC-888, page 26

 EGP 实现必须包含 indirect neighbor 支持.

Polling Intervals: RFC-904, page 10

 Hello command 重传之间的间隔以及 Poll 重传之间的间隔应该可配置, 但必须定义最小值.

 实现响应 Hello commands 和 Poll commands 的间隔应该可配置, 但必须定义最小值.

Network Reachability: RFC-904, page 15

实现必须默认不提供其他 autonomous systems 中 routers 的 external list; Update Response/Indication packet 中应该只包含 internal list of routers 以及可通过这些 routers 到达 的 nets. 但是, 实现可以选择提供一个配置选项以启用提供 external list. 实现不得在 external list 中包含通过另一个 autonomous system 中路由器提供的 external list 学到的 routers. 实现不得 将 network 发回其学习来源的 autonomous system, 即它必须在 autonomous system 级别执行 split-horizon.

如果 Network Reachability update 中需要指定超过 255 个 internal routers 或 255 个 external routers, 则无法列出的 routers 可到达的 networks 必须合并到某个已列出 router 的列表中. 为此 选择哪个已列出 router 应该可由用户配置, 但应该默认使用正在生成的 EGP update 的 source address.

EGP update 包含一系列 network numbers 块, 每个块包含可通过特定 router 以特定 distance 到达的 network numbers 列表. 如果通过特定 router 以特定 distance 可到达超过 255 个 networks, 它们会 拆分为多个 blocks (所有这些 blocks 具有相同 distance). 类似地, 如果列出可通过特定 router 到达的 networks 需要超过 255 个 blocks, 则该 router 的 address 会按必要次数列出, 以便在 update 中包含所有 blocks.

Unsolicited Updates: RFC-904, page 16

如果某个 network 与 peer 共享, 则当进入 Up state 且 source network 是该 shared network 时, 实现必须发送 unsolicited update.

Neighbor Reachability: RFC-904, page 6, 13-15

page 6 中描述 j 和 k (neighbor up 和 down thresholds) 值的表是错误的. 正确表格在此重现:

 Name    Active  Passive Description
 -----------------------------------------------
  j         3       1    neighbor-up threshold
  k         1       0    neighbor-down threshold

RFC-904, page 14 中 passive mode 下 k 的值也指定错误. 括号中的值应为:

 (j = 1, k = 0, and T3/T1 = 4)

作为优化, 当 Poll 到期时, 实现可以不发送 Hello command. 如果实现这样做, 它应该提供用户可配置 选项来禁用此优化.

Abort timer: RFC-904, pages 6, 12, 13

EGP 实现必须包含对 abort timer 的支持 (如 RFC-904 Section 4.1.4 中所记录). 实现应该在 Idle state 中使用 abort timer 自动发出 Start event 来重启 protocol machine. 推荐值是: 对 critical error (Administratively prohibited, Protocol Violation 和 Parameter Problem) 使用 P4, 对所有 其他错误使用 P5. 当 Stop event 是手动发起时 (例如通过 network management protocol), 不应该 启动 abort timer.

Cease command received in Idle state: RFC-904, page 13

当 EGP state machine 处于 Idle state 时, 它必须用 Cease-ack response 回复 Cease commands.

Hello Polling Mode: RFC-904, page 11

EGP 实现必须包含对 active 和 passive polling modes 的支持.

Neighbor Acquisition Messages: RFC-904, page 18

如前所述, Hello and Poll Intervals 应该只出现在 Request 和 Confirm messages 中. 因此, EGP Neighbor Acquisition Message 的长度对于 Request 或 Confirm message 是 14 bytes, 对于 Refuse, Cease 或 Cease-ack message 是 10 bytes. 实现不得为 Refuse, Cease 或 Cease-ack messages 发送 14 bytes, 但必须允许有实现为这些 messages 发送 14 bytes.

Sequence Numbers: RFC-904, page 10

收到 sequence number 不等于 S 的 response 或 indication packets 必须被丢弃. send sequence number S 必须仅在 Poll command 发送之前递增, 不得在其他任何时候递增.

F.2 ROUTING INFORMATION PROTOCOL - RIP

F.2.1 Introduction

RIP 在 [ROUTE:3] 中规定. 尽管 RIP 在 Internet 中仍相当重要, 但在复杂应用中, 它正被上述更现代 的 IGPs 取代. 实现 RIP 的路由器应该实现 RIP Version 2 [ROUTE:?], 因为它支持 CIDR routes. 如果使用 occasional access networking, 实现 RIP 的路由器应该实现 Demand RIP [ROUTE:?].

RIP 的另一种常见用途是作为 router discovery protocol. Section [4.3.3.10] 简要涉及此主题.

F.2.2 Protocol Walk-Through

Dealing with changes in topology: [ROUTE:3], page 11

 RIP 实现必须提供一种使 routes 超时的手段. 由于 messages 偶尔会丢失, 实现不得基于单次
 missed update 使 route 无效.

 实现默认必须等待 update interval 的六倍之后才使 route 无效. 路由器可以有配置选项来
 更改此值.

讨论:

对于 routing stability, RIP autonomous system 中所有路由器使用类似的 timeout value 来使 routes 无效很重要, 因此实现默认使用 RIP 规范中指定的 timeout value 很重要.

但是, 在 packet loss 相当少见的环境中, 该 timeout value 过于保守. 在此类环境中, 网络管理员 可能希望能够缩短 timeout period, 以促进从故障中更快恢复.

实现:

路由器可以使用一种非常简单的机制, 来满足 routes 超时后及时使其无效的要求. 每当路由器扫描 routing table 以查看是否有 routes 已超时时, 它还记录尚未超时的 least recently updated route 的 age. 从 timeout period 中减去此 age, 就得到路由器再次需要扫描表以查找 timed out routes 之前的时间.

Split Horizon: [ROUTE:3], page 14-15

RIP 实现必须实现 split horizon, 这是一种用于避免在发送给某路由器的 updates 中包含从该路由器 学到的 routes 所导致问题的方案.

RIP 实现应该实现 Split horizon with poisoned reverse, 这是 split horizon 的一种变体, 它在 发送给某路由器的内容中包含从该路由器学到的 routes, 但将其 metric 设置为 infinity. 由于实现 split horizon with poisoned reverse 可能产生 routing overhead, 实现可以包含一个选项, 用于选择 poisoned reverse 是否生效. 实现应该限制它以 infinite metric 发送 reverse routes 的时间.

实现:

以下每种算法都可用于限制 poisoned reverse 应用于某条 route 的时间. 第一种算法更复杂, 但更 彻底地将 poisoned reverse 限制在必要情形中.

两种算法的目标都是确保对任何在最近 Route Lifetime (通常为 180 seconds) 内 route 已改变的 destination 执行 poison reverse, 除非能够确定之前的 route 使用了相同 output interface. 使用 Route Lifetime 是因为这是 RIP 在声明旧 route stale 之前保留旧 route 的时间.

以下算法中使用的时间间隔 (以及派生变量) 如下:

Tu The Update Timer; RIP updates 之间的秒数. 这通常默认为 30 seconds.

Rl The Route Lifetime, in seconds. 这是在不要求 update 的情况下 route 被假定为 good 的时间. 这通常默认为 180 seconds.

Ul The Update Loss; RIP 删除 route 之前必须连续丢失或未提及某 route 的 updates 数. Ul 计算为 (Rl/Tu)+1. +1 是为了考虑以下事实: ifcounter 第一次递减会在其初始化后少于 Tu seconds 发生. 通常, Ul 为 7: (180/30)+1.

In 新学到 destination 时要将 ifcounter 设置为的值. 该值是 Ul-4, 其中 4 是 RIP 的 garbage collection timer/30.

第一种算法是:

• 每个 destination 都关联一个 counter, 下面称为 ifcounter. 对 destination 的 ifcounter 大于 zero 的任何 route 执行 Poison reverse.

• 发送 regular (非 triggered 且非响应 request) update 后, 所有非零 ifcounters 递减一.

• 当创建到某个 destination 的 route 时, 其 ifcounter 按如下方式设置:

  • 如果 new route 正在取代 valid route, 并且 old route 使用不同的 (logical) output interface, 则 ifcounter 设置为 Ul.

  • 如果 new route 正在取代 stale route, 并且 old route 使用不同的 (logical) output interface, 则 ifcounter 设置为 MAX(0, Ul - INT(seconds that the route has been stale/Ut).

  • 如果此前没有到该 destination 的 route, 则 ifcounter 设置为 In.

  • 否则, ifcounter 设置为 zero

• RIP 还维护一个 timer, 下面称为 resettimer. 只要 resettimer 尚未过期, 就对所有 routes 执行 Poison reverse (无论 ifcounter values 如何).

• 当 RIP 启动, 重启, reset, 或以其他方式清空其 routing table 时, 它将 resettimer 设置为在 Rl seconds 后触发.

第二种算法与第一种相同, 但有以下不同:

• 将 ifcounter 设置为非零值的规则改为始终将其设置为 Rl/Tu, 并且

• 删除 resettimer.

Triggered updates: [ROUTE:3], page 15-16; page 29

Triggered updates (也称为 flash updates) 是一种机制, 用于当路由器添加或删除 routes 或更改其 metrics 时立即通知路由器的 neighbors. 当 routes 被删除或其 metrics 增加时, 路由器必须发送 triggered update. 当 routes 被添加或其 metrics 降低时, 路由器可以发送 triggered update.

由于 triggered updates 可能导致过多 routing overhead, 实现必须使用以下机制限制 triggered updates 的频率:

(1) 当路由器发送 triggered update 时, 它将 timer 设置为未来一到五秒之间的随机时间. 在此 timer 过期之前, 路由器不得生成额外 triggered updates.

(2) 如果路由器会在此间隔内生成 triggered update, 它设置一个 flag, 表示需要 triggered update. 路由器还记录所需的 triggered update.

(3) 当 triggered update timer 过期时, 路由器检查 triggered update flag. 如果该 flag 已设置, 则路由器发送一个包含所有已记录 changes 的单个 triggered update. 随后路由器清除此 flag, 并且由于已发送 triggered update, 重新启动此算法.

(4) 每当发送 regular update 时, 该 flag 也被清除.

Triggered updates 应该包含自最近一次 regular (non-triggered) update 以来发生变化的所有 routes. Triggered updates 不得包含自最近一次 regular update 以来未发生变化的 routes.

讨论:

在 triggered updates 中发送所有 routes, 无论它们最近是否发生变化, 是不可接受的, 因为许多 Internet routing tables 的巨大规模否则可能导致在 triggered updates 上浪费大量带宽.

Use of UDP: [ROUTE:3], page 18-19.

发送到 IP broadcast address 的 RIP packets 应该将其 initial TTL 设置为 one.

请注意, 为符合本备忘录 Section [6.1], 路由器应该在其发起的 RIP packets 中使用 UDP checksums, 必须丢弃收到的具有 invalid UDP checksums 的 RIP packets, 但不得仅因为收到的 RIP packets 不 包含 UDP checksums 而丢弃它们.

Addressing Considerations: [ROUTE:3], page 22

RIP 实现应该支持 host routes. 如果不支持, 则必须 (如 [ROUTE:3] page 27 所述) 忽略收到的 updates 中的 host routes. 路由器可以记录被忽略的 hosts routes.

特殊地址 0.0.0.0 用于描述 default route. default route 用作 last resort 的 route (即当 routing table 中不存在到 specific net 的 route 时). 路由器必须能够为地址 0.0.0.0 创建 RIP entry.

Input Processing - Response: [ROUTE:3], page 26

处理 update 时, 必须执行以下 validity checks:

o response 必须来自 UDP port 520.

o source address 必须位于 directly connected subnet (或 directly connected, non-subnetted network) 上才被视为有效.

o source address 不得是路由器的某个地址.

讨论:

某些 networks, media 和 interfaces 允许发送节点接收它广播的 packets. 路由器不得将自己的 packets 作为有效 routing updates 接受并处理. 最后一项要求防止路由器接受并处理自己的 routing updates (假设它们是由网络上的其他路由器发送的).

如果收到的 metric 等于现有 metric, 实现不得替换现有 route, 除非按照以下 heuristic 执行.

实现可以选择实现以下 heuristic 来处理上述情况. 通常, 如果两台路由器都以相同 metric 通告到 某网络的 route, 则将 route 从一台路由器改为另一台路由器没有用. 但是, 其中一台路由器通告的 route 可能正在超时. 与其等待 route timeout, 不如在经过指定时间后使用新 route. 如果实现此 heuristic, 它必须至少等到过期点的一半之后才安装新 route.

F.2.3 Specific Issues

RIP Shutdown

RIP 实现应该使用以下步骤提供 graceful shutdown:

(1) Input processing 终止,

(2) 在二到四秒之间的随机间隔生成四个 updates. 这些 updates 包含此前宣布的所有 routes, 但带有 某些 metric changes. 此前以 infinity metric 宣布的 routes 应继续使用该 metric. 此前以 non-infinite metric 宣布的 routes 应以 metric 15 (infinity - 1) 宣布.

讨论:

上述真正应该使用的 metric 是 16 (infinity); 将其设置为 15 是一种 kludge, 用于避免破坏某些 wiretap RIP protocol 的旧主机. 如果这样的主机在没有到 destination 的 route 时尝试在连接上 发送 datagram, 它会 (错误地) abort TCP connection (即使主机没有 route 的时间只持续几秒钟, 在此期间 RIP 选择到 destination 的备用路径).

RIP Split Horizon and Static Routes

默认情况下, Split horizon 应该应用于 static routes. 实现应该提供一种方式, 可针对每条 static route 指定不应将 split horizon 应用于该 route.

F.3 GATEWAY TO GATEWAY PROTOCOL - GGP

Gateway to Gateway protocol 被认为已过时, 不应该实现.

致谢

O that we now had here But one ten thousand of those men in England That do no work to-day!

What's he that wishes so? My cousin Westmoreland? No, my fair cousin: If we are mark'd to die, we are enow To do our country loss; and if to live, The fewer men, the greater share of honour. God's will! I pray thee, wish not one man more. By Jove, I am not covetous for gold, Nor care I who doth feed upon my cost; It yearns me not if men my garments wear; Such outward things dwell not in my desires: But if it be a sin to covet honour, I am the most offending soul alive. No, faith, my coz, wish not a man from England: God's peace! I would not lose so great an honour As one man more, methinks, would share from me For the best hope I have. O, do not wish one more! Rather proclaim it, Westmoreland, through my host, That he which hath no stomach to this fight, Let him depart; his passport shall be made And crowns for convoy put into his purse: We would not die in that man's company That fears his fellowship to die with us. This day is called the feast of Crispian: He that outlives this day, and comes safe home, Will stand a tip-toe when the day is named, And rouse him at the name of Crispian. He that shall live this day, and see old age, Will yearly on the vigil feast his neighbours, And say 'To-morrow is Saint Crispian:' Then will he strip his sleeve and show his scars. And say 'These wounds I had on Crispin's day.' Old men forget: yet all shall be forgot, But he'll remember with advantages What feats he did that day: then shall our names. Familiar in his mouth as household words Harry the king, Bedford and Exeter, Warwick and Talbot, Salisbury and Gloucester,

Be in their flowing cups freshly remember'd. This story shall the good man teach his son; And Crispin Crispian shall ne'er go by, From this day to the ending of the world, But we in it shall be remember'd; We few, we happy few, we band of brothers; For he to-day that sheds his blood with me Shall be my brother; be he ne'er so vile, This day shall gentle his condition: And gentlemen in England now a-bed Shall think themselves accursed they were not here, And hold their manhoods cheap whiles any speaks That fought with us upon Saint Crispin's day.

                               -- William Shakespeare

本备忘录是 IETF Router Requirements Working Group 的成果. 像这样的备忘录必然凝聚了许多 人的工作, 其人数远超此处所能列出者. 来自 Internet community 的众多 vendors, network managers 以及其他专家慷慨贡献了他们的时间和智慧, 以提升本备忘录的质量. 编辑谨向他们所有人致以诚挚谢意.

当前编辑还希望特别指出并向本文档的原编辑 Philip Almquist 表达由衷的感谢和敬意. 如果没有 Philip 作为原编辑以及工作组主席所做的工作, 本文档就不会产生. 他还希望向前任编辑 Frank Kastenholz 表达深切而由衷的感谢. Frank 将原始文档从信息集合转变为一份有用的 IP 技术描述, 用他的话说, 是 1991 年该技术的一张 "snapshot". 只能希望这份关于 1994 年技术的 snapshot 同样清晰.

Philip Almquist, Jeffrey Burgan, Frank Kastenholz 和 Cathy Wittbrodt 分别撰写了本备忘录的主要章节. 对本文档作出重要贡献的其他人包括 Bill Barns, Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve Knowles, Yoni Malachi, Michael Reilly 和 Walt Wimer.

其他文本来自 Andy Malis, Paul Traina, Art Berggreen, John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, 以及其他被无意遗漏的人.

本备忘录中的部分文本 (毫不掩饰地) 剽借自早期文档, 尤其是 Bob Braden 和 Host Requirements Working Group 撰写的 RFC-1122, 以及 Bob Braden 和 Jon Postel 撰写的 RFC-1009. 特此感谢这些早期作者的工作.

Jim Forster 在 Router Requirements Working Group 早期会议期间担任共同主席, 并在帮助该组顺利起步方面发挥了重要作用. Jon Postel, Bob Braden 和 Walt Prue 也通过在该组第一次会议之前提供大量良好建议, 为成功作出了贡献. 后来, Phill Gross, Vint Cerf 和 Noel Chiappa 都提供了宝贵的建议和支持.

Mike St. Johns 协调了 Working Group 与 security community 的互动, Frank Kastenholz 协调了 Working Group 与 network management area 的互动. Allison Mankin 和 K.K. Ramakrishnan 就 congestion control 和 resource allocation 问题提供了专业知识.

参与 Router Requirements Working Group 讨论的人数远远超过此处可能列出或致谢的人数, 他们通过电子邮件或参加会议参与其中. 不过, 特别感谢 Ross Callon 和 Vince Fuller 在厘清 route choice 和 route leaking 等困难问题方面所做的努力.

编辑感谢他的雇主 Cisco Systems 允许他投入生成这份 1994 snapshot 所需的时间.

编辑地址

本文档当前编辑的地址是

  Fred Baker
  Cisco Systems
  519 Lado Drive
  Santa Barbara, California 93111
  USA

  Phone:+1 805-681-0115

  EMail: [email protected]