摘要

  • RFC 3956 在 IPv6 组播地址中编码前缀长度、单播前缀和一个小型接口标识，使 PIM-SM 路由器无需另一套映射服务就能推导同一个汇合点。
  • 组地址可能由任何用户提供，因此实现仍须拒绝危险的派生地址；即使计算合法，也不证明 RP 存在、可达、获授权、已有源状态或完成接收端交付。

一个目的地址兼任了地图

组播接收者首先拿到的是组地址。它可能来自配置、网页、目录或应用。RFC 3956让特定范围的 IPv6 组地址承担第二项职责：地址本身携带足够信息，供路由器重建 PIM-SM 使用的 Rendezvous Point。

这项选择针对跨域协调难题。IPv6 没有照搬 IPv4 Any-Source Multicast 所用的 MSDP 安排，而 Source-Specific Multicast 在当时也不是所有场景的即时替代。若每台路由器都能从目的地址得到相同 RP，就可以减少分布式配置和额外映射交换。

计算因此变得一致，但一致不等于真实。

128 位里放不下另一个完整地址

完整 IPv6 RP 地址也是 128 位，而组地址还必须留下组身份。RFC 3956 建立在 RFC 3306 的单播前缀型组播格式上，用标志位选择内嵌 RP 子范围，再以 plen、部分单播网络前缀和四位 RP 接口标识 RIID 重建候选地址。

RIID 零被保留。一个完整组地址只映射到一个 RP；同一前缀下可通过不同非零 RIID 使用不同 RP。组 ID 是否唯一却不在规范范围内。于是“所有路由器算出同一候选”和“所有管理者对组分配达成一致”仍是两件事。

在内嵌范围中，该映射被视为最长匹配并优先于其他 group-to-RP 机制。这能防止同一地址被两套发现系统给出不同答案。它证明选择规则一致，不证明所选服务健康。

用户输入开始影响路由器控制流量

接收端获知组地址后发送 MLD 报告，指定路由器向派生 RP 发起 PIM Join。发送端同样从外部获得组地址，其指定路由器可把早期数据封装进 PIM Register 发给该 RP。组地址因而决定了控制消息尝试前往哪里。

RFC 3956 明确把这种信息视为不受信任来源：互联网上任何用户都可能提供组地址。实现必须至少执行与其他 RP 学习方式相同的有效性检查，并特别排除派生到链路本地 fe80::/10、::/16 和组播 ff00::/8 等范围的结果。

检查通过只说明候选地址在语法和范围策略上可用。它不认证提供组地址的人、前缀运营者、发送者或接收者，也不授权创建、发送或加入组。地址结构已成为路由输入，却没有因此成为访问凭证。

规范直接承认：连“存在”都不能保证

PIM-SM 期望配置或学习到的 RP 在域内可达。RFC 3956 对边界说得很清楚：可达性通常无法被证明；面对外部内嵌 RP，甚至不能保证那台 RP 存在。

这句话拆开了常被监控面板压成一个绿灯的多项事实。到派生地址有路由，只证明转发表有候选下一跳，不证明端点运行 PIM-SM、接受 Register、保存正确源状态或拥有足够资源。Join 建立沿途状态，不证明源已经注册，更不证明数据抵达接收者。映射缓存只证明本机曾算过或存过一个结果。

RP 被写进组地址后也更醒目，因而更像可定位的单点故障。可见性有助排障，也可能集中攻击；它不是健康证明。把组从 MSDP 广告中隐藏本就只是隐蔽性，内嵌 RP 也没有把可发现性变成安全策略。边界限制和明确授权仍需另行实施。

周边协议继续各自出具收据

RFC 4601后来详细描述 PIM-SM 的 Join、Register 与共享树行为。RFC 3810定义 MLDv2 主机成员报告。前者记录控制状态，后者记录本地成员意图；两者都不能单独证明远端 RP 或最终交付。

RFC 4607中的 SSM 用源与组共同标识频道，从而绕过 RP。RFC 3956 把它视为重要替代，却没有把它当作当时的全面替换。无论名称中编码多少路径意图，当前运行状态仍需独立观察。

RFC 7371后来更新 IPv6 组播地址架构；RFC Editor 记录和勘误页保存 RFC 3956 的文档状态。这些资料都不证明某个网络实际部署了该机制。

内嵌 RP 的价值，在于让相同输入产生相同候选，减少配置分歧并缩小故障定位范围。但候选仍只是候选。组地址告诉控制面“向哪里尝试”；路由、PIM 应答、源状态、转发计数和接收端观察才分别证明后面的事情。

资料来源