Network Working Group D. Meyer
Request for Comments: 2365 University of Oregon
BCP: 23 July 1998
Category: Best Current Practice
Network Working Group D. Meyer
Request for Comments: 2365 University of Oregon
BCP: 23 July 1998
Category: Best Current Practice
Administratively Scoped IP Multicast
管理作用域IP多播
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes.
本文档将“管理范围的IPv4多播空间”定义为范围239.0.0.0至239.255.255.255。此外，它还描述了一组用于实现管理范围的IP多播的简单语义。最后，它提供了IPv6多播地址类[RFC1884]和IPv4多播地址类之间的映射。
This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
本备忘录是互联网工程任务组运营和管理领域MBONE部署工作组（MBONED）的产品。向提交意见<mboned@ns.uoregon.edu>或者是作者。
Much of this memo is taken from "Administratively Scoped IP Multicast", Van Jacobson and Steve Deering, presented at the 30th IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and Dave Thaler have also provided insightful comments on earlier versions of this document.
本备忘录的大部分内容摘自1994年7月25日在加拿大多伦多第30届IETF上发表的“管理范围的IP多播”，Van Jacobson和Steve Deering。Steve Casner、Mark Handley和Dave Thaler还就本文档的早期版本提供了有见地的评论。
Most current IP multicast implementations achieve some level of scoping by using the TTL field in the IP header. Typical MBONE (Multicast Backbone) usage has been to engineer TTL thresholds that confine traffic to some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold.
大多数当前的IP多播实现都通过使用IP报头中的TTL字段来实现一定程度的作用域。MBONE（多播主干网）的典型用途是设计TTL阈值，将流量限制在某些管理定义的拓扑区域内。配置了TTL阈值的接口的基本转发规则是，除非数据包的剩余TTL大于阈值，否则不会在接口上转发数据包。
TTL scoping has been used to control the distribution of multicast traffic with the objective of easing stress on scarce resources (e.g., bandwidth), or to achieve some kind of improved privacy or scaling properties. In addition, the TTL is also used in its traditional role to limit datagram lifetime. Given these often conflicting roles, TTL scoping has proven difficult to implement reliably, and the resulting schemes have often been complex and difficult to understand.
TTL作用域已被用于控制多播流量的分布，目的是缓解对稀缺资源（如带宽）的压力，或实现某种改进的隐私或扩展特性。此外，TTL在其传统角色中也用于限制数据报的生存期。考虑到这些经常相互冲突的角色，TTL范围界定已被证明难以可靠地实施，并且由此产生的方案往往复杂且难以理解。
A more serious architectural problem concerns the interaction of TTL scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The particular problem is that in many common cases, TTL scoping can prevent pruning from being effective. Consider the case in which a packet has either had its TTL expire or failed a TTL threshold. The router which discards the packet will not be capable of pruning any upstream sources, and thus will sink all multicast traffic (whether or not there are downstream receivers). Note that while it might seem possible to send prunes upstream from the point at which a packet is discarded, this strategy can result in legitimate traffic being discarded, since subsequent packets could take a different path and arrive at the same point with a larger TTL.
一个更严重的体系结构问题涉及TTL作用域与广播和删减协议（例如DVMRP[DVMRP]）的交互。特别的问题是，在许多常见情况下，TTL作用域可能会阻止修剪的有效性。考虑一个数据包有TTL过期或TTL阈值失败的情况。丢弃数据包的路由器将无法修剪任何上游源，因此将接收所有多播流量（无论是否存在下游接收器）。请注意，虽然似乎可以从丢弃数据包的点向上游发送剪枝，但此策略可能导致丢弃合法流量，因为后续数据包可能采用不同的路径，并以更大的TTL到达同一点。
On the other hand, administratively scoped IP multicast can provide clear and simple semantics for scoped IP multicast. The key properties of administratively scoped IP multicast are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries.
另一方面，管理作用域IP多播可以为作用域IP多播提供清晰而简单的语义。管理作用域IP多播的关键属性是（i）。寻址到管理作用域多播地址的数据包不会跨越配置的管理边界，以及（ii）。管理范围的多播地址是本地分配的，因此不要求跨管理边界是唯一的。
The administratively scoped IPv4 multicast address space is defined to be the range 239.0.0.0 to 239.255.255.255.
管理范围的IPv4多播地址空间定义为范围239.0.0.0到239.255.255.255。
In order to support administratively scoped IP multicast, a router should support the configuration of per-interface scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matching an interface's boundary definition in either direction (the bi-directional check prevents problems with multi-access networks). In addition, a boundary router always prunes the boundary for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range.
为了支持管理范围的IP多播，路由器应该支持配置每个接口范围的IP多播边界。这种称为边界路由器的路由器不会在任何方向上转发与接口边界定义匹配的数据包（双向检查可防止多址网络出现问题）。此外，边界路由器总是修剪密集模式组[PIMDM]的边界，并且不接受管理范围内稀疏模式组[PIMSM]的连接。
The structure of the IP version 4 administratively scoped multicast space is loosely based on the IP Version 6 Addressing Architecture described in RFC 1884 [RFC1884]. This document defines two important scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These scopes are described below.
IP版本4管理范围多播空间的结构松散地基于RFC 1884[RFC1884]中描述的IP版本6寻址体系结构。本文档定义了两个重要作用域：IPv4本地作用域和IPv4组织本地作用域。这些范围如下所述。
239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own local scope. This implies that any scope boundary is also a boundary for the Local Scope. The more general topological requirements for administratively scoped regions are discussed below.
239.255.0.0/16被定义为IPv4本地作用域。局部作用域是最小的封闭作用域，因此不可进一步划分。尽管局部作用域的确切范围取决于站点，但局部作用域必须遵守某些拓扑约束。特别是，局部范围不得跨越任何其他范围边界。此外，局部范围必须完全包含在或等于任何较大范围内。如果范围区域在区域中重叠，则重叠区域必须在其自身的局部范围内。这意味着任何范围边界也是局部范围的边界。下面讨论管理范围区域的更一般拓扑要求。
6.1.1. Expansion of the IPv4 Local Scope
6.1.1. IPv4本地作用域的扩展
The IPv4 Local Scope space grows "downward". As such, the IPv4 Local Scope may grow downward from 239.255.0.0/16 into the reserved ranges 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not be utilized until the 239.255.0.0/16 space is no longer sufficient.
IPv4本地作用域空间“向下”增长。因此，IPv4本地作用域可能会从239.255.0.0/16向下扩展到保留范围239.254.0.0/16和239.253.0.0/16。但是，在239.255.0.0/16空间不再足够之前，不应使用这些范围。
239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, and is the space from which an organization should allocate sub-ranges when defining scopes for private use.
239.192.0.0/14被定义为IPv4组织本地作用域，是组织在定义私有作用域时应分配子范围的空间。
The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are unassigned and available for expansion of this space. These ranges should be left unassigned until the 239.192.0.0/14 space is no longer sufficient. This is to allow for the possibility that future revisions of this document may define additional scopes on a scale larger than organizations.
范围239.0.0.0/10、239.64.0.0/10和239.128.0.0/10未分配，可用于扩展此空间。在239.192.0.0/14空间不再足够之前，这些范围应保持未分配状态。这是为了考虑到本文件的未来修订可能会以比组织更大的规模定义其他范围。
The other two scope classes of interest, statically assigned link-local scope and global scope already exist in IPv4 multicast space.
IPv4多播空间中已经存在另外两个感兴趣的作用域类，即静态分配的链路本地作用域和全局作用域。
The statically assigned link-local scope is 224.0.0.0/24. The existing static global scope allocations are somewhat more granular, and include
静态指定的链接本地范围为224.0.0.0/24。现有的静态全局范围分配更细粒度，包括
224.1.0.0-224.1.255.255 ST Multicast Groups 224.2.0.0-224.2.127.253 Multimedia Conference Calls 224.2.127.254 SAPv1 Announcements 224.2.127.255 SAPv0 Announcements (deprecated) 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 224.252.0.0-224.255.255.255 DIS transient groups 232.0.0.0-232.255.255.255 VMTP transient groups
224.1.0.0-224.1.255.255 ST多播组224.2.0.0-224.2.127.253多媒体会议电话224.2.127.254 SAPv1公告224.2.127.255 SAPv0公告（不推荐）224.2.128.0-224.2.255.255 SAP动态分配224.252.0.0-224.255.255 DIS瞬态组232.0.0.0-232.255.255 VMTP瞬态组
See [RFC1700] for current multicast address assignments (this list can also be found, possibly in a more current form, on ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
有关当前多播地址分配，请参见[RFC1700]（此列表也可以在ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
An administratively scoped IP multicast region is defined to be a topological region in which there are one or more boundary routers with common boundary definitions. Such a router is said to be a boundary for scoped addresses in the range defined in its configuration.
管理范围的IP多播区域定义为拓扑区域，其中有一个或多个具有公共边界定义的边界路由器。这种路由器被称为其配置中定义的范围内的作用域地址的边界。
Network administrators may configure a scope region whenever constrained multicast scope is required. In addition, an administrator may configure overlapping scope regions (networks can be in multiple scope regions) where convenient, with the only limitations being that a scope region must be connected (there must be a path between any two nodes within a scope region that doesn't leave that region), and convex (i.e., no path between any two points in the region can cross a region boundary). However, it is important to note that if administratively scoped areas intersect topologically, then the outer scope must consist of its address space minus the address spaces of any intersecting scopes. This requirement prevents the problem that would arise when a path between two points in a convex region crosses the boundary of an intersecting region. For this reason, it is recommended that administrative scopes that intersect topologically should not intersect in address range.
只要需要受约束的多播作用域，网络管理员就可以配置作用域区域。此外，管理员可以在方便的情况下配置重叠的作用域区域（网络可以位于多个作用域区域中），唯一的限制是必须连接作用域区域（作用域区域内的任何两个节点之间必须有一条不离开该区域的路径），并且（即，区域中任何两点之间的路径都不能跨越区域边界）。但是，重要的是要注意，如果管理范围的区域在拓扑上相交，则外部范围必须由其地址空间减去任何相交范围的地址空间组成。此要求可防止凸区域中两点之间的路径穿过相交区域边界时出现问题g区域。因此，建议拓扑相交的管理范围不应在地址范围内相交。
Finally, note that any scope boundary is a boundary for the Local Scope. This implies that packets sent to groups covered by 239.255.0.0/16 must not be forwarded across any link for which a scoped boundary is defined.
最后，请注意，任何范围边界都是局部范围的边界。这意味着发送到239.255.0.0/16所涵盖的组的数据包不得通过定义了作用域边界的任何链路转发。
The following table outlines the partitioning of the IPv4 multicast space, and gives the mapping from IPv4 multicast prefixes to IPv6 SCOP values:
下表概述了IPv4多播空间的分区，并给出了从IPv4多播前缀到IPv6 SCOP值的映射：
IPv6 SCOP RFC 1884 Description IPv4 Prefix
===============================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
IPv6 SCOP RFC 1884 Description IPv4 Prefix
===============================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
The high order /24 in every scoped region is reserved for relative assignments. A relative assignment is an integer offset from highest address in the scope and represents a 32-bit address (for IPv4). For example, in the Local Scope defined above, 239.255.255.0/24 is reserved for relative allocations. The de-facto relative assignment "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for SAP [SAP]. The next relative assignment, "1", corresponds to the address 239.255.255.254 in the Local Scope. The rest of a scoped region below the reserved /24 is available for dynamic assignment (presumably by an address allocation protocol).
每个作用域中的高阶/24保留用于相对赋值。相对分配是范围中最高地址的整数偏移量，表示32位地址（对于IPv4）。例如，在上面定义的本地范围中，239.255.255.0/24保留用于相对分配。SAP[SAP]当前存在事实上的相对分配“0”（即本地范围中的239.255.255.255）。下一个相对赋值“1”对应于本地范围中的地址239.255.255.254。reserved/24下面的作用域的其余部分可用于动态分配（可能是通过地址分配协议）。
In is important to note that a scope discovery protocol [MZAP] will have to be developed to make practical use of scopes other than the Local Scope. In addition, since any use of any administratively scoped region, including the Local Scope, requires dynamically assigned addressing, an Address Allocation Protocol (AAP) will need to be developed to make administrative scoping generally useful.
在中，需要注意的是，必须开发范围发现协议[MZAP]，以便实际使用本地范围以外的范围。此外，由于任何管理范围区域（包括本地范围）的任何使用都需要动态分配寻址，因此需要开发一个地址分配协议（AAP），以使管理范围通常有用。
Requests for relative assignments should be directed to the IANA. The IANA will be advised by an area expert when making relative address assignments. The area expert will be appointed by the relevant Area Director.
相关任务的请求应提交给IANA。IANA在进行相对地址分配时，将由区域专家提供建议。区域专家将由相关区域主任任命。
In general, relative addresses will be used only for bootstrapping to dynamic address assignments from within the scope. As such, relative assignments should only be made to those services that cannot use a dynamic address assignment protocol to find the address used by that service within the desired scope, such as a dynamic address assignment service itself.
通常，相对地址将仅用于从范围内引导到动态地址分配。因此，只能对那些不能使用动态地址分配协议在所需范围内查找该服务使用的地址的服务进行相对分配，例如动态地址分配服务本身。
10. Security Considerations
10. 安全考虑
It is recommended that organizations using the administratively scoped IP Multicast addresses not rely on them to prevent sensitive data from being transmitted outside the organization. Should a multicast router on an administrative boundary be mis-configured, have a bug in the administrative scoping code, or have other problems that would cause that router to forward an administratively scoped IP multicast packet outside of the proper scope, the organizations data would leave its intended transmission region.
建议使用管理范围的IP多播地址的组织不要依赖这些地址来防止敏感数据在组织外部传输。如果管理边界上的多播路由器配置错误，管理作用域代码中存在错误，或者存在其他问题，这些问题将导致该路由器转发超出适当作用域的管理作用域IP多播数据包，则组织数据将离开其预定传输区域。
Organizations using administratively scoped IP Multicasting to transmit sensitive data should use some confidentiality mechanism (e.g. encryption) to protect that data. In the case of many existing video-conferencing applications (e.g. vat), encryption is available as an application feature and merely needs to be enabled (and appropriate cryptographic keys securely distributed). For many other applications, the use of the IP Encapsulating Security Payload (ESP) [RFC-1825, RFC-1827] can provide IP-layer confidentiality though encryption.
使用管理范围的IP多播传输敏感数据的组织应使用某种保密机制（例如加密）来保护该数据。对于许多现有的视频会议应用程序（如vat），加密作为应用程序功能可用，只需启用（并安全分发适当的加密密钥）。对于许多其他应用程序，使用IP封装安全有效载荷（ESP）[RFC-1825，RFC-1827]可以通过加密提供IP层机密性。
Within the context of an administratively scoped IP multicast group, the use of manual key distribution might well be feasible. While dynamic key management for IP Security is a research area at the time this note is written, it is expected that the IETF will be extending the ISAKMP key management protocol to support scalable multicast key distribution in the future.
在管理范围的IP多播组的上下文中，使用手动密钥分发可能是可行的。在撰写本说明时，IP安全的动态密钥管理是一个研究领域，预计IETF将扩展ISAKMP密钥管理协议，以支持未来的可伸缩多播密钥分发。
It is important to note that the "boundary router" described in this note is not necessarily providing any kind of firewall capability.
需要注意的是，本说明中描述的“边界路由器”不一定提供任何类型的防火墙功能。
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP Multicast", presented at the 30th IETF, Toronto, Canada, 25 July 1994.
[ASMA]V.Jacobson，S.Deering，“管理范围的IP多播”，1994年7月25日在加拿大多伦多第30届IETF上发表。
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
[DVMRP]Pusateri，T.，“距离向量多播路由协议”，正在进行中。
[MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol (MZAP)", Work in Progress.
[MZAP]Handley，M.，“多播作用域公告协议（MZAP）”，正在进行中。
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress.
[PIMDM]Deering，S，等人，“协议独立多播版本2，密集模式规范”，正在进行中。
[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.
[PIMSM]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.，和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing Architecture", RFC1884, December 1995.
[RFC1884]印地安语。R.和S.Deering，“IP版本6寻址体系结构”，RFC1884，1995年12月。
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in Progress.
[SAP]Handley，M.，“SAP：会话公告协议”，正在进行中。
David Meyer Cisco Systems San Jose, CA
David Meyer思科系统公司加利福尼亚州圣何塞
EMail: dmm@cisco.com
EMail: dmm@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。