RFC 8200 第 4.2 节指出，如果节点无法识别选项类型，则该节点必须根据选项类型的 2 个高阶位执行某些操作。当高位为 时01，它应该丢弃数据包，无论数据包的目标地址是否是多播地址，发送 ICMP 参数问题，代码 2，消息到数据包的源地址，指向无法识别的选项类型。
这似乎与 RFC 1122 第 3.2.2 节相矛盾，该节规定 ICMP 错误消息不得作为接收到 IP 广播或 IP 多播地址的数据报的结果而发送。
似乎存在一些冲突，但 RFC 8200 仅使用“必须”的小写字母，因此我认为 RFC 1122 优先。如果是这种情况，这是否使行动01有效地与10实践中的行动相同？
当高位为 时
01，它应该丢弃数据包，无论数据包的目标地址是否是多播地址，发送 ICMP 参数问题，代码 2，消息到数据包的源地址，指向无法识别的选项类型。
这不是它对两个高阶位所说的01：
01 - 丢弃数据包。
它确实说对于两个高位为10：
10 - 丢弃数据包，无论数据包的目标地址是否是多播地址，都向数据包的源地址发送 ICMP 参数问题，代码 2，消息，指向无法识别的选项类型。
您似乎将 ICMP 与 ICMPv6 混淆了。
这似乎与 RFC 1122 第 3.2.2 节相矛盾，该节规定 ICMP 错误消息不得作为接收到 IP 广播或 IP 多播地址的数据报的结果而发送。
那是针对 ICMP，而不是针对 ICMPv6。在查看 IPv6 时，您应该查看 ICMPv6 RFC，而不是 ICMP (v4) RFC 和规则。请参阅RFC 4443，Internet 协议版本 6 (IPv6) 规范的 Internet 控制消息协议 (ICMPv6)。ICMPv6 在几个方面与 ICMP (IPv4) 不同。下面是第 2.4 节的内容。消息处理规则对此有说明：
(e.3) 一个发往 IPv6 多播地址的数据包。（此规则有两个例外：(1) Packet Too Big Message（第 3.2 节）允许路径 MTU 发现适用于 IPv6 多播，以及（2）参数问题消息，代码 2（第 3.4 节）报告无法识别的IPv6 选项（参见 [IPv6] 的第 4.2 节）将选项类型最高位的两位设置为 10）。