Internet Engineering Task Force (IETF) P. Savola
Request for Comments: 6308 CSC/FUNET
Obsoletes: 2908 June 2011
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Savola
Request for Comments: 6308 CSC/FUNET
Obsoletes: 2908 June 2011
Category: Informational
ISSN: 2070-1721
Overview of the Internet Multicast Addressing Architecture
Internet多播寻址体系结构综述
Abstract
摘要
The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.
由于缺乏关于IP多播地址分配和分配过程的最新文档，导致了大量的混乱。为了澄清这种情况，本备忘录描述了目前（截至撰写本文时）使用的分配和分配技术和机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6308.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6308.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology: Allocation or Assignment ......................3
2. Multicast Address Allocation ....................................3
2.1. Derived Allocation .........................................3
2.1.1. GLOP Allocation .....................................4
2.1.2. Unicast-Prefix-Based Allocation .....................4
2.2. Administratively Scoped Allocation .........................5
2.3. Static IANA Allocation .....................................6
2.4. Dynamic Allocation .........................................6
3. Multicast Address Assignment ....................................6
3.1. Derived Assignment .........................................6
3.2. SSM Assignment inside the Node .............................7
3.3. Manually Configured Assignment .............................7
3.4. Static IANA Assignment .....................................7
3.4.1. Global IANA Assignment ..............................7
3.4.2. Scope-Relative IANA Assignment ......................8
3.5. Dynamic Assignments ........................................8
4. Summary and Future Directions ...................................9
4.1. Prefix Allocation ..........................................9
4.2. Address Assignment ........................................10
4.3. Future Actions ............................................11
5. Acknowledgements ...............................................11
6. IANA Considerations ............................................11
7. Security Considerations ........................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
1. Introduction ....................................................2
1.1. Terminology: Allocation or Assignment ......................3
2. Multicast Address Allocation ....................................3
2.1. Derived Allocation .........................................3
2.1.1. GLOP Allocation .....................................4
2.1.2. Unicast-Prefix-Based Allocation .....................4
2.2. Administratively Scoped Allocation .........................5
2.3. Static IANA Allocation .....................................6
2.4. Dynamic Allocation .........................................6
3. Multicast Address Assignment ....................................6
3.1. Derived Assignment .........................................6
3.2. SSM Assignment inside the Node .............................7
3.3. Manually Configured Assignment .............................7
3.4. Static IANA Assignment .....................................7
3.4.1. Global IANA Assignment ..............................7
3.4.2. Scope-Relative IANA Assignment ......................8
3.5. Dynamic Assignments ........................................8
4. Summary and Future Directions ...................................9
4.1. Prefix Allocation ..........................................9
4.2. Address Assignment ........................................10
4.3. Future Actions ............................................11
5. Acknowledgements ...............................................11
6. IANA Considerations ............................................11
7. Security Considerations ........................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Good, up-to-date documentation of IP multicast is close to non-existent. Particularly, this is an issue with multicast address allocations (to networks and sites) and assignments (to hosts and applications). This problem is stressed by the fact that there exists confusing or misleading documentation on the subject [RFC2908]. The consequence is that those who wish to learn about IP multicast and how the addressing works do not get a clear view of the current situation.
关于IP多播的好的、最新的文档几乎不存在。特别是，这是多播地址分配（到网络和站点）和分配（到主机和应用程序）的问题。这一问题的突出表现是，存在关于该主题的混淆或误导性文件[RFC2908]。其结果是，那些希望了解IP多播以及寻址如何工作的人无法清楚地了解当前的情况。
The aim of this document is to provide a brief overview of multicast addressing and allocation techniques. The term "addressing architecture" refers to the set of addressing mechanisms and methods in an informal manner.
本文档的目的是简要概述多播寻址和分配技术。术语“寻址架构”是指以非正式方式的一组寻址机制和方法。
It is important to note that Source-Specific Multicast (SSM) [RFC4607] does not have these addressing problems because SSM group addresses have only local significance; hence, this document focuses on the Any Source Multicast (ASM) model.
需要注意的是，源特定多播（SSM）[RFC4607]没有这些寻址问题，因为SSM组地址只有本地意义；因此，本文将重点介绍任意源多播（ASM）模型。
This memo obsoletes and re-classifies RFC 2908 to Historic, and re-classifies RFCs 2776 and 2909 to Historic.
本备忘录淘汰并将RFC 2908重新分类为历史，将RFC 2776和2909重新分类为历史。
Almost all multicast documents and many other RFCs (such as DHCPv4 [RFC2131] and DHCPv6 [RFC3315]) have used the terms "address allocation" and "address assignment" interchangeably. However, the operator and address management communities use these terms for two conceptually different processes.
几乎所有多播文档和许多其他RFC（如DHCPv4[RFC2131]和DHCPv6[RFC3315]）都交替使用了术语“地址分配”和“地址分配”。但是，运营商和地址管理社区将这些术语用于两个概念上不同的流程。
In unicast operations, address allocations refer to leasing a large block of addresses from the Internet Assigned Numbers Authority (IANA) to a Regional Internet Registry (RIR), or from an RIR to a Local Internet Registry (LIR), possibly through a National Internet Registry (NIR). Address assignments, on the other hand, are the leases of smaller address blocks or even single addresses to the end-user sites or end-users themselves.
在单播操作中，地址分配是指将大量地址从互联网分配号码管理局（IANA）租赁到区域互联网注册中心（RIR），或从RIR租赁到本地互联网注册中心（LIR），可能通过国家互联网注册中心（NIR）。另一方面，地址分配是将较小的地址块甚至单个地址租给最终用户站点或最终用户本身。
Therefore, in this memo, we will separate the two different functions: "allocation" describes how larger blocks of addresses are obtained by the network operators, and "assignment" describes how applications, nodes, or sets of nodes obtain a multicast address for their use.
因此，在本备忘录中，我们将区分两种不同的功能：“分配”描述网络运营商如何获得较大的地址块，“分配”描述应用程序、节点或节点集如何获得供其使用的多播地址。
Multicast address allocation, i.e., how a network operator might be able to obtain a larger block of addresses, can be handled in a number of ways, as described below.
多播地址分配，即网络运营商如何能够获得更大的地址块，可以通过多种方式处理，如下所述。
Note that these are all only pertinent to ASM -- SSM requires no address block allocation because the group address has only local significance (however, we discuss the address assignment inside the node in Section 3.2).
注意，这些都只与ASM相关——SSM不需要地址块分配，因为组地址只有本地意义（但是，我们在第3.2节中讨论了节点内部的地址分配）。
Derived allocations take the unicast prefix or some other properties of the network (e.g., an autonomous system (AS) number) to determine unique multicast address allocations.
派生分配采用单播前缀或网络的某些其他属性（例如，自治系统（AS）编号）来确定唯一的多播地址分配。
GLOP address allocation [RFC3180] inserts the 16-bit public AS number in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each AS number can get a /24 worth of multicast addresses. While this is sufficient for multicast testing or small-scale use, it might not be sufficient in all cases for extensive multicast use.
GLOP地址分配[RCF3180]在IPv4多播前缀23.0.0.0/8的中间插入16位公共号码，以便每个AS号可以获得24个/多个组播地址。虽然这对于多播测试或小规模使用来说已经足够了，但对于广泛的多播使用来说，这可能并不完全足够。
A minor operational debugging issue with GLOP addresses is that the connection between the AS and the prefix is not apparent from the prefix when the AS number is greater than 255, but has to be calculated (e.g., as described in [RFC3180], AS 5662 maps to 233.22.30.0/24). A usage issue is that GLOP addresses are not tied to any prefix but to routing domains, so they cannot be used or calculated automatically.
GLOP地址的一个次要操作调试问题是，当AS编号大于255时，AS和前缀之间的连接在前缀中不明显，但必须进行计算（例如，如[RFC3180]中所述，AS 5662映射到233.22.30.0/24）。一个使用问题是GLOP地址没有绑定到任何前缀，而是绑定到路由域，因此无法自动使用或计算它们。
GLOP mapping is not available with 4-byte AS numbers [RFC4893]. Unicast-prefix-based allocation or an IANA allocation from "AD-HOC Block III" (the previous so-called "EGLOP" (Extended GLOP) block) could be used instead, as needed.
GLOP映射不适用于4字节AS数字[RFC4893]。根据需要，可以使用基于单播前缀的分配或来自“AD-HOC Block III”（先前所谓的“EGLOP”（扩展GLOP）块）的IANA分配。
The GLOP allocation algorithm has not been defined for IPv6 multicast because the unicast-prefix-based allocation (described below) addresses the same need in a simpler fashion.
尚未为IPv6多播定义GLOP分配算法，因为基于单播前缀的分配（如下所述）以更简单的方式解决了相同的需求。
RFC 3306 [RFC3306] describes a mechanism that embeds up to 64 high-order bits of an IPv6 unicast address in the prefix part of the IPv6 multicast address, leaving at least 32 bits of group-id space available after the prefix mapping.
RFC 3306[RFC3306]描述了一种机制，该机制在IPv6多播地址的前缀部分嵌入多达64位的IPv6单播地址的高阶位，在前缀映射后留下至少32位的组id空间。
A similar IPv4 mapping is described in [RFC6034], but it provides a limited number of addresses (e.g., 1 per IPv4 /24 block).
[RFC6034]中描述了类似的IPv4映射，但它提供的地址数量有限（例如，每个IPv4/24块1个）。
The IPv6 unicast-prefix-based allocations are an extremely useful way to allow each network operator, even each subnet, to obtain multicast addresses easily, through an easy computation. Further, as the IPv6 multicast header also includes the scope value [RFC4291], multicast groups of smaller scope can also be used with the same mapping.
基于IPv6单播前缀的分配是一种非常有用的方法，它允许每个网络运营商，甚至每个子网，通过简单的计算，轻松获得多播地址。此外，由于IPv6多播报头还包括作用域值[RFC4291]，因此作用域较小的多播组也可以与相同的映射一起使用。
The IPv6 Embedded Rendezvous Point (RP) technique [RFC3956], used with Protocol Independent Multicast - Sparse Mode (PIM-SM), further leverages the unicast-prefix-based allocations, by embedding the unicast prefix and interface identifier of the PIM-SM RP in the prefix. This provides all the necessary information needed to the routing systems to run the group in either inter- or intra-domain operation. A difference from RFC 3306 is, however, that the hosts
与协议独立多播稀疏模式（PIM-SM）一起使用的IPv6嵌入式集合点（RP）技术[RFC3956]通过在前缀中嵌入单播前缀和PIM-SM RP的接口标识符，进一步利用基于单播前缀的分配。这为路由系统提供了在域间或域内操作中运行组所需的所有必要信息。然而，与RFC3306的不同之处在于，主机
cannot calculate their "multicast prefix" automatically (as the prefix depends on the decisions of the operator setting up the RP), but instead require an assignment method.
无法自动计算其“多播前缀”（因为前缀取决于设置RP的运营商的决定），而是需要一种分配方法。
All the IPv6 unicast-prefix-based allocation techniques provide a sufficient amount of multicast address space for network operators.
所有基于IPv6单播前缀的分配技术都为网络运营商提供了足够的多播地址空间。
Administratively scoped multicast address allocation [RFC2365] is provided by two different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in the IPv6 multicast address prefix [RFC4291].
管理范围的多播地址分配[RFC2365]通过两种不同的方式提供：IPv4中的239.0.0.0/8或IPv6多播地址前缀[RFC4291]中的4位编码。
Since IPv6 administratively scoped allocations can be handled with unicast-prefix-based multicast addressing as described in Section 2.1.2, we'll only discuss IPv4 in this section.
由于IPv6管理范围的分配可以使用第2.1.2节中描述的基于单播前缀的多播寻址来处理，因此我们将在本节中仅讨论IPv4。
The IPv4 administratively scoped prefix 239.0.0.0/8 is further divided into Local Scope (239.255.0.0/16) and Organization Local Scope (239.192.0.0/14); other parts of the administrative scopes are either reserved for expansion or undefined [RFC2365]. However, RFC 2365 is ambiguous as to whether the enterprises or the IETF are allowed to expand the space.
IPv4管理范围前缀239.0.0.0/8进一步分为本地范围（239.255.0.0/16）和组织本地范围（239.192.0.0/14）；管理范围的其他部分保留用于扩展或未定义[RFC2365]。然而，RFC 2365对于是否允许企业或IETF扩展空间是不明确的。
Topologies that act under a single administration can easily use the scoped multicast addresses for their internal groups. Groups that need to be shared between multiple routing domains (even if not propagated through the Internet) are more problematic and typically need an assignment of a global multicast address because their scope is undefined.
在单一管理下运行的拓扑可以轻松地为其内部组使用作用域多播地址。需要在多个路由域之间共享的组（即使没有通过Internet传播）问题更大，通常需要分配全局多播地址，因为它们的范围未定义。
There are a large number of multicast applications (such as "Norton Ghost") that are restricted either to a link or a site, and it is extremely undesirable to propagate them further (beyond the link or the site). Typically, many such applications have been given or have hijacked a static IANA address assignment. Given the fact that assignments to typically locally used applications come from the same range as global applications, implementing proper propagation limiting is challenging. Filtering would be easier if a separate, identifiable range would be used for such assignments in the future; this is an area of further future work.
有大量的多播应用程序（如“Norton Ghost”）被限制在链路或站点上，并且极不希望进一步传播它们（超出链路或站点）。通常，许多这样的应用程序已经给出或劫持了静态IANA地址分配。考虑到通常本地使用的应用程序的分配与全局应用程序的分配范围相同，实现适当的传播限制是一项挑战。如果将来对此类分配使用单独的、可识别的范围，则过滤将更容易；这是今后进一步工作的一个领域。
There has also been work on a protocol to automatically discover multicast scope zones [RFC2776], but it has never been widely implemented or deployed.
也有关于自动发现多播作用域的协议的工作[RFC2776]，但它从未被广泛实施或部署。
In some rare cases, organizations may have been able to obtain static multicast address allocations (of up to 256 addresses) directly from IANA. Typically, these have been meant as a block of static assignments to multicast applications, as described in Section 3.4.1. If another means of obtaining addresses is available, that approach is preferable.
在一些罕见的情况下，组织可以直接从IANA获得静态多播地址分配（最多256个地址）。通常，如第3.4.1节所述，这些都是指多播应用程序的静态分配块。如果有另一种获取地址的方法可用，则该方法更可取。
Especially for those operators that only have a 32-bit AS number and need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the previous so-called "EGLOP" block) is an option [RFC5771].
特别是对于那些只有32位AS号码且需要IPv4地址的运营商而言，从“AD-HOC Block III”（先前所谓的“EGLOP”块）分配IANA是一种选择[RFC5771]。
RFC 2908 [RFC2908] proposed three different layers of multicast address allocation and assignment, where layer 3 (inter-domain allocation) and layer 2 (intra-domain allocation) could be applicable here. The Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an example of the former, and the Multicast Address Allocation Protocol (AAP) [MALLOC-AAP] (abandoned in 2000 due to lack of interest and technical problems) is an example of the latter.
RFC 2908[RFC2908]提出了三种不同的多播地址分配和分配层，其中第3层（域间分配）和第2层（域内分配）可适用于此。多播地址集声明协议（MASC）[RFC2909]是前者的一个例子，多播地址分配协议（AAP）[MALLOC-AAP]（由于缺乏兴趣和技术问题于2000年放弃）是后者的一个例子。
Both of the proposed allocation protocols were quite complex, and have never been deployed or seriously implemented.
这两个提议的分配协议都相当复杂，从未被部署或认真实施过。
It can be concluded that dynamic multicast address allocation protocols provide no benefit beyond GLOP/unicast-prefix-based mechanisms and have been abandoned.
可以得出这样的结论：动态多播地址分配协议除了基于GLOP/单播前缀的机制之外没有任何好处，已经被放弃。
There are a number of possible ways for an application, node, or set of nodes to learn a multicast address, as described below.
应用程序、节点或一组节点有多种可能的方法来学习多播地址，如下所述。
Any IPv6 address assignment method should be aware of the guidelines for the assignment of group-IDs for IPv6 multicast addresses [RFC3307].
任何IPv6地址分配方法都应了解IPv6多播地址组ID分配指南[RFC3307]。
There are significantly fewer options for derived address assignment compared to derived allocation. Derived multicast assignment has only been specified for IPv6 link-scoped multicast [RFC4489], where the EUI64 is embedded in the multicast address, providing a node with unique multicast addresses for link-local ASM communications.
与派生分配相比，派生地址分配的选项要少得多。仅为IPv6链路作用域多播[RFC4489]指定了派生多播分配，其中EUI64嵌入在多播地址中，为链路本地ASM通信提供具有唯一多播地址的节点。
While SSM multicast addresses have only local (to the node) significance, there is still a minor issue on how to assign the addresses between the applications running on the same IP address.
虽然SSM多播地址只有本地（到节点）意义，但在如何在同一IP地址上运行的应用程序之间分配地址方面仍然存在一个小问题。
This assignment is not considered to be a problem, because typically the addresses for these applications are selected manually or statically, but if done using an Application Programming Interface (API), the API could check that the addresses do not conflict prior to assigning one.
这种分配不被认为是一个问题，因为这些应用程序的地址通常是手动或静态选择的，但如果使用应用程序编程接口（API）完成，API可以在分配地址之前检查地址是否冲突。
With manually configured assignment, a network operator who has a multicast address prefix assigns the multicast group addresses to the requesting nodes using a manual process.
通过手动配置分配，具有多播地址前缀的网络运营商使用手动过程将多播组地址分配给请求节点。
Typically, the user or administrator that wants to use a multicast address for a particular application requests an address from the network operator using phone, email, or similar means, and the network operator provides the user with a multicast address. Then the user/administrator of the node or application manually configures the application to use the assigned multicast address.
通常，想要为特定应用程序使用多播地址的用户或管理员使用电话、电子邮件或类似方式从网络运营商请求地址，并且网络运营商向用户提供多播地址。然后，节点或应用程序的用户/管理员手动配置应用程序以使用分配的多播地址。
This is a relatively simple process; it has been sufficient for certain applications that require manual configuration in any case, or that cannot or do not want to justify a static IANA assignment. The manual assignment works when the number of participants in a group is small, as each participant has to be manually configured.
这是一个相对简单的过程；对于某些在任何情况下都需要手动配置的应用程序，或者不能或不想证明静态IANA分配的合理性的应用程序，这已经足够了。当组中的参与者人数较少时，手动分配有效，因为每个参与者都必须手动配置。
This is the most commonly used technique when the multicast application does not have a static IANA assignment.
当多播应用程序没有静态IANA分配时，这是最常用的技术。
In contrast to manually configured assignment, as described above, static IANA assignment refers to getting an assignment for the particular application directly from IANA. There are two main forms of IANA assignment: global and scope-relative. Guidelines for IANA are described in [RFC5771].
与上述手动配置的分配不同，静态IANA分配指的是直接从IANA获取特定应用程序的分配。IANA分配有两种主要形式：全局和范围相对。[RFC5771]中描述了IANA指南。
Globally unique address assignment is seen as lucrative because it's the simplest approach for application developers, since they can then hard-code the multicast address. Hard-coding requires no lease of the usable multicast address, and likewise the client applications do
全局唯一地址分配被认为是有利可图的，因为它是应用程序开发人员最简单的方法，因为他们可以硬编码多播地址。硬编码不需要租用可用的多播地址，客户端应用程序也一样
not need to perform any kind of service discovery (but depend on hard-coded addresses). However, there is an architectural scaling problem with this approach, as it encourages a "land-grab" of the limited multicast address space.
不需要执行任何类型的服务发现（但取决于硬编码地址）。然而，这种方法存在架构扩展问题，因为它鼓励对有限的多播地址空间进行“抢占”。
IANA also assigns numbers as an integer offset from the highest address in each IPv4 administrative scope, as described in [RFC2365]. For example, the SLPv2 discovery scope-relative offset is "2", so the SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is "239.255.255.253"; within the IPv4 Organization Local-Scope (239.192.0.0/14), it is "239.195.255.253"; and so on.
IANA还将数字分配为每个IPv4管理范围中最高地址的整数偏移量，如[RFC2365]中所述。例如，SLPv2发现作用域相对偏移量为“2”，因此IPv4本地作用域（239.255.0.0/16）内的SLPv2发现地址为“239.255.255.253”；在IPv4组织本地范围内（239.192.0.0/14），为“239.195.255.253”；等等
Similar scope-relative assignments also exist with IPv6 [RFC2375]. As IPv6 multicast addresses have much more flexible scoping, scope-relative assignments are also applicable to global scopes. The assignment policies are described in [RFC3307].
IPv6[RFC2375]也存在类似的作用域相对分配。由于IPv6多播地址具有更灵活的作用域，作用域相对分配也适用于全局作用域。[RFC3307]中描述了分配策略。
Layer 1 as defined in RFC 2908 [RFC2908] described dynamic assignment from Multicast Address Allocation Servers (MAAS) to applications and nodes, with the Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] as an example. Since then, other mechanisms have also been proposed (e.g., DHCPv6 assignment [MCAST-DHCPv6]), but these have not gained traction.
RFC 2908[RFC2908]中定义的第1层描述了从多播地址分配服务器（MAA）到应用程序和节点的动态分配，以多播地址动态客户端分配协议（MADCAP）[RFC2730]为例。此后，还提出了其他机制（例如，DHCPv6分配[MCAST-DHCPv6]），但这些机制尚未得到重视。
It would be rather straightforward to deploy a dynamic assignment protocol that would lease group addresses based on a multicast prefix to applications wishing to use multicast. However, only few have implemented MADCAP (i.e., it is not significantly deployed). It is not clear if the sparse deployment is due to a lack of need for the protocol. Moreover, it is not clear how widely, for example, the APIs for communication between the multicast application and the MADCAP client operating at the host have been implemented [RFC2771].
部署一个动态分配协议将非常简单，该协议将基于多播前缀向希望使用多播的应用程序租用组地址。然而，只有少数人实现了MADCAP（即，它没有显著部署）。目前尚不清楚稀疏部署是否是由于缺乏对协议的需求。此外，还不清楚多播应用程序和在主机上运行的MADCAP客户端之间的通信API的实现范围[RFC2771]。
An entirely different approach is the Session Announcement Protocol (SAP) [RFC2974]. In addition to advertising global multicast sessions, the protocol also has associated ranges of addresses for both IPv4 and IPv6 that can be used by SAP-aware applications to create new groups and new group addresses. Creating a session (and obtaining an address) is a rather tedious process, which is why it isn't done all that often. It is also worth noting that the IPv6 SAP address is unroutable in the inter-domain multicast.
一种完全不同的方法是会话公告协议（SAP）[RFC2974]。除了播发全局多播会话外，该协议还具有IPv4和IPv6的相关地址范围，SAP感知应用程序可以使用这些地址创建新组和新组地址。创建会话（并获取地址）是一个相当乏味的过程，这就是为什么不经常这样做的原因。还值得注意的是，IPv6 SAP地址在域间多播中是不可中断的。
Conclusions about dynamic assignment protocols are that:
关于动态分配协议的结论如下：
1. multicast is not significantly attractive in the first place,
1. 首先，多播并没有太大的吸引力，
2. most applications have a static IANA assignment and thus require no dynamic or manual assignment,
2. 大多数应用程序都有静态IANA分配，因此不需要动态或手动分配，
3. those applications that cannot be easily satisfied with IANA or manual assignment (i.e., where dynamic assignment would be desirable) are rather marginal, or
3. 那些无法通过IANA或手动分配轻松满足的应用程序（即，需要动态分配的应用程序）非常有限，或者
4. there are other reasons why dynamic assignments are not seen as a useful approach (for example, issues related to service discovery/rendezvous).
4. 动态分配没有被视为有用的方法还有其他原因（例如，与服务发现/会合相关的问题）。
In consequence, more work on rendezvous/service discovery would be needed to make dynamic assignments more useful.
因此，需要在会合/服务发现方面做更多的工作，以使动态分配更加有用。
This section summarizes the mechanisms and analysis discussed in this memo, and presents some potential future directions.
本节总结了本备忘录中讨论的机制和分析，并提出了一些潜在的未来方向。
A summary of prefix allocation methods for ASM is shown in Figure 1.
ASM前缀分配方法的摘要如图1所示。
+-------+--------------------------------+--------+--------+
| Sect. | Prefix allocation method | IPv4 | IPv6 |
+-------+--------------------------------+--------+--------+
| 2.1.1 | Derived: GLOP | Yes | NoNeed*|
| 2.1.2 | Derived: Unicast-prefix-based | No | Yes |
| 2.2 | Administratively scoped | Yes | NoNeed*|
| 2.3 | Static IANA allocation | Yes** | No |
| 2.4 | Dynamic allocation protocols | No | No |
+-------+--------------------------------+--------+--------+
* = the need satisfied by IPv6 unicast-prefix-based allocation
** = mainly using the AD-HOC block III (formerly called "EGLOP")
+-------+--------------------------------+--------+--------+
| Sect. | Prefix allocation method | IPv4 | IPv6 |
+-------+--------------------------------+--------+--------+
| 2.1.1 | Derived: GLOP | Yes | NoNeed*|
| 2.1.2 | Derived: Unicast-prefix-based | No | Yes |
| 2.2 | Administratively scoped | Yes | NoNeed*|
| 2.3 | Static IANA allocation | Yes** | No |
| 2.4 | Dynamic allocation protocols | No | No |
+-------+--------------------------------+--------+--------+
* = the need satisfied by IPv6 unicast-prefix-based allocation
** = mainly using the AD-HOC block III (formerly called "EGLOP")
Figure 1
图1
o Only ASM is affected by the assignment/allocation issues.
o 只有ASM受分配/分配问题的影响。
o With IPv4, GLOP allocations provide a sufficient IPv4 multicast allocation mechanism for those that have a 16-bit AS number. IPv4 unicast-prefix-based allocation offers some addresses. IANA is also allocating from the AD-HOC block III (formerly called "EGLOP"), especially with 32-bit AS number holders in mind. Administratively scoped allocations provide the opportunity for internal IPv4 allocations.
o 对于IPv4，GLOP分配为具有16位AS号码的用户提供了足够的IPv4多播分配机制。基于IPv4单播前缀的分配提供了一些地址。IANA也从特设模块III（以前称为“EGLOP”）进行分配，特别是考虑到32位作为数字持有者。管理范围的分配为内部IPv4分配提供了机会。
o With IPv6, unicast-prefix-based addresses and the derivatives provide a good allocation strategy, and this also works for scoped multicast addresses.
o 在IPv6中，基于单播前缀的地址及其衍生物提供了良好的分配策略，这也适用于作用域多播地址。
o Dynamic allocations are too complex and unnecessary a mechanism.
o 动态分配太复杂，不需要一种机制。
A summary of address assignment methods is shown in Figure 2.
地址分配方法的摘要如图2所示。
+--------+--------------------------------+----------+----------+
| Sect. | Address assignment method | IPv4 | IPv6 |
+--------+--------------------------------+----------+----------+
| 3.1 | Derived: link-scope addresses | No | Yes |
| 3.2 | SSM (inside the node) | Yes | Yes |
| 3.3 | Manual assignment | Yes | Yes |
| 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort|
| 3.4.2 | Scope-relative IANA assignment | Yes | Yes |
| 3.5 | Dynamic assignment protocols | Yes | Yes |
+--------+--------------------------------+----------+----------+
+--------+--------------------------------+----------+----------+
| Sect. | Address assignment method | IPv4 | IPv6 |
+--------+--------------------------------+----------+----------+
| 3.1 | Derived: link-scope addresses | No | Yes |
| 3.2 | SSM (inside the node) | Yes | Yes |
| 3.3 | Manual assignment | Yes | Yes |
| 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort|
| 3.4.2 | Scope-relative IANA assignment | Yes | Yes |
| 3.5 | Dynamic assignment protocols | Yes | Yes |
+--------+--------------------------------+----------+----------+
Figure 2
图2
o Manually configured assignment is typical today, and works to a sufficient degree in smaller scale.
o 如今，手动配置的任务是典型的，并且在较小的规模下工作到足够的程度。
o Global IANA assignment has been done extensively in the past. Scope-relative IANA assignment is acceptable, but the size of the pool is not very high. Inter-domain routing of IPv6 IANA-assigned prefixes is likely going to be challenging, and as a result that approach is not very appealing.
o 全球IANA分配在过去已经做了大量工作。范围相对IANA分配是可以接受的，但池的大小不是很高。IPv6 IANA分配前缀的域间路由可能会很有挑战性，因此这种方法不是很有吸引力。
o Dynamic assignment, e.g., MADCAP, has been implemented, but there is no wide deployment. Therefore, either there are other gaps in the multicast architecture, or there is no sufficient demand for it in the first place when manual and static IANA assignments are available. Assignments using SAP also exist but are not common; global SAP assignment is infeasible with IPv6.
o 已实施动态分配，例如MADCAP，但没有广泛部署。因此，在多播体系结构中要么存在其他差距，要么在手动和静态IANA分配可用的情况下，首先没有足够的需求。使用SAP的分配也存在，但并不常见；使用IPv6时，全局SAP分配不可行。
o Derived assignments are only applicable in a fringe case of link-scoped multicast.
o 导出的分配仅适用于链路范围多播的边缘情况。
o Multicast address discovery/"rendezvous" needs to be analyzed at more length, and an adequate solution provided. See [ADDRDISC-PROB] and [MSA-REQ] for more information.
o 需要更详细地分析多播地址发现/集合，并提供适当的解决方案。有关更多信息，请参阅[ADDRDISC-PROB]和[MSA-REQ]。
o The IETF should consider whether to specify more ranges of the IPv4 administratively scoped address space for static allocation for applications that should not be routed over the Internet (such as backup software, etc. -- so that these wouldn't need to use global addresses, which should never leak in any case).
o IETF应该考虑是否为IPv4管理范围内的地址空间指定更多的范围来进行静态分配，这些应用程序不应该在因特网上路由（例如备份软件等），这样就不需要使用全局地址，这在任何情况下都不应该泄漏。
o The IETF should consider its static IANA allocations policy, e.g., "locking it down" to a stricter policy (like "IETF Consensus") and looking at developing the discovery/rendezvous functions, if necessary.
o IETF应该考虑其静态IANA分配政策，例如“锁定它”到更严格的政策（如“IETF共识”），并在需要时开发发现/交会功能。
Tutoring a couple of multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN], convinced the author that updated multicast address assignment/allocation documentation is needed.
通过指导Kaarle Ritvanen[Ritvanen]最近发表的几篇与多播相关的论文，作者确信需要更新多播地址分配/分配文档。
Multicast address allocations/assignments were discussed at the MBONED WG session at IETF 59 [MBONED-IETF59].
在IETF 59[MBONED-IETF59]的MBONED工作组会议上讨论了多播地址分配/分配。
Dave Thaler, James Lingard, and Beau Williamson provided useful feedback for the preliminary version of this memo. Myung-Ki Shin, Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred Hoenes also suggested improvements.
Dave Thaler、James Lingard和Beau Williamson为这份备忘录的初稿提供了有用的反馈。明基新、杰罗姆·杜兰德、约翰·克里斯托夫、戴夫·普莱斯、斯宾塞·道金斯和阿尔弗雷德·霍恩斯也提出了改进建议。
IANA considerations in Sections 4.1.1 and 4.1.2 of obsoleted and now Historic [RFC2908] were never implemented in the IANA registry.
IANA注册表中从未实施过时且现在具有历史意义的[RFC2908]第4.1.1节和第4.1.2节中的IANA注意事项。
This memo only describes different approaches to allocating and assigning multicast addresses, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo.
本备忘录仅描述分配和分配多播地址的不同方法，没有安全考虑；上述协议的安全性分析超出本备忘录的范围。
Obviously, the dynamic assignment protocols in particular are inherently vulnerable to resource exhaustion attacks, as discussed, e.g., in [RFC2730].
显然，动态分配协议特别容易受到资源耗尽攻击的攻击，如[RFC2730]中所述。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，BCP 53，RFC 31802001年9月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307]Haberman，B.，“IPv6多播地址的分配指南”，RFC3307，2002年8月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for Generating Link-Scoped IPv6 Multicast Addresses", RFC 4489, April 2006.
[RFC4489]Park，J-S.，Shin，M-K.，和H-J.Kim，“生成链路作用域IPv6多播地址的方法”，RFC 4489，2006年4月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 57712010年3月。
[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast Addresses", RFC 6034, October 2010.
[RFC6034]Thaler，D.，“基于单播前缀的IPv4多播地址”，RFC60342010年10月。
[ADDRDISC-PROB] Savola, P., "Lightweight Multicast Address Discovery Problem Space", Work in Progress, March 2006.
[ADDRDISC-PROB]Savola，P.，“轻量级多播地址发现问题空间”，正在进行的工作，2006年3月。
[MALLOC-AAP] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress, June 2000.
[MALLOC-AAP]Handley，M.和S.Hanna，“多播地址分配协议（AAP）”，正在进行的工作，2000年6月。
[MBONED-IETF59] "MBONED WG session at IETF59", <http://www.ietf.org/proceedings/04mar/172.htm>.
[MBONED-IETF59]“IETF59上的MBONED工作组会议”<http://www.ietf.org/proceedings/04mar/172.htm>.
[MCAST-DHCPv6] Durand, J., "IPv6 multicast address assignment with DHCPv6", Work in Progress, February 2005.
[MCAST-DHCPv6]Durand，J.，“使用DHCPv6的IPv6多播地址分配”，正在进行的工作，2005年2月。
[MSA-REQ] Asaeda, H. and V. Roca, "Requirements for IP Multicast Session Announcement", Work in Progress, March 2010.
[MSA-REQ]Asaeda，H.和V.Roca，“IP多播会话公告的要求”，正在进行的工作，2010年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375]Hinden，R.和S.Deering，“IPv6多播地址分配”，RFC 23751998年7月。
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[RFC2730]Hanna，S.，Patel，B.，和M.Shah，“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[RFC2771]Finlayson，R.，“用于多播地址分配的抽象API”，RFC 27712000年2月。
[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[RFC2776]Handley，M.，Thaler，D.，和R.Kermode，“多播作用域公告协议（MZAP）”，RFC 27762000年2月。
[RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC2908]Thaler，D.，Handley，M.，和D.Estrin，“互联网多播地址分配架构”，RFC 2908，2000年9月。
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., Kumar, S., and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.
[RFC2909]Radoslavov，P.，Estrin，D.，Govindan，R.，Handley，M.，Kumar，S.，和D.Thaler，“多播地址集声明（MASC）协议”，RFC 29092000年9月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893]Vohra，Q.和E.Chen，“BGP支持四个八位组作为数字空间”，RFC 4893，2007年5月。
[RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
[RITVANEN]RITVANEN，K.，“多播路由和寻址”，HUT报告，互联网研讨会，2004年5月<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Author's Address
作者地址
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
Pekka Savola CSC-科学计算有限公司，芬兰埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi