摘要

  • RFC 1469 要求同一 Token Ring 物理环上的组播系统使用同一种硬件地址方法；方法可按接口配置，桥接器可以在不同环之间转换方法。
  • 被共用的功能地址解决的是受限硬件中的本地接收选择。它本身既不能证明一帧就是 IP 组播，也不能证明某主机属于那个组；RFC 1112 将这些状态明确放在不同层次。

IP 组名不是网卡的判决

IP 组播地址看起来像一个组的名字，但它并不直接告诉本地网卡应当接纳哪一帧。RFC 1112 把主机组定义为一个动态集合：主机可以加入或离开；主机可以向某个组发送数据报而自己并非成员；成员关系还要按接口保存。这些都是 IP 层的事实。它们必须在本地网络上找到接收办法，却不会因此变成一条 MAC 地址的固有含义。

RFC 1469 所解决的是 Token Ring 上的这一步映射。它列出三种选择：使用全环广播地址、使用分配给 Token Ring 的功能地址、或者使用既有的 IEEE IP 组播组地址。这里最关键的不是哪一个十六进制写法更漂亮，而是协调规则：每一个支持 IP 组播的系统，在同一物理环上都必须同意使用同一硬件地址。于是，这一方法应当能在接口上配置；连接两个环的桥可以在两种方法间翻译。

这说明了地址选择真正的作用范围。它是一项本地运行约定，而不是关于该组的普遍宣言。一个环可以采用一种表示，另一个环采用另一种，桥仍可让两者连通。IP 的意图并没有因为穿越媒介而成为另一个成员事实。相反，观察到某个 Token Ring 目的地址，最多说明该环怎样组织接收；它不能单独还原 IP 软件里是否存在成员关系。

稀缺迫使多个含义共用一条信号

Token Ring 的功能地址原本服务于环监视、NetBIOS、桥接和 LAN Manager 等广泛使用的功能。RFC 1469 指出，这样的地址总共只有 31 个，因此互不相关的功能也可能共享一项。

这项约束塑造了 IP 组播的后备方案。所有 IP 组播地址被映射到同一个 Token Ring 功能地址：规范位序下是 03-00-00-20-00-00，Token Ring 接口通常使用的非规范表示则是 C0-00-00-04-00-00。这是一种有意的压缩。它让能力有限的适配器仍能作出“这帧值得进一步检查”的接收选择，却不再让硬件地址和某个 IP 组一一对应。

RFC 随即给出必须保留的否定结论：一帧发送到这个功能地址，并不因此就一定是 IP 组播帧。别的协议也可能被分配同一个地址。换言之，目的 MAC 地址是检查的门槛，不是对负载语义的裁决。还要看上层封装，才能知道它究竟是什么。

过滤器和成员簿是两本不同的账

RFC 1112 把这一区分放进主机模型。IP 模块维护每个接口上的组成员状态，并用 IGMP 向紧邻的组播路由器报告成员存在。本地网络模块的职责更窄：把 IP 组地址映射为本地地址，以更新接收过滤器。

两者并未被设计成完全相同。RFC 1112 允许本地模块忽略离组请求；如果硬件过滤不够精细，它也可以把目的地址多于请求加入的那些帧一并向上交付。因此，接口见到一帧并不能证明存在相应的成员记录。反过来，向一个组发送也不能证明发送者是成员。IP 目的地址、MAC 过滤规则、主机成员状态和 IGMP 报告互有关联，却不是可以相互替代的证据。

RFC 1469 在控制器能力允许时推荐 IEEE 方法；硬件做不到时，功能地址优先于全环广播。兼容性要求又让支持较高级方法的系统保留较低级的办法。这不是把所有组融成一个组，而是在不相等的硬件能力之间维持可互操作的选择。

因而，这一历史事实的价值不在于给一条地址附加更多含义，而在于清楚划出含义的终点。共享功能地址不识别个人，不识别某一台具体机器，也不证明有多少监听者。它不证明负载就是 IP 组播，不证明路由器把它送出了环，更不证明远端收到了它或应用作出了反应。它描述的是一次本地接收选择。

来源