解析包含未知扩展名的IPv6扩展头

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

因此，我正在深入阅读IPv6数据包格式，有点像……好吧……我不得不一遍又一遍地阅读它，以确保我实际上读得对。在我看来，您必须从40字节的固定标头开始，然后查看其下一个标头字段。然后，您必须查看下一个标头的下一个标头字段，依此类推，就像链接列表一样，直到到达末尾。如果有有效载荷，它将跟随。

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

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

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

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

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

路由器可以路由此类数据包，因为它们所需的只是路由头。深度数据包检测小工具之类的东西需要了解很多，但这毕竟是他们的命运。

编辑添加：此设计意味着中间盒只能更改其所知道的内容。如果中间盒看到它不知道的标题，则只有两个选项：拒绝或继续。在IPv4中，它也可以删除未知扩展名并将其余部分继续传递。IMO的这一特性使设计更具扩展性。

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

从RFC 2460开始：

如果作为处理标头的结果，要求节点前进到下一个标头，但是该节点无法识别当前标头中的“下一个标头”值，则它应该丢弃该数据包并将ICMP参数问题消息发送到源分组的，为1的ICMP代码值（“未识别的下一个首部类型中遇到”）和含有原始数据包内的无法识别的值的偏移的ICMP指针字段。如果节点在除IPv6标头之外的任何标头中遇到下一个标头值为零，则应采取相同的操作。

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

错误，因为：

1. 只允许目标主机根据无法识别的扩展头拒绝（链接的问题中提到的一个例外）

2. 如果新的扩展头在某种程度上是可选的（最好是可选的），则您将收到有关此的ICMP错误，如果没有，可以再次尝试。

更新RFC 6564涵盖了这种情况。它准确地列出了您描述的场景，并为任何新的扩展头（如果有的话）定义了格式，至少在某些情况下，您的中间箱可以使用。

请记住，它不是通过创建新的扩展头来扩展IPv6的，而是通过添加新的Destination Options来扩展的。处理未知的目标选项应该很简单，或者至少要容易得多。