摘要

  • RFC 2908 把组播地址分配分为客户端向服务器申请、域内服务器协调、域间分配三层。实验性 RFC 2909 规定的 MASC 让各网络域从更大地址段中暂时声明前缀，再自行细分或转交给下级域。
  • RFC 2909 提醒：IPsec 可以保护两个直接对等节点，却不能证明被转发的 UPDATE 最初来自可信来源。拓扑中任何不可信的 MASC 节点都可能注入有害更新。规范把防线放在对等关系的管理信任上；它并未证明 MASC 曾被部署、遭到攻击或承载过流量。

2000 年 9 月，互联网组播地址架构要回答两个容易混为一谈的问题：谁把一个组地址交给应用，谁又预留了供这个地址取用的上级空间？RFC 2908 没把它们塞进同一笔交易，而是拆成三层。客户端向地址分配服务器申请组地址；服务器之间在本域协调；域间机制再把地址范围分配给各域。MADCAP 可用于客户端这一层，AAP 或人工配置可用于域内协调，MASC 则是域间分配的一个方案。

这样一来，组播分配不再像一个由全网共同递增的计数器。MASC 节点通常设想部署在边界路由器上，代表一个网络域——这个域往往与一个自治系统相对应。节点从更大的范围里挑选前缀，把声明发给预先配置的对等节点，然后等待是否出现冲突。父子层级允许一个域把获得的前缀切分给本域地址服务器，也可继续向子域分配子前缀。成功取得的前缀还可以进入组播路由信息，供另一套路由协议使用。这些控制面彼此相关，却不是同一件事：MASC 分配前缀，并不会自动生成路由、接收者成员关系或已送达的数据包。

声明有期限。每个前缀都附带有效时长；域若要继续使用，就必须在到期前续期。续期失败后，规范要求停止使用该前缀，并从相应的组播路由状态中删除它。地址范围因此不是默认永久的资源。不过，如果运营者只看其中一项，分配状态、路由状态与应用实际使用情况就可能各不相同。控制记录不是数据包的实测轨迹。

架构还把空间不足时的取舍写得很直白。严格切分地址范围可以避免域间冲突，但为了应对网络分区和故障切换所留下的余量会使地址池碎片化。RFC 2908 因此认为，在地址紧张的情况下，充分利用地址和维持可用性比绝对保证“永不冲突”更重要。目标是把冲突概率压得很低，而不是让它归零。MASC 的声明、冲突比较、等待期和换选前缀，落实的是这个概率性设计，并非数学上的确定性。

RFC 2909 接着指出另一种边界：更新的来源。UPDATE 并不总在首个接收它的对等节点处终止。MASC 节点会保存并转发更新，让它经过父节点、同级节点、子节点和内部对等节点。RFC 2909 说，IPsec 可以保护两个建立对等关系的节点。但若拓扑中某处接入了不可信的 MASC 节点，它就可能注入有害 UPDATE，其他节点未必能辨认出来。因此，规范建议每个 MASC 节点只与可信节点建立对等关系。重启恢复时，来自父节点或内部对等节点的状态通常被视为可信；节点也可以丢弃经同级或子节点转来的、宣称源自本域的 UPDATE。

这并不是说“IPsec 没用”。链路保护可以保护一段具体的连接。问题发生在信息继续转发之后：下一跳知道是哪一个邻居把消息交给它，却未必能独立确认谁最初生成了这项声明，也不能确认每个中继节点都有权转发。MASC 的时间戳和节点标识可以帮助比较相互冲突的声明，但 RFC 2909 没把这些字段说成加密的来源认证。它也没有报告任何真实攻击事件。它写的是威胁模型，并将对等拓扑的配置选择留给运营者。

这道边界很重要，因为一个地址段声明可能影响多个地址分配服务器。一项更新被接受并传播后，可能限制邻域中其他声明，也可能进入组播路由状态——那时还没有应用请求某个组地址。RFC 2909 提出的办法不是设立一个为全网每项声明背书的中心，而是让对等关系服从信任政策，并在接受转发更新时考虑其经过的路径。于是，真正的控制权落在网络拓扑的设计与信任关系管理之中。

RFC 的状态标签也限定了历史结论。RFC 2908 是信息类文件，描述的是提议中的架构；RFC 2909 是实验性协议，不是互联网标准。两份文件能证明设计者认真讨论过分层分配模型和其中的风险，却不能证明有多少网络实现了 MASC、它有多普及，或恶意更新是否曾导致服务中断。RFC 3180 的 GLOP 静态映射和 RFC 3171 的 IANA 注册流程是别的分配方式，也不能证明 MASC 落地。能够成立的历史结论更有限，也更有用：前缀声明、链路保护、可信来源、路由和组播数据送达，是不同层次的事实。安全的控制面必须说清楚，每一次状态转换究竟由什么证据授权。

来源