RFC 5135：NAT 如何把两个 SSM 私网源压成同一个公网通道

摘要

SSM 以源地址和组地址组成的 (S,G) 作为通道选择依据，而不是只看组地址。
两个私网发送者可以选择同一个组，依靠不同的私网源地址保持可区分性。
RFC 5135 要求 NAT 在组播由内向外发送时，把私网源地址改写成公网侧地址。
若两个发送者被呈现为同一公网源且组地址保持不变，两个私网通道就会收敛成同一个公网 (S,G)。
RFC 明确指出，此时流量不再能被唯一识别，接收端可能看到相互混合的数据。
Endpoint-Independent Mapping 约束映射是否随目的地变化，却不保证不同私网发送者拥有不同公网身份。
IGMPv3 代理聚合可以避免多个私网报告者的状态变更被错误交错，但它不能恢复数据面已丢失的源差异。
239.0.0.0/8、224.0.0.0/24 和 TTL 控制的是报文能走多远，不是到达后代表谁。
RFC 5135 把通用解决方案留待继续研究，只把“允许用户更改 SSM 组”作为临时办法。
组地址可修改只说明存在控制入口；必须另证信令、缓存、过滤器与所有接收者实际采用了新组。
RTP 的 SSRC、CNAME 等应用身份可能提供第二条区分路径，但其生成、传输、校验和使用都需要独立证据。
完整证明必须把私网源、NAT 映射、公网通告、接收选择与最终输出连接为一条可审计链。

外部接收者看到的并不是私网事实

设有两个私网发送者甲和乙，它们都向组 G 发送 SSM 流量。在 NAT 内侧，甲的源地址为 A，乙的源地址为 B，因此两个通道分别是 (A,G) 和 (B,G)。G 相同并不构成冲突；A 与 B 的差异正是 SSM 用来选择源的事实。

跨过 NAT 后，情况发生变化。RFC 5135 要求设备把由内向外的源地址改写成外部地址。如果甲和乙都由同一个公网地址 N 表示，同时组地址 G 不被改写，那么外部报文都落在 (N,G) 上。私网中两个有效的选择条件，在公网侧只剩下一个。

这不是说 NAT 没有工作。相反，它可能严格执行了自己的任务：建立映射、改写源、保留组、转发报文。外部接口计数器可以增长，接收端也可以收到数据。失败发生在另一层——接收者依赖的源差异不再包含在公网 (S,G) 中。

RFC 5135 附录 A 直接描述了这一点：流量不再具有唯一可识别性，接收者可能看到混合。它没有把所有部署都判为失败，因为应用层也许另有身份机制；它也没有提供一个已经完成的通用修复。它只是精确划出网络层能证明与不能证明的边界。

同一个公网地址不是同一个业务来源

运营界面常把“公网源地址稳定”当成连续性的代名词。对于 NAT 而言，这最多说明翻译状态稳定。Endpoint-Independent Mapping 要求一个内部端点面对不同单播或组播目的地时使用一致的映射；若设备拥有多个公网地址，paired address pooling 还建议同一个内部端点持续使用同一个外部地址。

这些规则减少了映射随目的地漂移的意外，却没有承诺每一个内部发送者都得到独占公网地址。两个不同端点各自拥有稳定映射，仍可能在外部以同一个地址出现。稳定描述的是转换规则，不是身份基数。

因此，映射表中的一行不能替代源谱系。审计需要回答：转换前有多少个可区分源？转换后有多少个？如果数量减少，哪一个更高层机制重新建立了区分？若答案只有“报文已经转发”，就仍缺少接收结果所需的证据。

RFC 5135 给 NAT 的任务清单

RFC 5135 于 2008 年 2 月以 BCP 135 发布，范围是带 IGMP 代理的 IPv4 NAT/NAPT，覆盖 ASM 与 SSM。PIM-SM 和 IPv6 不在范围内。这个边界很重要：标准名称不能被借来为未定义的协议与部署结果背书。

对外向内流量，设备不得改写组播目的地址和目的端口，并必须把组播 UDP 转发给已订阅的内部接收者；非 UDP 组播也应得到转发。对内向外流量，源 IP 必须被改写；NAPT 还可能改写源端口，并在预期回应时保留对应映射。

标准要求支持由内向外的组播 UDP，同时要求提供关闭选项，因为多宿主网络可能通过多个出口重复把同一流量送到公网。重复路径与源身份收敛不能混为一谈：前者是一个流被发送多次，后者是两个不同流看起来像同一个。

范围控制也独立存在。默认不得把管理范围 239.0.0.0/8 送到外部，224.0.0.0/24 本地网络控制块也不得越界。TTL 为一还能让报文停在本地路由器。它们决定“去哪里”，并不回答“是谁发的”。

