解析包含未知扩展的 IPv6 扩展标头答案

【问题标题】：Parsing IPv6 extension headers containing unknown extensions解析包含未知扩展的 IPv6 扩展标头
【发布时间】：2013-07-05 07:57:38
【问题描述】：

我正在编写一个非常简单的网络过滤器，并到达我想要解析 IPv6 标头以匹配 ICMPv6 类型、TCP/UDP 端口号等内容的位置。

所以我正在深入阅读IPv6 packet format，我有点像......嗯......我不得不一遍又一遍地阅读它以确保我实际上阅读它是正确的. 在我看来，您必须从 40 字节的固定标头开始，然后查看它的下一个标头字段。然后你必须查看下一个标题的下一个标题字段，以此类推，就像一个链表，直到你到达末尾。如果有有效载荷，它就会跟随。

问题在于固定标头或扩展标头中都没有长度字段。您必须有一个扩展标头类型及其大小的表，以便您可以将这个链表追踪到最后。

这让我觉得这是一个奇怪的，甚至可能是愚蠢的设计。如果我遇到无法识别的扩展标头类型怎么办？我该怎么办？我不知道它的长度。我想我必须将数据包丢弃并阻止它，因为在允许数据包通过的网络过滤器中，攻击者可以通过包含虚假的标头类型来逃避网络过滤器。 但这意味着如果协议被扩展，如果要使用新的扩展，那么曾经编写的每一个 IPv6 报头解析软件都必须同时更新。

那么，如果我不知道 IPv6 标头使用的扩展名，我该如何解析它们呢？由于我不知道它的长度，如何跳过未知扩展的标头？

【问题讨论】：

基于这个问题，我看起来并不愚蠢，是的，我没看错：（在现实世界中）不可能向 IPv6 添加新的扩展标头。 stackoverflow.com/questions/9847923/…
是的，计算标头长度似乎也需要链表遍历：stackoverflow.com/questions/14762193/… 不要误会我的意思。 IPv6 很棒而且非常需要。但这似乎仍然是愚蠢的。
规范（链接在顶部评论中）说路由器不应该查看标头，因此不应该关心您添加的标头。只有目标节点应该查看标头。
请注意：“hair-brained”是一个相当混乱的拼写，应该首选“hare-brained”（来源：tfd）
只要有一个正确的拼写，那就是'hare-brained'。

标签： networking ip ipv6

【解决方案1】：

如果我遇到无法识别的扩展标头类型怎么办？

来自RFC 2460：

如果作为处理标头的结果，需要一个节点继续到下一个标头，但当前标头中的下一个标头值是未被节点识别，它应该丢弃数据包并发送一个发给数据包源的 ICMP 参数问题消息，带有 ICMP 代码值为 1（“遇到无法识别的下一个标头类型”）以及包含无法识别的偏移量的 ICMP 指针字段原始数据包中的值。应采取相同的措施，如果节点在任何其他标头中遇到下一个标头值为零而不是 IPv6 标头。

【讨论】：

好。我以为我疯了。所以是的，它确实是一个完全不可扩展的设计……至少没有带内信号和其他黑客攻击。在您控制两端并且只需要考虑应用程序的新版本的应用程序协议中，这是可以原谅的，但对于旨在持续......数百年的东西来说，这是可以原谅的？
拥有忽略未知标题的能力会导致更复杂的问题。（如果中间代理在不知道封装 ESP 标头的情况下修改了 TCP 标头怎么办？）在这种情况下，简单性胜过“可扩展”！
@Max IPv6 确实有足够的地址来为地球上的每一个原子分配一个地址。没有多少联网烤面包机会耗尽这个空间。
@Max 我不会说我们绝对永远不需要 IPv7，但是有了 IPv6，我们有足够的地址空间来提供地球大气层（130,000 公里以上）中的每一 立方毫米 ) 一个唯一的地址...超过 100,000 次。所以我的意思是，一旦我们开始殖民其他星系，我们可能会担心一些事情，但在那之前我们应该会很好。
缺少某些上下文：With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

【解决方案2】：

如果遇到无法解析的内容，则必须根据已解析的内容做出决定或执行操作。

之所以这样设计，是因为在 IPv6 中，每个扩展标头都“包装”了数据包的其余部分。如果您看到路由标头，然后是一些您从未听说过的标头，然后是有效负载，那么您将无法解析有效负载。有效载荷的含义原则上取决于您不知道如何解释的标头。

路由器可以路由此类数据包，因为它们所需要的只是路由标头。深度数据包检测小工具之类的需要知道很多，但无论如何这就是它们的命运。

编辑添加：这种设计意味着中间盒只能改变他们知道的东西。如果中间盒看到它不知道的标题，那么它只有两个选择：拒绝或传递。在 IPv4 中，它还可以删除未知扩展名并传递其余部分。 IMO 这个属性使设计更具可扩展性。

【讨论】：

【解决方案3】：

（在现实世界中）不可能向 IPv6 添加新的扩展标头。

不正确，因为：

仅允许目标主机根据无法识别的扩展标头拒绝（the question you linked 中提到的一个例外）
如果您的新扩展标头在某种程度上是可选的（最好是），您将收到一个 ICMP 错误，并且可以在没有它的情况下重试。

【讨论】：

并且您确定该 ICMP 数据包会通过 NAT 到达实际发送者？
@Dexter ipv6 将杀死 NAT ... 希望
@Dexter：这些 ICMP 数据包需要到达有多种原因。比如管道的MTU缩小了（可能是因为PPPoE或者VPN的原因造成了数据包封装），发送的数据包太大，会返回一个ICMP数据包，说数据包太大。跨度>
@JanusTroelsen 不是每个人都和你一样希望。

【解决方案4】：

更新RFC 6564 涵盖了这种情况。它准确地列出了您描述的场景，并为任何新的扩展标头（如果曾经定义过）提出了一种格式，至少在某些时候，像您这样的中间盒将能够使用这些标头。

请记住，它并非旨在通过创建新的扩展标头来扩展 IPv6，而是通过添加新的目标选项。处理未知的目的地选项应该是微不足道的，或者至少要容易得多。

【讨论】：