Network Working Group D. Thaler
Request for Comments: 2908 Microsoft
Category: Informational M. Handley
ACIRI
D. Estrin
ISI
September 2000
Network Working Group D. Thaler
Request for Comments: 2908 Microsoft
Category: Informational M. Handley
ACIRI
D. Estrin
ISI
September 2000
The Internet Multicast Address Allocation Architecture
Internet多播地址分配体系结构
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document proposes a multicast address allocation architecture (MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server-server coordination mechanism, and an inter-domain mechanism.
本文提出了一种用于Internet的多播地址分配体系结构（MALLOC）。该体系结构分为三层，包括主机-服务器机制、域内-服务器协调机制和域间机制。
Table of Contents
目录
1: Introduction ................................................ 2
2: Requirements ................................................ 2
3.1: Address Dynamics .......................................... 4
3: Overview of the Architecture ................................ 5
4: Scoping ..................................................... 7
4.1: Allocation Scope .......................................... 8
4.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 ............. 9
4.1.2: The IPv6 Allocation Scope -- SCOP 6 ..................... 9
5: Overview of the Allocation Process .......................... 9
6: Security Considerations ..................................... 10
7: Acknowledgments ............................................. 11
8: References .................................................. 11
9: Authors' Addresses .......................................... 12
10: Full Copyright Statement ................................... 13
1: Introduction ................................................ 2
2: Requirements ................................................ 2
3.1: Address Dynamics .......................................... 4
3: Overview of the Architecture ................................ 5
4: Scoping ..................................................... 7
4.1: Allocation Scope .......................................... 8
4.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 ............. 9
4.1.2: The IPv6 Allocation Scope -- SCOP 6 ..................... 9
5: Overview of the Allocation Process .......................... 9
6: Security Considerations ..................................... 10
7: Acknowledgments ............................................. 11
8: References .................................................. 11
9: Authors' Addresses .......................................... 12
10: Full Copyright Statement ................................... 13
This document proposes a multicast address allocation architecture (MALLOC) for the Internet, and is intended to be generic enough to apply to both IPv4 and IPv6 environments.
本文档提出了一种适用于Internet的多播地址分配体系结构（MALLOC），旨在具有足够的通用性，以适用于IPv4和IPv6环境。
As with unicast addresses, the usage of any given multicast address is limited in two dimensions:
与单播地址一样，任何给定多播地址的使用仅限于两个方面：
Lifetime: An address has a start time and a (possibly infinite) end time, between which it is valid.
生存期：地址有一个开始时间和一个（可能无限）结束时间，在这两个时间之间是有效的。
Scope: An address is valid over a specific area of the network. For example, it may be globally valid and unique, or it may be a private address which is valid only within a local area.
作用域：地址在网络的特定区域有效。例如，它可能是全局有效且唯一的，也可能是仅在本地区域内有效的私人地址。
This architecture assumes that the primary scoping mechanism in use is administrative scoping, as described in RFC 2365 [1]. While solutions that work for TTL scoping are possible, they introduce significant additional complication for address allocation [2]. Moreover, TTL scoping is a poor solution for multicast scope control, and our assumption is that usage of TTL scoping will decline before this architecture is widely used.
如RFC 2365[1]中所述，该体系结构假设使用的主要作用域机制是管理作用域。虽然TTL作用域的解决方案是可能的，但它们为地址分配带来了显著的额外复杂性[2]。此外，TTL作用域控制对于多播作用域控制来说是一个糟糕的解决方案，我们的假设是，在这种体系结构被广泛使用之前，TTL作用域的使用将会下降。
From a design point of view, the important properties of multicast allocation mechanisms are robustness, timeliness, low probability of clashing allocations, and good address space utilization in situations where space is scare. Where this interacts with multicast routing, it is desirable for multicast addresses to be allocated in a manner that aids aggregation of routing state.
从设计角度来看，多播分配机制的重要特性是鲁棒性、及时性、低冲突分配概率以及在空间有限的情况下良好的地址空间利用率。在这与多播路由交互的情况下，希望以有助于路由状态聚合的方式分配多播地址。
o Robustness/Availability
o 健壮性/可用性
The robustness requirement is that an application requiring the allocation of an address should always be able to obtain one, even in the presence of other network failures.
健壮性要求是，即使存在其他网络故障，需要分配地址的应用程序也应始终能够获得地址。
o Timeliness
o 及时性
From a timeliness point of view, a short delay of up to a few seconds is probably acceptable before the client is given an address with reasonable confidence in its uniqueness. If the session is defined in advance, the address should be allocated as soon as possible, and should not wait until just before the
从及时性的角度来看，在给客户一个对其唯一性有合理信心的地址之前，可能可以接受长达几秒钟的短暂延迟。如果事先定义了会话，则应尽快分配地址，而不应等到会话之前
session starts. It is in some cases acceptable to change the multicast addresses used by the session up until the time when the session actually starts, but this should only be done when it averts a significant problem such as an address clash that was discovered after initial session definition.
会议开始。在某些情况下，在会话实际启动之前更改会话使用的多播地址是可以接受的，但只有在避免了重大问题（如初始会话定义后发现的地址冲突）时才可以这样做。
o Low Probability of Clashes
o 冲突概率低
A multicast address allocation scheme should always be able to allocate an address that can be guaranteed not to clash with that of another session. A top-down partitioning of the address space would be required to completely guarantee that no clashes would occur.
一个多播地址分配方案应该总是能够分配一个可以保证不会与另一个会话的地址冲突的地址。需要对地址空间进行自顶向下的分区，以完全保证不会发生冲突。
o Address Space Packing in Scarcity Situations
o 解决稀缺情况下的空间打包问题
In situations where address space is scarce, simply partitioning the address space would result in significant fragmentation of the address space. This is because one would need enough spare space in each address space partition to give a reasonable degree of assurance that addresses could still be allocated for a significant time in the event of a network partition. In addition, providing backup allocation servers in such a hierarchy, so that fail-over (including partitioning of a server and its backup from each other) does not cause collisions would add further to the address space fragmentation.
在地址空间稀缺的情况下，简单地对地址空间进行分区将导致地址空间的严重碎片化。这是因为在每个地址空间分区中需要足够的空闲空间，以便在发生网络分区的情况下，能够合理地保证在相当长的时间内仍然可以分配地址。此外，在这样的层次结构中提供备份分配服务器，以便故障转移（包括服务器及其备份的分区）不会导致冲突，这将进一步增加地址空间碎片。
Since guaranteeing no clashes in a robust manner requires partitioning the address space, providing a hard guarantee leads to inefficient address space usage. Hence, when address space is scarce, it is difficult to achieve constant availability and timeliness, guarantee no clashes, and achieve good address space usage. As a result, we must prioritize these properties. We believe that, when address space is scarce, achieving good address space packing and constant availability are more important than guaranteeing that address clashes never occur. What we aim for in these situations is a very high probability that an address clash does not occur, but we accept that there is a finite probability of this happening. Should a clash occur (or should an application start using an address it did not allocate, which may also lead to a clash), either the clash can be detected and addresses changed, or hosts receiving additional traffic can prune that traffic using source-specific prunes available in IGMP version 3, and so we do not believe that this is a disastrous situation.
由于以健壮的方式保证没有冲突需要对地址空间进行分区，因此提供硬保证会导致地址空间使用效率低下。因此，当地址空间不足时，很难实现恒定的可用性和及时性，保证没有冲突，并实现良好的地址空间使用。因此，我们必须优先考虑这些属性。我们认为，当地址空间不足时，实现良好的地址空间打包和持续可用性比保证地址冲突永远不会发生更为重要。在这些情况下，我们的目标是不发生地址冲突的概率非常高，但我们承认发生这种情况的概率是有限的。如果发生冲突（或者应用程序开始使用未分配的地址，这也可能导致冲突），则可以检测冲突并更改地址，或者接收额外流量的主机可以使用IGMP版本3中提供的源特定修剪来修剪该流量，因此，我们不认为这是一个灾难性的局面。
In summary, tolerating the possibility of clashes is likely to allow allocation of a very high proportion of the address space in the presence of network conditions such as those observed in [3].
总之，容忍冲突的可能性很可能允许在存在网络条件（如[3]中观察到的情况）的情况下分配非常高比例的地址空间。
We believe that we can get good packing and good availability with good collision avoidance, while we would have to compromise packing and availability significantly to avoid all collisions.
我们相信，通过良好的碰撞避免，我们可以获得良好的包装和良好的可用性，而我们必须在包装和可用性方面做出重大妥协，以避免所有碰撞。
Finally, in situations where address space is not scarce, such as with IPv6, achieving good address space usage is less important, and hence partitioning may potentially be used to guarantee no collisions among hosts that use this architecture.
最后，在地址空间不稀缺的情况下，例如IPv6，实现良好的地址空间使用就不那么重要了，因此分区可能被用来保证使用此体系结构的主机之间不会发生冲突。
Multicast addresses may be allocated in any of three ways:
可以通过以下三种方式之一分配多播地址：
Static: Statically allocated addresses are allocated by IANA for specific protocols that require well-known addresses to work. Examples of static addresses are 224.0.1.1 which is used for the Network Time Protocol [13] and 224.2.127.255 which is used for global scope multicast session announcements. Applications that use multicast for bootstrap purposes should not normally be given their own static multicast address, but should bootstrap themselves using a well-known service location address which can be used to announce the binding between local services and multicast addresses.
静态：IANA为需要已知地址才能工作的特定协议分配静态分配的地址。静态地址的示例包括用于网络时间协议[13]的224.0.1.1和用于全局范围多播会话公告的224.2.127.255。出于引导目的而使用多播的应用程序通常不应获得自己的静态多播地址，而应使用可用于宣布本地服务和多播地址之间绑定的已知服务位置地址来引导自己。
Static addresses typically have a permanent lifetime, and a scope defined by the scope range in which they reside. As such, a static address is valid everywhere (although the set of receivers may be different depending on location), and may be hard-coded into applications, devices, embedded systems, etc. Static addresses are also useful for devices which support sending but not receiving multicast IP datagrams (Level 1 conformance as specified in RFC 1112 [7]), or even are incapable of receiving any data at all, such as a wireless broadcasting device.
静态地址通常有一个永久的生存期，其作用域由它们所在的作用域范围定义。因此，静态地址在任何地方都有效（尽管接收器集可能因位置不同而不同），并且可以硬编码到应用程序、设备、嵌入式系统等中。静态地址也可用于支持发送但不接收多播IP数据报的设备（RFC 1112[7]中规定的1级一致性），甚至无法接收任何数据，如无线广播设备。
Scope-relative: RFC 2365 [1] reserves the highest 256 addresses in every administrative scope range for relative assignments. Relative assignments are made by IANA and consist of an offset which is valid in every scope. Relative addresses are reserved for infrastructure protocols which require an address in every scope, and this offset may be hard-coded into applications, devices, embedded systems, etc. Such devices must have a way (e.g. via MZAP [9] or via MADCAP [4]) to obtain the list of scopes in which they reside.
作用域相对：RFC 2365[1]为相对分配保留每个管理作用域范围中最高的256个地址。相对分配由IANA进行，包括在每个范围内有效的偏移量。相对地址保留给在每个作用域中都需要地址的基础设施协议，该偏移可以硬编码到应用程序、设备、嵌入式系统等中。此类设备必须有一种方法（例如，通过MZAP[9]或通过MADCAP[4]）来获取其驻留的作用域列表。
The offsets assigned typically have a permanent lifetime, and are valid in every scope and location. Hence, the scope-relative address in a given scope range has a lifetime equal to that of the scope range in which it falls.
分配的偏移通常具有永久生存期，并且在每个范围和位置都有效。因此，给定作用域范围内的作用域相对地址的生存期等于其所属作用域范围的生存期。
Dynamic: For most purposes, the correct way to use multicast is to obtain a dynamic multicast address. These addresses are provided on demand and have a specific lifetime. An application should request an address only for as long as it expects to need the address. Under some circumstances, an address will be granted for a period of time that is less than the time that was requested. This will occur rarely if the request is for a reasonable amount of time. Applications should be prepared to cope with this when it occurs.
动态：在大多数情况下，使用多播的正确方法是获取动态多播地址。这些地址是按需提供的，并且具有特定的生存期。应用程序只应在其预期需要地址的时间内请求地址。在某些情况下，地址将被授予一段时间，这段时间比请求的时间短。如果请求的时间合理，这种情况很少发生。应用程序应准备好在出现这种情况时进行处理。
At any time during the lifetime of an existing address, applications may also request an extension of the lifetime, and such extensions will be granted when possible. When the address extension is not granted, the application is expected to request a new address to take over from the old address when it expires, and to be able to cope with this situation gracefully. As with unicast addresses, no guarantee of reachability of an address is provided by the network once the lifetime expires.
在现有地址的生存期内的任何时候，应用程序也可以请求延长生存期，并且在可能的情况下将授予此类延长。当地址扩展未被授予时，应用程序将在旧地址过期时请求一个新地址来接管旧地址，并能够优雅地处理这种情况。与单播地址一样，一旦生存期到期，网络无法保证地址的可达性。
These restrictions on address lifetime are necessary to allow the address allocation architecture to be organized around address usage patterns in a manner that ensures addresses are aggregatable and multicast routing is reasonably close to optimal. In contrast, statically allocated addresses may be given sub-optimal routing.
这些对地址生存期的限制是必要的，以允许地址分配体系结构围绕地址使用模式进行组织，从而确保地址是可聚合的，并且多播路由合理地接近最优。相反，静态分配的地址可能被赋予次优路由。
The architecture is modular so that each layer may be used, upgraded, or replaced independently of the others. Layering also provides isolation, in that different mechanisms at the same layer can be used by different organizations without adversely impacting other layers.
该体系结构是模块化的，因此每一层都可以独立于其他层使用、升级或替换。分层还提供了隔离，因为不同的组织可以使用同一层的不同机制，而不会对其他层产生不利影响。
There are three layers in this architecture (Figure 1). Note that these layer numbers are different from the layer numbers in the TCP/IP stack, which describe the path of data packets.
此体系结构中有三层（图1）。请注意，这些层编号与TCP/IP堆栈中的层编号不同，后者描述数据包的路径。
+--------------------------+ +------------------------+
| | | |
| to other peers | | to other peers |
| || // | | || // || |
| Prefix | | Prefix Prefix |
| Coordinator | |Coordinator Coordinator|
+------------||------------+ +-------||----//---------+
||Layer 3 || //
+------------||------------------------------||--//-----------+
| Prefix Prefix |
| Coordinator=======================Coordinator |
| ^ ^ |
| +----------------+-------------+ |
| | Layer 2 | | |
| MAAS<---/ | +---> MAAS |
| ^ ^ v ^ |
| . . MAAS . |
| . .Layer 1 ^ .Layer 1 |
| v v .Layer 1 v |
| Client Client v Client |
| Client |
+-------------------------------------------------------------+
+--------------------------+ +------------------------+
| | | |
| to other peers | | to other peers |
| || // | | || // || |
| Prefix | | Prefix Prefix |
| Coordinator | |Coordinator Coordinator|
+------------||------------+ +-------||----//---------+
||Layer 3 || //
+------------||------------------------------||--//-----------+
| Prefix Prefix |
| Coordinator=======================Coordinator |
| ^ ^ |
| +----------------+-------------+ |
| | Layer 2 | | |
| MAAS<---/ | +---> MAAS |
| ^ ^ v ^ |
| . . MAAS . |
| . .Layer 1 ^ .Layer 1 |
| v v .Layer 1 v |
| Client Client v Client |
| Client |
+-------------------------------------------------------------+
Figure 1: An Overview of the Multicast Address Allocation Architecture
图1：多播地址分配体系结构概述
Layer 1 A protocol or mechanism that a multicast client uses to request a multicast address from a multicast address allocation server (MAAS). When the server grants an address, it becomes the server's responsibility to ensure that this address is not then reused elsewhere within the address's scope during the lifetime granted.
第1层多播客户端用于从多播地址分配服务器（MAAS）请求多播地址的协议或机制。当服务器授予地址时，服务器有责任确保该地址在授予的生存期内不会在地址范围内的其他地方重用。
Examples of possible protocols or mechanisms at this layer include MADCAP [4], HTTP to access a web page for allocation, and IANA static address assignments.
该层可能的协议或机制示例包括MADCAP[4]、访问网页进行分配的HTTP以及IANA静态地址分配。
An abstract API for applications to use for dynamic allocation, independent of the Layer 1 protocol/mechanism in use, is given in [11].
[11]中给出了应用程序用于动态分配的抽象API，该API独立于使用的第1层协议/机制。
Layer 2 An intra-domain protocol or mechanism that MAAS's use to coordinate allocations to ensure they do not allocate duplicate addresses. A MAAS must have stable storage, or some equivalent robustness mechanism, to ensure that uniqueness is preserved across MAAS failures and reboots.
第2层：MAAS用于协调分配以确保不分配重复地址的域内协议或机制。MAAS必须具有稳定的存储或某些等效的健壮性机制，以确保在MAAS故障和重新启动期间保持唯一性。
MAASs also use the Layer 2 protocol/mechanism to acquire (from "Prefix Coordinators") the ranges of multicast addresses out of which they may allocate addresses.
MAAS还使用第2层协议/机制（从“前缀协调器”获取）多播地址的范围，从中可以分配地址。
In this document we use the term "allocation domain" to mean an administratively scoped multicast-capable region of the network, within which addresses in a specific range may be allocated by a Layer 2 protocol/mechanism.
在本文档中，我们使用术语“分配域”来表示网络的管理范围内的多播能力区域，其中特定范围内的地址可由第2层协议/机制分配。
Examples of protocols or mechanisms at this layer include AAP [5], and manual configuration of MAAS's.
该层协议或机制的示例包括AAP[5]和MAAS的手动配置。
Layer 3 An inter-domain protocol or mechanism that allocates multicast address ranges (with lifetimes) to Prefix Coordinators. Individual addresses may then be allocated out of these ranges by MAAS's inside allocation domains as described above.
第3层一种域间协议或机制，用于将多播地址范围（具有生存期）分配给前缀协调器。如上文所述，MAAS的内部分配域可将各个地址分配到这些范围之外。
Examples of protocols or mechanisms at this layer include MASC [6] (in which Prefix Coordinators are typically routers without any stable storage requirement), and static allocations by AS number as described in [10] (in which Prefix Coordinators are typically human administrators).
该层的协议或机制的示例包括MASC[6]（其中前缀协调器通常是没有任何稳定存储需求的路由器）和按[10]中所述数量进行的静态分配（其中前缀协调器通常是人工管理员）。
Each of the three layers serves slightly different purposes and as such, protocols or mechanisms at each layer may require different design tradeoffs.
这三层中的每一层都有略微不同的用途，因此，每一层的协议或机制可能需要不同的设计权衡。
To allocate dynamic addresses within administrative scopes, a MAAS must be able to learn which scopes are in effect, what their address ranges and names are, and which addresses or subranges within each scope are valid for dynamic allocation by the MAAS.
要在管理范围内分配动态地址，MAA必须能够了解哪些范围有效，它们的地址范围和名称是什么，以及每个范围内哪些地址或子范围对MAA的动态分配有效。
The first two tasks, learning the scopes in effect and the address range and name(s) of each scope, may be provided by static configuration or dynamically learned. For example, a MAAS may simply passively listen to MZAP [9] messages to acquire this information.
前两个任务，学习有效的作用域以及每个作用域的地址范围和名称，可以通过静态配置或动态学习提供。例如，MAA可能只是被动地侦听MZAP[9]消息以获取此信息。
To determine the subrange for dynamic allocation, there are two cases for each scope, corresponding to small "indivisible" scopes, and big "divisible" scopes. Note that MZAP identifies which scopes are divisible and which are not.
为了确定动态分配的子范围，每个范围有两种情况，分别对应于小的“不可分割”范围和大的“可分割”范围。请注意，MZAP标识哪些作用域是可划分的，哪些是不可划分的。
(1) For small scopes, the allocation domain corresponds to the entire topology within the administrative scope. Hence, all MAASs inside the scope may use the entire address range (minus the last
(1) 对于小范围，分配域对应于管理范围内的整个拓扑。因此，作用域内的所有MAAs都可以使用整个地址范围（减去最后一个地址范围）
256 addresses reserved as scope-relative addresses), and use the Layer 2 mechanism/protocol to coordinate allocations. For small scopes, Prefix Coordinators are not involved.
256个地址保留为作用域相对地址），并使用第2层机制/协议来协调分配。对于小范围，不涉及前缀协调器。
Hence, for small scopes, the effective "allocation domain" area may be different for different scopes. Note that a small, indivisible scope could be larger or smaller than the Allocation Scope used for big scopes (see below).
因此，对于小范围，不同范围的有效“分配域”区域可能不同。请注意，一个小的、不可分割的作用域可以大于或小于用于大作用域的分配作用域（见下文）。
(2) For big scopes (including the global scope), the area inside the scope may be large enough that simply using a Layer 2 mechanism/protocol may be inefficient or otherwise undesirable. In this case, the scope must span multiple allocation domains, and the Layer 3 mechanism/protocol must be used to divvy up the scoped address space among the allocation domains. Hence, a MAAS may learn of the scope via MZAP, but must acquire a subrange from which to allocate from a Prefix Coordinator.
(2) 对于大范围（包括全局范围），范围内的区域可能足够大，因此仅使用第2层机制/协议可能效率低下或不受欢迎。在这种情况下，作用域必须跨越多个分配域，并且必须使用第3层机制/协议在分配域之间划分作用域地址空间。因此，MAA可以通过MZAP了解范围，但必须从前缀协调器获取要分配的子范围。
For simplicity, the effective "allocation domain" area will be the same for all big scopes, being the granularity at which all big scopes are divided up. We define the administrative scope at this granularity to be the "Allocation Scope".
为简单起见，所有大范围的有效“分配域”区域都是相同的，即划分所有大范围的粒度。我们将此粒度的管理范围定义为“分配范围”。
The Allocation Scope is a new administrative scope, defined in this document and to be reserved by IANA with values as noted below. This is the scope that is used by a Layer 2 protocol/mechanism to coordinate address allocation for addresses in larger, divisible scopes.
分配范围是本文件中定义的一个新的管理范围，由IANA保留，其值如下所述。这是第2层协议/机制使用的范围，用于协调较大可分割范围内地址的地址分配。
We expect that the Allocation Scope will often coincide with a unicast Autonomous System (AS) boundary.
我们期望分配范围通常与单播自治系统（AS）边界重合。
If an AS is too large, or the network administrator wishes to run different intra-domain multicast routing in different parts of an AS, that AS can be split by manual setup of an allocation scope boundary that is not an AS boundary. This is done by setting up a multicast boundary dividing the unicast AS into two or more multicast allocation domains.
如果AS太大，或者网络管理员希望在AS的不同部分运行不同的域内多播路由，则可以通过手动设置非AS边界的分配范围边界来拆分AS。这是通过设置多播边界来实现的，该边界将单播AS划分为两个或多个多播分配域。
If an AS is too small, and address space is scarce, address space fragmentation may occur if the AS is its own allocation domain. Here, the AS can instead be treated as part of its provider's allocation domain, and use a Layer 2 protocol/mechanism to coordinate allocation between its MAAS's (if any) and those of its provider. An AS should probably take this course of action if:
如果AS太小，并且地址空间不足，则如果AS是其自己的分配域，则可能会发生地址空间碎片。在这里，AS可以被视为其提供商分配域的一部分，并使用第2层协议/机制来协调其MAA（如果有）与其提供商的MAA之间的分配。如果出现以下情况，AS可能会采取此行动：
o it is connected to a single provider,
o 它连接到单个提供商，
o it does not provide transit for another AS, and
o 它不为另一个AS提供运输，以及
o it needs fewer than (say) 256 multicast addresses of larger than AS scope allocated on average.
o 它需要少于（比如）256个大于平均分配范围的多播地址。
The address space 239.251.0.0/16 is to be reserved for the Allocation Scope. The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16 are to be left unassigned and available for expansion of this space. These ranges should be left unassigned until the 239.251.0.0/16 space is no longer sufficient.
为分配范围保留地址空间239.251.0.0/16。范围239.248.0.0/16、239.249.0.0/16和239.250.0.0/16未分配，可用于扩展此空间。在239.251.0.0/16空间不再足够之前，这些范围应保持未分配状态。
The IPv6 "scop" value 6 is to be used for the Allocation Scope.
IPv6“scop”值6将用于分配范围。
Once Layer 3 allocation has been performed for large, divisible scopes, and each Prefix Coordinator has acquired one or more ranges, then those ranges are passed to all MAAS's within the Prefix Coordinator's domain via a Layer 2 mechanism/protocol.
一旦对大的可分割范围执行了第3层分配，并且每个前缀协调器都获得了一个或多个范围，那么这些范围将通过第2层机制/协议传递给前缀协调器域内的所有MAA。
MAAS's within the domain receive these ranges and store them as the currently allowable addresses for that domain. Each range is valid for a given lifetime (also acquired via the Layer 3 mechanism/protocol) and is not revoked before the lifetime has expired. MAAS's also learn of small scopes (e.g., via MZAP) and store the ranges associated with them.
域内的MAA接收这些范围，并将其存储为该域当前允许的地址。每个范围在给定的生存期内有效（也通过第3层机制/协议获取），并且在生存期到期之前不会撤销。MAAS还学习小范围（例如，通过MZAP）并存储与之相关的范围。
Using the Layer 2 mechanism/protocol, each MAAS ensures that it will exclude any addresses which have been or will be allocated by other MAAS's within its domain.
使用第2层机制/协议，每个MAA确保其将排除已由或将由其他MAA在其域内分配的任何地址。
When a client needs a multicast address, it first needs to decide what the scope of the intended session should be, and locate a MAAS capable of allocating addresses within that scope.
当客户机需要一个多播地址时，它首先需要确定预期会话的作用域，并找到能够在该作用域内分配地址的MAAS。
To pick a scope, the client will either simply choose a well-known scope, such as the global scope, or it will enumerate the available scopes (e.g., by sending a MADCAP query, or by listening to MZAP messages over time) and allow a user to select one.
要选择一个作用域，客户机要么简单地选择一个众所周知的作用域，例如全局作用域，要么枚举可用的作用域（例如，通过发送一个MADCAP查询，或者通过监听MZAP消息），并允许用户选择一个。
Locating a MAAS can be done via a variety of methods, including manual configuration, using a service location protocol such as SLP [12], or via a mechanism provided by a Layer 1 protocol itself. MADCAP, for instance, includes such a facility.
可以通过多种方法定位MAA，包括手动配置、使用服务定位协议（如SLP[12]）或通过第1层协议本身提供的机制。例如，MADCAP包括这样一个设施。
Once the client has chosen a scope and located a MAAS, it then requests an address in that scope from the MAAS located. Along with the request it also passes the acceptable range for the lifetimes of the allocation it desires. For example, if the Layer 1 protocol in use is MADCAP, the client sends a MADCAP REQUEST message to the MAAS, and waits for a NAK message or an ACK message containing the allocated information.
一旦客户机选择了一个范围并定位了一个MAA，它就会从定位的MAA请求该范围内的地址。与请求一起，它还通过了它所期望的分配生命周期的可接受范围。例如，如果使用的第1层协议是MADCAP，则客户端向MAAS发送MADCAP请求消息，并等待包含分配信息的NAK消息或ACK消息。
Upon receiving a request from a client, the MAAS then chooses an unused address in a range for the specified scope, with a lifetime which both satisfies the acceptable range specified by the client, and is within the lifetime of the actual range.
在接收到来自客户机的请求后，MAAS然后在指定范围内选择一个未使用的地址，其生存期既满足客户机指定的可接受范围，又在实际范围的生存期内。
The MAAS uses the Layer 2 mechanism/protocol to ensure that such an address does not clash with any addresses allocated by other MAASs. For example, if Layer 2 uses manual configuration of non-overlapping ranges, then this simply consists of adhering to the range configured in the local MAAS. If, on the other hand, AAP is used at Layer 2 to provide less address space fragmentation, the MAAS advertises the proposed allocation domain-wide using AAP. If no clashing AAP claim is received within a short time interval, then the address is returned to the client via the Layer 1 protocol/mechanism. If a clashing claim is received by the MAAS, then it chooses a different address and tries again. AAP also allows each MAAS to pre-reserve a small "pool" of addresses for which it need not wait to detect clashes.
MAAS使用第2层机制/协议，以确保此类地址不会与其他MAAS分配的任何地址冲突。例如，如果第2层使用非重叠范围的手动配置，则这仅仅包括遵守本地MAA中配置的范围。另一方面，如果在第2层使用AAP以提供较少的地址空间碎片，则MAAS使用AAP在整个域范围内宣传所提议的分配。如果在短时间间隔内未收到冲突AAP声明，则通过第1层协议/机制将地址返回给客户端。如果MAA收到冲突索赔，则选择不同的地址并重试。AAP还允许每个MAA预先保留一个小的地址“池”，它不需要等待来检测冲突。
If a domain ever begins to run out of available multicast addresses, a Prefix Coordinator in that domain uses the Layer 3 protocol/mechanism to acquire more space.
如果某个域开始用尽可用的多播地址，该域中的前缀协调器将使用第3层协议/机制来获取更多空间。
The architecture described herein does not prevent an application from just sending to or joining a multicast address without allocating it (just as the same is true for unicast addresses today). However, there is no guarantee that data for unallocated addresses will be delivered by the network. That is, routers may drop data for unallocated addresses if they have some way of checking whether a destination address has been allocated. For example, if the border routers of a domain participate in the Layer 2 protocol/mechanism and cache the set of allocated addresses, then data for unallocated
本文描述的体系结构并不阻止应用程序在不分配多播地址的情况下发送到或加入多播地址（正如今天的单播地址也是如此）。但是，无法保证未分配地址的数据将由网络传送。也就是说，如果路由器有某种方法来检查目标地址是否已分配，则可能会丢弃未分配地址的数据。例如，如果域的边界路由器参与第2层协议/机制并缓存分配的地址集，则未分配的数据
addresses in a range allocated by that domain can be dropped by creating multicast forwarding state with an empty outgoing interface list and/or pruning back the tree branches for those groups.
通过使用空的传出接口列表创建多播转发状态和/或修剪这些组的树分支，可以删除由该域分配的范围内的地址。
A malicious application may attempt a denial-of-service attack by attempting to allocate a large number of addresses, thus attempting to exhaust the supply of available addresses. Other attacks include releasing or modifying the allocation of another party. These attacks can be combatted through the use of authentication with policy restrictions (such as a maximum number of addresses that can be allocated by a single party).
恶意应用程序可能通过尝试分配大量地址来尝试拒绝服务攻击，从而试图耗尽可用地址的供应。其他攻击包括释放或修改另一方的分配。这些攻击可以通过使用具有策略限制的身份验证（例如，一方可以分配的最大地址数）来打击。
Hence, protocols/mechanisms that implement layers of this architecture should be deployable in a secure fashion. For example, one should support authentication with policy restrictions, and should not allow someone unauthorized to release or modify the allocation of another party.
因此，实现该体系结构各层的协议/机制应该可以安全地部署。例如，应该支持带有策略限制的身份验证，并且不应该允许未经授权的人释放或修改另一方的分配。
Steve Hanna provided valuable feedback on this document. The members of the MALLOC WG and the MBone community provided the motivation for this work.
Steve Hanna对此文件提供了宝贵的反馈。MALLOC工作组和MBone社区的成员为这项工作提供了动力。
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[1] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[2] Mark Handley, "Multicast Session Directories and Address Allocation", Chapter 6 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.
[2] Mark Handley，“多播会话目录和地址分配”，第6章题为“可扩展多媒体会议系统”的博士论文，伦敦大学，1997。
[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4 of PhD Thesis entitled "On Scalable Multimedia Conferencing Systems", University of London, 1997.
[3] Mark Handley，《MBOSE性能分析》，第4章题为“可扩展多媒体会议系统”的博士论文，伦敦大学，1997。
[4] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[4] Hanna，S.，Patel，B.和M.Shah，“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[5] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress.
[5] Handley，M.和S.Hanna，“多播地址分配协议（AAP）”，正在进行中。
[6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, P. and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.
[6] Estrin，D.，Govindan，R.，Handley，M.，Kumar，S.，Radoslavov，P.和D.Thaler，“多播地址集声明（MASC）协议”，RFC 2909，2000年9月。
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[8] Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[9] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.
[9] Handley，M.，Thaler，D.和R.Kermode，“多播作用域公告协议（MZAP）”，RFC 27762000年2月。
[10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770, February 2000.
[10] Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，RFC 27702000年2月。
[11] Finlayson, R., "Abstract API for Multicast Address Allocation", RFC 2771, February 2000.
[11] Finlayson，R.，“多播地址分配的抽象API”，RFC 27712000年2月。
[12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[12] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[13] Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Dave Thaler微软公司华盛顿州雷德蒙微软大道一号98052-6399
EMail: dthaler@microsoft.com
EMail: dthaler@microsoft.com
Mark Handley AT&T Center for Internet Research at ICSI 1947 Center St, Suite 600 Berkeley, CA 94704
马克·汉德利美国电话电报公司互联网研究中心，位于加利福尼亚州伯克利市ICSI 1947中心街600室，邮编94704
EMail: mjh@aciri.org
EMail: mjh@aciri.org
Deborah Estrin Computer Science Dept/ISI University of Southern California Los Angeles, CA 90089
底波拉埃斯特林计算机科学系/洛杉矶南加州大学，CA 90089
EMail: estrin@usc.edu
EMail: estrin@usc.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。