IGMP 代理解决的是状态一致性

代理不会把每台私网主机的 IGMP 报告原样透传。它接收下游成员状态，计算聚合结果，再作为一个上游报告者发出消息。RFC 5135 把 IGMPv1 设为可选、IGMPv2 设为必须、IGMPv3 设为建议；若支持 IGMPv3，则必须支持 SSM 及相应源过滤语义。

这种聚合不是装饰。多个主机各自维护状态机；一台加入的同时另一台离开，若简单交错转发各自的状态变更，上游可能看到无效序列，产生短暂黑洞。代理必须先算出整体状态，才能正确代表私网。

但聚合表仍只是控制面收据。它证明代理准备向上游表达哪些组和源过滤条件，无法逆转数据报文上的源地址改写。外部过滤器只能依据当前位置可见的源地址工作；它不会秘密记住 A 和 B 曾经不同。

这解释了为什么“IGMP 正常”与“接收内容混合”可以同时为真。控制面没有坏，数据面也可能没有丢包；丢失的是跨层身份。若监控只问成员状态和流量计数，这个故障会以绿色状态存在。

改组是一项需要全链采纳的变更

RFC 5135 给出的临时办法是让 SSM 应用允许用户修改组地址。若甲改用 G1、乙使用 G2，即使两者都呈现为 N，公网也能通过 (N,G1) 与 (N,G2) 区分。办法本身合理，但标准明确把一般解决方案留待未来研究。

“可以修改”不等于“修改已经生效”。操作者要识别冲突、选择符合分配与范围政策的新组、更新会话描述、把新值送到每一个接收者、刷新过滤器和授权、排空旧组，并确认缓存没有继续发布旧 (N,G)。任何一个环节停留在旧值，混合通道就仍会被使用。

所以变更必须有版本。记录每个发送者在什么时间使用哪个组，哪一版公网信令包含什么值，哪些接收者取得该版本，实际创建了什么订阅，何时停止旧通道。只保存控制台里当前的 G2，会抹去故障发生时真正运行的 G。

这正是“最小公共规范、本地未来决定、自愿采用”的现实含义。公共层指出一个可携带的逃生入口；应用和运营方决定如何使用；最终是否成立，只能由本地运行系统的采纳证据回答。

应用身份是另一层，不是自动补丁

RTP 的 SSRC 与 CNAME 可以让应用在共享翻译地址之上识别参与者。RFC 5135 鼓励正确生成 CNAME，因为全球大量 NAT 都重复使用 RFC 1918 私网范围。若接收应用真正校验这些字段，它可能把网络层已经合并的报文重新区分开。

然而，字段存在不是结果。发送者要生成合适身份，传输与信令要保留它，接收者要执行冲突规则，应用还要把身份绑定到正确的人或设备。SSRC 冲突本身也不同于 SSM 的 (S,G) 收敛；两个问题可以分别发生，也可以同时发生。

对于承载 RTP 的 ASM，RFC 5135 还讨论映射超时：映射重建可能改变翻译后的传输地址，触发 RTP 碰撞检测。标准建议映射保留 60 分钟，并在离组时销毁；资源压力可以缩短，但不能低于 RFC 4787 的最小值。这个时钟证明 NAT 状态持续多久，不证明接收者理解的是谁。

从入口到输出逐层开具收据

第一张收据来自 NAT 内侧：发送者业务身份、私网地址、所选组、配置版本、有效时间与实际观察到的 (S,G)。若这些数据没有在转换前保存，事后仅凭公网抓包无法可靠恢复有几个私网源。

第二组收据来自边界：映射编号、公网地址、可能改写的端口、地址池决定、建立与到期时间。IGMP 版本、下游成员、源过滤与上游聚合应单独保存，再通过时间和对象关联，不能压成一个“组播正常”的布尔值。

第三组收据来自公网与接收端：会话信令通告的 (S,G)、接收者实际请求的 (S,G)、公网报文、是否存在多个私网贡献者、应用身份及碰撞决定。最后还要记录选中了哪个逻辑源、接受或丢弃了什么、是否混合、是否按时渲染或触发动作。

只有走完这条链，转发才能被描述为“按意图交付”。在此之前，合规、映射、成员关系和到包都各自为真，却没有任何一项有权代表最终现实。

两个私网源公布了同一个公网 `(S,G)`：RFC 5135 留下的身份断点

为何重要

摘要

外部接收者看到的并不是私网事实

同一个公网地址不是同一个业务来源

RFC 5135 给 NAT 的任务清单

IGMP 代理解决的是状态一致性

改组是一项需要全链采纳的变更

应用身份是另一层，不是自动补丁

从入口到输出逐层开具收据

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报