9.1 封装在 IP 中的 IP 数据包

IP 数据包头部封装在许多地方用于隧道, 包括 IPsec 和 IP in IP [RFC2003]. 本节考虑 ECN 与 IP 隧道交互相关的问题, 并规定两种替代解决方案. RFC 2983 关于 Differentiated Services 与各种形式 IP 隧道交互的讨论 [RFC2983] 对此讨论形成补充, 因为 Differentiated Services 使用 ECN 所用 IP 头部字节中的其余六个 bit (见第 5 节图 2).

某些 IP 隧道模式基于添加新的 "outer" IP header, 该头部封装原始或 "inner" IP header 及其关联数据包. 在许多情况下, 新的 "outer" IP header 可以在连接沿途的中间点添加和移除, 从而允许网络建立隧道而不要求端点参与. 我们把在隧道出口丢弃外层头部的隧道称为 "simple tunnels".

ECN 使用 IP 头部中的 ECN 字段在路由器和连接端点之间发信号. ECN 与 IP 隧道的交互基于 IP 隧道内 IP 头部中 ECN 字段的处理. 在简单 IP 隧道中, 包含 ECN 字段的字节在 IP 隧道入口处从内层 IP 头部复制或映射到外层 IP 头部, 并且外层头部中的该字段副本在 IP 隧道出口处被丢弃. 如果外层头部被简单丢弃, 而没有注意处理 ECN 字段, 并且 ECN-capable 路由器在简单 IP 隧道内的数据包中设置 CE (Congestion Experienced) codepoint, 则该指示会在隧道出口被丢弃, 从而丢失拥塞指示.

因此, 在简单 IP 隧道上使用 ECN 将导致路由器试图使用外层 IP 头部向端点发送拥塞信号, 但这些拥塞警告永远无法到达, 因为外层头部在隧道出口点被丢弃. RFC 2481 遇到了 ECN 与隧道模式 IPsec 的这一问题, 并建议不要将 ECN 与较旧的简单 IPsec 隧道一起使用, 以避免这种行为及其后果. 当 ECN 被广泛部署时, 可能承载 ECN-capable 流量的简单隧道必须被修改. 如果 ECN-capable 流量通过一个包含拥塞 ECN-capable 路由器的简单隧道传输, 则随着拥塞路由器处平均队列大小增加, 这可能导致该流的后续数据包被丢弃, 如上文第 8 节所讨论.

从安全角度看, 在 IP 隧道的外层头部中使用 ECN 可能引发安全担忧, 因为对手可能篡改会传播到隧道端点之外的 ECN 信息. 基于第 18 和第 19 节中对这些问题及其风险的分析, 我们的总体方法是使 ECN 支持成为 IP 隧道的一个选项, 以便可以指定或配置 IP 隧道是否在隧道外层头部中使用 ECN. 因此, 在认为使用 ECN 的风险超过其收益的环境或隧道协议中, 隧道可以简单地不在外层头部中使用 ECN. 这样, 隧道内路由器遇到拥塞的唯一指示将通过数据包丢弃来提供.

因此, 对 IP 隧道 (包括 IPsec 隧道) 上 ECN-capable 连接的行为, 存在两个可行选项:

limited-functionality option, 其中 ECN 保留在内层头部中, 但在外层头部中禁用. 在这种情况下, 指示隧道内发生拥塞的唯一机制是丢失的数据包.
full-functionality option, 其中内层和外层头部都支持 ECN, 并且来自隧道内节点的拥塞警告会传播到端点.

支持这些选项需要对隧道入口和出口处的 IP 头部处理作不同程度的修改. 只支持 limited-functionality option 所需的一小部分修改, 足以消除 ECN 与 IP 隧道之间的任何不兼容.

本文档的一个目标是就 limited-functionality 和 full-functionality 选项之间的权衡提供指导. 第 18 和第 19 节详细讨论对手修改 ECN 字段的潜在影响.

9.1 封装在 IP 中的 IP 数据包​

9.1 封装在 IP 中的 IP 数据包