逐跳选项头（Hop-by-Hop Options Header）是IPv6协议中的一种扩展头部，它允许在数据包传输过程中每个跃点（路由器或节点）都能够读取并处理该头部中的信息。逐跳选项头的设计初衷是为了提供一种机制，在整个传输路径上对IP数据包进行特定操作。
然而，由于所有中间设备都需要处理逐跳选项头，这可能导致每台设备解析和处理逐跳选项头会增加网络延迟和处理开销，特别是在大规模网络中，可能成为潜在的瓶颈。同时扩大了攻击面，恶意用户可能会利用逐跳选项头发送特制的数据包来实施攻击。防火墙和其他安全设备需要正确识别和处理逐跳选项头，否则可能导致误判或者绕过安全策略。兼容性也存在问题，并非所有网络设备都支持逐跳选项头，且部分设备可能出于安全考虑默认禁用对其的处理。
鉴于以上原因，许多现代网络设备选择不启用或限制对IPv6逐跳选项头的支持。同时，RFC 8200更新了IPv6规范，建议在非实验环境中慎用逐跳选项头，并指出大部分网络功能可以通过其他扩展头部实现，例如目的地选项头等。
逐跳选项头用于点对点连接，主要在 HTTP/1.1 中用于管理两个节点（如客户端代理或代理代理）之间的数据，并且不意味着转发。 标准逐跳标头包括 Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization 和 Proxy-Authenticate，如 RFC 2616 中所定义。
背景
在 IPv6 规范的第一个版本中，所有节点、路由器和主机都需要处理逐跳选项。由于多种因素，这被证明在高速路由器中不实用，包括：
- 无法在硬件中以线速处理逐跳选项。
- 逐跳选项将被发送到"慢速路径"。这可能会降低路由器的性能及其处理重要控制流量的能力。
- 强制外部数据包到达路由器"慢速路径"的机制可能会被利用作为对路由器的拒绝服务攻击。
- 数据包可能包含多个逐跳选项，这会增加处理它们所需的复杂性，从而使之前的问题变得更糟。
当 IPv6 规范于 2017 年 7 月更新并发布为 [ RFC8200 ]时，与逐跳选项相关的过程如下：
- 扩展标头（逐跳选项标头除外）不会被数据包传送路径上的任何节点处理、插入或删除，直到数据包到达该节点（或每个节点集，在这种情况下）多播）在 IPv6 标头的目标地址字段中标识。
- 逐跳选项标头不会被插入或删除，但可以由数据包传送路径上的任何节点检查或处理，直到数据包到达该节点（或在多播情况下到达节点组中的每个节点）在 IPv6 标头的目标地址字段中标识。逐跳选项标头（如果存在）必须紧跟在 IPv6 标头之后。它的存在由 IPv6 标头的下一个标头字段中的零值指示。
- 注意：虽然 [RFC2460] 要求所有节点必须检查和处理逐跳选项标头，但现在预计数据包传送路径上的节点仅在明确配置为时检查和处理逐跳选项标头这样做。
这些更改意味着即使不处理逐跳选项，实现也符合 IPv6 规范，并且预计路由器将添加配置信息来控制它们将处理哪些逐跳选项。
不幸的是，这并没有改进逐跳选项的处理，并且它们通常无法在互联网中部署和使用。它只是记录了它们在互联网上的使用方式。
事后看来，逐跳选项在互联网上广泛使用仍然不切实际。许多运行的路由器被配置为丢弃所有包含逐跳选项标头的数据包。主要问题仍然存在：
- 路由器已配置为丢弃将在快速路径中处理的中转数据包，这包括丢弃需要在快速路径中处理的逐跳数据包。
- 在单个数据包中允许多个逐跳选项使得在快速路径中处理这些数据包的路由器资源更加昂贵。它增加了可能需要处理的排列数量的复杂性。
- 任何可以在外部使用的强制数据包进入路由器慢速路径的机制都可以通过使路由器管理协议（例如，路由协议、网络管理协议等）所需的资源饱和而被利用作为对中转路由器的拒绝服务攻击。这可能会导致路由器出现故障。[ RFC6398 ]中讨论了路由器警报选项的这个问题，该选项故意将数据包放置在慢速路径上。本 RFC 第 3 节包含一个很好的总结：
"简而言之，IP 路由器警报选项没有提供一种方便的通用机制来准确、可靠地区分感兴趣的 IP 路由器警报数据包和不需要的 IP 路由器警报数据包。这反过来又会在 IP 路由器警报选项出现时产生安全问题。使用选项是因为，如果缺乏适当的路由器实现特定机制，路由器慢速路径就有被不需要的流量淹没的风险。"
有一些学术研究讨论了丢弃包含 IPv6 扩展标头（包括逐跳选项标头）的数据包的一般问题。例如，[ Hendriks ]指出"丢弃所有带有扩展标头的数据包是一种不好的做法"，并且"然而，包含多个 EH 的流量份额非常小。对于能够处理动态特性的硬件设计的 EH，因此我们建议支持至少一个 EH"
本文档定义了一组逐跳选项标头的过程，使逐跳选项的处理在现代中转路由器中变得实用。
逐跳报头处理过程
本节描述了对[ RFC8200 ]的三组更改。
1. 每个数据包的逐跳选项
RFC8200 \]第 4.3 节中定义的逐跳选项标头由 IPv6 标头中的下一个标头值 0 来标识。第 4.1 节要求逐跳选项标头紧接在 IPv6 标头之后出现。 \[ RFC8200 \]还要求逐跳选项标头只能在数据包中出现一次。 \[ RFC8200 \] 中定义的逐跳选项标头可以包含一个或多个逐跳选项。本文档更新了\[ RFC8200 \]，使得单个数据包的逐跳选项标头中只能包含一个选项。此更改的动机是简化快速路径中逐跳选项的处理。 创建具有逐跳选项标头的数据包的节点必须在数据包中仅包含一个选项。这还要求所有逐跳选项必须是 8 字节对齐的。详细信息请参见第 6 节。 如果该标头中存在多个逐跳选项，则处理带有逐跳选项标头的数据包的节点必须丢弃该数据包。 #### 2. 逐跳标头处理 \[ RFC8200 \]的第4.2节定义了选项中的选项类型字段，用于控制在处理选项标头的IPv6节点无法识别选项类型的情况下如何处理选项。本文档以两种方式修改逐跳选项标头中携带的选项的行为。 如果可以在路由器的快速路径中完成，IPv6 节点必须仅处理逐跳选项标头。如果 IPv6 节点无法处理快速路径中的逐跳选项标头，则必须跳过此选项并继续正常处理标头。 \[ RFC8200 \] 的第 4.2 节 将选项类型标识符定义为内部编码，以便它们的最高 2 位指定在处理 IPv6 节点无法识别选项类型时必须采取的操作。本文档修改了逐跳选项的此行为，如下所示： 00 - 跳过此选项并继续处理标头。 01 - 丢弃数据包。 10 - 丢弃数据包。 11 - 丢弃数据包。 此更改的动机是简化路由器在无法识别选项类型时需要在快速路径中执行的操作。不再需要发送 ICMP 参数问题消息。 #### 3. 配置 \[ RFC8200 \]第 4 节 允许路由器通过本地配置控制其对 IPv6 逐跳选项的处理。正文为： > 注意：虽然 \[RFC2460\] 要求所有节点必须检查和处理逐跳选项标头，但现在预计数据包传送路径上的节点仅在明确配置为时检查和处理逐跳选项标头这样做。 实现此目的的一种可能方法是根据快速路径中支持的 IPv6 选项的选项类型维护一个查找表。这将允许节点快速确定选项是否受支持并且可以被处理。如果不支持该选项，则节点将按照本文档第 5.2 节中的描述对其进行处理。 查找表的操作应该可以由路由器的操作员配置。 ### 逐跳选项头对齐 每个扩展标头的长度都是 8 八位字节的整数倍，以便为后续标头保留 8 八位字节对齐。 如果目标选项头或逐跳选项头中的选项不导致 8 字节对齐，则定义两种类型的 Pad 选项来保持这种对齐，即 Pad1 和 PadN。 本文档要求所有逐跳选项均按 8 字节对齐（参见第 5.1 节）。这消除了在逐跳选项标头中使用 Pad 选项以使它们对齐 8 字节的需要。 当前定义的目的地和逐跳选项列表可以在\[ IANA-HBH \]中找到。 以下部分列出了当前的逐跳选项，这些选项满足此处定义的对齐要求，或者是否需要弃用或修改它们。已弃用的逐跳选项和目标选项在第 6.3 节中单独列出。Pad 选项（Pad1 和 PadN）和 RFC3692 式实验选项未列出。 #### 1. 满足对齐要求的逐跳选项 以下逐跳选项满足本节中定义的对齐要求： * 巨型有效负载\[ RFC2675
- 路径 MTU 记录选项[ ID.ietf-6man-mtu-option ]
- RPL 选项[ ID.ietf-roll-useofrplinfo ]
- 快速入门[ RFC4782 ]
- 卡利普索[ RFC5570 ]
- SMF_DPD [ RFC6621 ]
- ILNP 随机数[ RFC6744 ]
- MPL 选项[ RFC7731 ]
注意：需要验证这些选项是否是 8 字节对齐的。
2. 必须弃用或修改的逐跳选项
本节中列出的逐跳选项不满足本节中定义的对齐要求。它们需要被弃用或修改以支持 8 字节对齐而不使用 Pad 选项。如果有兴趣修改它们，应该很容易使它们具有 8 八位字节对齐。
- 路由器警报[ RFC2711 ]
- IP_DFF [ RFC6971 ]
- IOAM [ ID.ietf-ippm-ioam-ipv6-options ]
3. 目的地选项和已弃用的逐跳选项
本节中列出的选项是"目标选项"或"已弃用的逐跳选项"。8 字节对齐不是问题。
- 隧道封装限制[ RFC2473 ]
- RPL 选项（已弃用）[ RFC6553 ]
- 端点识别（已弃用）[CHARLES LYNN]
- MPL 选项（已弃用）[ RFC7731 ]
- 家庭地址[ RFC6275 ]
- 线路识别选项[ RFC6788 ]
- 性能和诊断指标 (PDM) [ RFC8250 ]
新的逐跳选项
未来定义的任何新的 IPv6 Hop-by-Hop 选项都应该具有 8 字节对齐，而不使用任何 Pad 选项。该要求修改了[ RFC8200 ]的第 4.8 节。
规范性引用文件
-
IANA-HBH\] "目标选项和逐跳选项"，\
-
RFC8174\] Leiba, B.，"RFC 2119 关键字中大写与小写的歧义"，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月，\< https://www.rfc-editor.org/info/rfc8174 \>。
参考资料
Hendriks\] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. Aiko, "Threats and Surprises behind IPv6 Extension Headers", , , August 2017,