组播的IP管理范围

本备忘录的状态

本文档规定了互联网社区的互联网最佳当前实践，并要求进行讨论和提出改进建议。这份备忘录的分发是无限的。

版权声明

版权所有（C）互联网协会（1998）。保留所有权利。

1、 摘要

本文档将“管理作用域IPv4组播空间”定义为239.0.0.0至239.255.255.255。此外，它还描述了一组用于实现管理范围IP组播的简单语义。最后，它提供了IPv6组播地址类[RFC1884]（IPV6 地址架构）和IPv4组播地址类别之间的映射。

本备忘录是互联网工程任务组运营和管理领域MBONE部署工作组（MBONED）的产品。向提交评论<mboned@ns.uoregon.edu>或作者。

2、 鸣谢

这份备忘录的大部分内容取自Van Jacobson和Steve Deering于1994年7月25日在加拿大多伦多举行的第30届IETF上发表的“管理范围内的IP组播”。Steve Casner、Mark Handley和Dave Thaler也对本文件的早期版本发表了深刻的评论。

3、 简介

大多数当前的IP组播实现通过使用IP报文头中的TTL字段来实现某种程度的作用域。典型的MBONE（Multicast Backbone，组播骨干网）用途是设计TTL阈值，该阈值将流量限制在一些管理定义的拓扑区域内。具有配置的TTL阈值的接口的基本转发规则是，除非数据包的剩余TTL大于阈值，否则不会在接口上转发数据包。

TTL范围已被用于控制组播流量的分布，目的是缓解对稀缺资源（例如带宽）的压力，或实现某种改进的隐私或缩放特性。此外，TTL在其传统角色中也用于限制数据报的生存期。鉴于这些经常相互冲突的角色，TTL范围界定已被证明难以可靠地实施，并且由此产生的方案往往复杂且难以理解。

一个更严重的体系结构问题涉及TTL范围界定与广播和修剪协议（例如，DVMRP[DVMRP]）的交互。特别的问题是，在许多常见的情况下，TTL范围可能会阻止修剪的有效性。考虑一个数据包的TTL过期或未达到TTL阈值的情况。丢弃数据包的路由器将无法修剪任何上游源，因此将接收所有组播流量（无论是否存在下游接收器）。请注意，虽然从丢弃数据包的点向上游发送修剪似乎是可能的，但这种策略可能会导致合法流量被丢弃，因为后续数据包可能会采用不同的路径，并以更大的TTL到达同一点。

另一方面，管理作用域的IP组播可以为作用域IP组播提供清晰而简单的语义。管理作用域IP组播的关键属性是（i）寻址到管理作用域组播地址的报文不跨越配置的管理边界，以及（ii）管理范围内的组播地址是本地分配的，因此不需要在管理边界上是唯一的。

4、 管理范围的IPv4组播空间的定义

管理作用域IPv4组播地址空间被定义为239.0.0.0到239.255.255.255的范围。

5、 讨论

为了支持管理范围内的IP组播，路由器应该支持每个接口范围内IP组播边界的配置。这种被称为边界路由器的路由器不会在任何方向上转发与接口边界定义匹配的数据包（双向检查可以防止多址网络出现问题）。此外，边界路由器总是修剪密集模式组[PIMM]的边界，并且不接受管理范围内稀疏模式组[PIMSM]的联接。

6、 管理范围的组播空间的结构

IPV4管理范围的组播空间的结构松散地基于RFC 1884（IPV6 地址架构）[RFC1884]中描述的IPV6寻址架构。本文档定义了两个重要作用域：IPv4本地作用域和IPv4组织本地作用域。这些范围如下所述。

6.1、 IPv4本地作用域：239.255.0.0/16

239.255.0.0/16被定义为IPv4本地作用域。局部作用域是最小的封闭作用域，因此不能进一步分割。尽管局部作用域的确切范围取决于站点，但局部作用域必须遵守某些拓扑约束。特别是，本地作用域不得跨越任何其他作用域边界。此外，本地作用域必须完全包含在或等于任何更大的作用域内。如果范围区域在区域上重叠，则重叠区域必须在其自己的局部范围内。这意味着任何范围边界也是本地范围的边界。以下讨论了管理范围区域的更通用拓扑要求。

6.1.1、 IPv4本地范围的扩展

IPv4本地作用域空间“向下”增长。因此，IPv4本地作用域可以从239.255.0.0/16向下增长到保留范围239.254.0.0/16和239.253.0.0/16。但是，在239.255.0.0/16空间不再足够之前，不应使用这些范围。

6.2、 IPv4组织本地范围：239.192.0.0/14

239.192.0.0/14被定义为IPv4组织本地作用域，是组织在定义专用作用域时应分配子范围的空间。

6.2.1、 IPv4组织本地范围的扩展

范围239.0.0.0/10、239.64.0.0/10和239.128.0.0/10未分配，可用于扩展此空间。在239.192.0.0/14空间不再足够之前，这些范围应保持未分配状态。这是为了考虑到本文件的未来修订可能会定义比组织规模更大的额外范围。

6.3、 其他IPv4感兴趣的范围

