摘要

  • 10 月 28 日的 v6ops 工作组草案第 02 版规定，当 ICMPv6 错误外层源地址无法映射成 IPv4 时，翻译器若有可用公网 IPv4，应先用它作 ICMPv4 源；否则必须使用后备地址 192.0.0.8。第 01 版没有写明这个优先分支。
  • 翻译器应另加 Node Identification 对象保存原始 IPv6 源。Packet Too Big 错误只能先翻译成 ICMPv4，再加该对象；草案允许省去扩展，但建议仍送出错误。IANA把 192.0.0.8/32登记为 IPv4 虚拟地址，不能把它当成可全球到达的目的地址。

让错误回来，不等于知道是谁说的

跨协议的麻烦不在于错误没有内容。ICMPv6 可以说目的地不可达、时间耗尽或数据包太大。问题是外层 IPv6 源可能既不匹配翻译前缀，也没有静态或有状态映射。翻译器要为 IPv4 接收端制造一封能读的回信，却没有办法把这个 128 位地址原样写进 32 位源字段。若翻译器自己还没有公网 IPv4，传统的“用本机公网地址回信”也走不通。

新草案第 4.1 节不再把 192.0.0.8当成不分条件的首选。它先问是否有可用公网 IPv4 或地址池；有，则应遵循 RFC 6791 所述路径使用公网源。没有，才必须用虚拟地址。旧版对无法翻译的源笼统建议使用 192.0.0.8，新版把资源条件写成明确的决定顺序。公网地址可用时，翻译器应使用它；没有时，192.0.0.8让错误继续送达。两种部署条件终于各有明确规则。

IANA 的特殊用途 IPv4 登记表把 192.0.0.8/32称为 IPv4 dummy address，依据是 RFC 7600。表中允许它作源，却不把它列为有效目的地、可转发目的地或全球可达目的地。诊断工具里若出现这个数，含义是翻译器动用了后备标记，不是路径上真有一台名叫 192.0.0.8 的路由器。拿标记画拓扑，调查人员会追一台不存在的机器。

为了留下真正的来处，草案建议增加 Node Identification 对象，内含记录原始 IPv6 源的 IP Address 子对象。既然加了这个对象，原始地址就必须在内，扩展头校验和也必须更新。若 IPv6 源本来就能转换，草案禁止使用虚拟地址，也禁止增加该扩展。这个条件把“正常映射”与“后备标记加来源证据”分开，避免用额外身份字段掩盖一条本来有准确映射的路径。

但是，报文写了地址，不等于屏幕显示了地址。草案的运维章节说，traceroute 之类的工具必须理解并呈现 Node Identification，运营人员才能看见附加信息。只会显示 IPv4 源字段的工具，最终可能只给出 192.0.0.8。数据和观察之间还有一层软件控制。

Packet Too Big 是最难看的例外

Packet Too Big 错误携带调整报文大小所需的信息；把它丢掉可能让发送方继续用不合适的尺寸。可 ICMPv6 的 Packet Too Big 不能直接装入所需的 ICMP 扩展。草案写得很具体：先把错误翻译成 ICMPv4，然后才能加入节点身份对象。实现也可以在这个场景省略对象，但仍应以虚拟源完成翻译，不应因为缺身份扩展就扔掉错误。

这是一笔诚实的交易。IPv4 端拿到大小信号，来源信息可能不完整。虚拟地址解决“回信从哪里发”，身份扩展解决“究竟谁触发了错误”；前者不自动保证后者。把两项功能绑死，可能因为一种附加元数据难以装入，就让基础诊断信号也消失。

翻译器还须识别哪些 ICMPv6 错误属于它处理过的 IPv4 流量，哪些是原生 IPv6 交通。专用 IPv6 地址或专用 /64 能使判断简单些。若同一个 IPv6 地址两边都用，草案认为可能需要保存状态或检查触发错误的原始报文头。IANA 的保留地址不能替设备完成这个分类。

官方状态页将这份文本列为已提交 IESG、仍在 AD 评估的工作组 Internet-Draft。若获批，它会更新 RFC 6791 和 RFC 7915；目前没有新的 IANA 分配请求，也没有文中提供的实网抓包。要判断两条源地址规则是否在实现中兑现，需要各取一份真实报文：有公网 IPv4 的翻译器一份，无公网 IPv4 的一份。

来源