另外两个感兴趣的作用域类，静态分配的链路本地作用域和全局作用域已经存在于IPv4组播空间中。

静态分配的链路本地作用域为224.0.0.0/24。现有的静态全局作用域分配更加精细，如下：

有关当前组播地址分配，请参阅[RFC1700]（此列表也可以在ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses)。

7、 行政边界的拓扑要求

管理范围的IP组播区域被定义为拓扑区域，其中存在一个或多个具有公共边界定义的边界路由器。这样的路由器被认为是其配置中定义的范围内的作用域地址的边界。

只要需要受约束的组播作用域，网络管理员就可以配置作用域区域。此外，管理员可以在方便的情况下配置重叠的作用域（网络可以在多个作用域中），唯一的限制是作用域必须连接（作用域中的任何两个节点之间必须有一条路径不离开该区域）和限制（即，该区域中的任何两点之间的路径都不能跨越区域边界）。但是，需要注意的是，如果管理作用域在拓扑上相交，则外部作用域必须由其地址空间减去任何相交作用域的地址空间组成。这一要求防止了当限制区域中的两点之间的路径与相交区域的边界相交时会出现的问题。因此，建议在拓扑上相交的管理作用域不应在地址范围内相交。

最后，请注意，任何范围边界都是本地范围的边界。这意味着发送到239.255.0.0/16所涵盖的组的数据包不得在定义了作用域边界的任何链路上转发。

8、 管理范围的组播空间的划分

下表概述了IPv4组播空间的划分，并给出了从IPv4组播前缀到IPv6 SCOP值的映射：

9、 范围区域的结构和使用

每个作用域中的高阶/24是为相对分配保留的。相对分配是从作用域中最高地址偏移的整数，表示32位地址（对于IPv4）。例如，在上面定义的本地作用域中，239.255.255.0/24被保留用于相对分配。SAP[SAP]当前存在事实上的相对分配“0”（即本地作用域中的239.255.255.255）。下一个相对赋值“1”对应于本地作用域中的地址239.255.255.254。保留/24之下的作用域的其余部分可用于动态分配（可能通过地址分配协议）。

需要注意的是，必须开发范围发现协议[MZAP]，以实际使用本地范围以外的范围。此外，由于任何管理范围区域（包括本地范围）的使用都需要动态分配寻址，因此需要开发地址分配协议（Address Allocation Protocol，AAP），以使管理范围通常有用。

9.1、 相关分配指南

相关任务的请求应直接提交给IANA。IANA在进行相关地址分配时，将由地区专家提供建议。区域专家将由相关区域主任任命。

通常，相对地址将仅用于从范围内引导到动态地址分配。因此，应该只对那些不能使用动态地址分配协议来在所需范围内找到该服务使用的地址的服务进行相对分配，例如动态地址分配服务本身。

10、 安全注意事项

建议使用管理作用域IP组播地址的组织不要依赖这些地址，以防止敏感数据在组织外部传输。如果管理边界上的组播路由器配置错误，管理作用域代码中存在错误，或者存在其他问题，导致该路由器在适当作用域之外转发管理作用域IP组播数据包，则组织数据将离开其预期传输区域。

使用管理范围的IP组播传输敏感数据的组织应该使用一些保密机制（例如加密）来保护这些数据。在许多现有的视频会议应用程序（例如，vat）的情况下，加密作为一种应用程序功能是可用的，并且只需要启用（并且安全地分发适当的加密密钥）。对于许多其他应用，使用IP封装安全有效载荷（Encapsulating Security Payload，ESP）[RFC-1825，RFC-1827]（ESP：RFC2406-IP Encapsulating Security Payload）可以通过加密提供IP层机密性。

在管理范围的IP组播组的上下文中，使用手动密钥分发可能是可行的。虽然在编写本说明时，IP安全的动态密钥管理是一个研究领域，但预计IETF将在未来扩展ISAKMP密钥管理协议，以支持可扩展的组播密钥分发。

需要注意的是，本说明中描述的“边界路由器”不一定提供任何类型的防火墙功能。

11、 参考文献

[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP Multicast", presented at the 30th IETF, Toronto, Canada, 25 July 1994.[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.[MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol (MZAP)", Work in Progress.[PIMDM] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress.[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.[RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing Architecture", RFC1884, December 1995.[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in Progress.

12、 完整版权声明

版权所有（C）互联网协会（1998）。保留所有权利。

本文件及其译文可复制并提供给他人，对其进行评论或以其他方式解释或协助其实施的衍生作品可全部或部分制作、复制、出版和分发，不受任何形式的限制，前提是上述版权声明和本段包含在所有此类复制品和衍生作品中。然而，本文件本身不得以任何方式进行修改，例如删除版权声明或提及互联网协会或其他互联网组织，除非是为了制定互联网标准而需要，在这种情况下，必须遵守互联网标准流程中定义的版权程序，或者根据需要将其翻译成英语以外的语言。

上述授予的有限权限是永久性的，互联网协会或其继承人或受让人不会撤销。

本文件及其包含的信息以“原样”为基础提供，互联网协会和互联网工程工作组不承担任何明示或暗示的保证，包括但不限于任何保证，即使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。