Network Working Group B. Haberman
Request for Comments: 3307 Consultant
Category: Standards Track August 2002
Network Working Group B. Haberman
Request for Comments: 3307 Consultant
Category: Standards Track August 2002
Allocation Guidelines for IPv6 Multicast Addresses
IPv6多播地址的分配准则
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.
本文档规定了负责分配IPv6多播地址的任何实体必须实施的准则。这包括但不限于希望分配永久IPv6多播地址、分配动态IPv6多播地址和定义永久IPv6多播组标识符的任何文档或实体。这些指南的目的是降低IPv6多播地址冲突的概率，不仅在IPv6层，而且在将IP层地址的一部分编码为MAC层地址的媒体链路层。
Table of Contents
目录
1. Terminology.....................................................2
2. Introduction....................................................2
3. Applicability...................................................3
4. Group ID Selection Guidelines...................................3
4.1 Permanent IPv6 Multicast Addresses............................4
4.2 Permanent IPv6 Multicast Group Identifiers....................4
4.3 Dynamic IPv6 Multicast Addresses..............................4
4.3.1 Server Allocation............................................5
4.3.2 Host Allocation..............................................5
5. IANA Considerations.............................................5
6. Security Considerations.........................................6
7. Acknowledgements................................................6
8. References......................................................6
Author's Address...................................................7
Full Copyright Statement...........................................8
1. Terminology.....................................................2
2. Introduction....................................................2
3. Applicability...................................................3
4. Group ID Selection Guidelines...................................3
4.1 Permanent IPv6 Multicast Addresses............................4
4.2 Permanent IPv6 Multicast Group Identifiers....................4
4.3 Dynamic IPv6 Multicast Addresses..............................4
4.3.1 Server Allocation............................................5
4.3.2 Host Allocation..............................................5
5. IANA Considerations.............................................5
6. Security Considerations.........................................6
7. Acknowledgements................................................6
8. References......................................................6
Author's Address...................................................7
Full Copyright Statement...........................................8
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
The term "group ID", throughout this document, conforms to the definition contained in [UNIMCAST], that is, the low-order 32 bits of the IPv6 multicast address.
本文档中的术语“组ID”符合[UNIMCAST]中包含的定义，即IPv6多播地址的低阶32位。
This document specifies guidelines that MUST be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the link-layer address.
本文档规定了负责分配IPv6多播地址的任何实体必须实施的准则。这包括但不限于希望分配永久IPv6多播地址、分配动态IPv6多播地址和定义永久IPv6多播组标识符的任何文档或实体。这些指南的目的是降低IPv6多播地址冲突的概率，不仅在IPv6层，而且在将IP层地址的一部分编码为链路层地址的媒体的链路层。
With the current IPv6 address architecture [ADDRARCH] and the extension to the multicast address architecture specified in [UNIMCAST], a set of guidelines is needed for entities assigning any flavor of IPv6 multicast addresses.
对于当前的IPv6地址体系结构[ADDRARCH]和[UNIMCAST]中指定的多播地址体系结构的扩展，实体分配任何类型的IPv6多播地址都需要一套指南。
The current approach of several physical media [RFC 2464][RFC 2467] is to map a portion of the IPv6 multicast address into a link-layer destination address. This is accomplished by taking the low order 32
几种物理介质[RFC 2464][RFC 2467]的当前方法是将IPv6多播地址的一部分映射到链路层目标地址。这是通过采用低阶32来实现的
bits (henceforth called the group ID) of the IPv6 multicast address and including them in the link-layer destination address. Group IDs, less than or equal to, 32 bits long will generate unique link-layer addresses within a given multicast scope.
IPv6多播地址的位（此后称为组ID），并将其包含在链路层目标地址中。小于或等于32位的组ID将在给定的多播范围内生成唯一的链路层地址。
These guidelines specify how the group ID of the IPv6 multicast address are chosen and assigned. The guidelines specify several mechanisms that can be used to determine the group ID of the multicast address, based on the type of allocation being done.
这些准则指定了如何选择和分配IPv6多播地址的组ID。该指南指定了几种机制，可用于根据正在执行的分配类型确定多播地址的组ID。
These guidelines are designed to be used in any environment in which IPv6 multicast addresses are delegated, assigned, or selected. These guidelines are not limited to use by MADCAP [RFC 2730] servers. The following is a non-exhaustive list of applications of these guidelines:
这些指导原则设计用于委派、分配或选择IPv6多播地址的任何环境。这些指南不限于MADCAP[RFC 2730]服务器使用。以下是这些指南的非详尽应用列表：
- Source-specific multicast application servers can generate an SSM group address by generating a 96-bit multicast prefix, as defined in [UNIMCAST] (i.e. FF3x::/96) and concatenating that with a group ID, as defined in this document.
- 源特定多播应用程序服务器可以通过生成96位多播前缀（如[UNIMCAST]（即FF3x:：/96）并将其与本文档中定义的组ID连接来生成SSM组地址。
- A MADCAP server allocates IPv6 multicast addresses conforming to section 2.7 of [ADDRARCH], creating the group ID using the rules defined in this document.
- MADCAP服务器分配符合[ADDRARCH]第2.7节的IPv6多播地址，使用本文档中定义的规则创建组ID。
- Nodes supplying multicast services in a zeroconf environment generate multicast addresses without the need of centralized control.
- 在zeroconf环境中提供多播服务的节点生成多播地址，而无需集中控制。
- IANA can assign permanent multicast addresses to fulfill requests via the protocol standardization process.
- IANA可以通过协议标准化过程分配永久多播地址以满足请求。
The Group ID selection process allows for three types of multicast address assignments. These are permanent IPv6 multicast addresses, dynamic IPv6 multicast addresses, and permanent IPv6 multicast group IDs. The following guidelines assume that the prefix of the multicast address has been initialized according to [ADDRARCH] or [UNIMCAST].
组ID选择过程允许三种类型的多播地址分配。这些是永久IPv6多播地址、动态IPv6多播地址和永久IPv6多播组ID。以下准则假设多播地址的前缀已根据[ADDRARCH]或[UNIMCAST]进行初始化。
Permanent multicast addresses, like those defined in [RFC 2375], are allocated by IANA. These addresses will be assigned with group ID's, in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.
永久多播地址，如[RFC 2375]中定义的地址，由IANA分配。在专家审查的基础上，这些地址将分配0x00000001到0x3FFFFFFF范围内的组ID。
Multicast addresses assigned by IANA MUST have the T bit set to 0 and the P bit set to 0.
IANA分配的多播地址必须将T位设置为0，P位设置为0。
Permanent group IDs allow for a global identifier of a particular service (e.g. Network Time Protocol (NTP) being assigned the group ID 0x40404040). The use of permanent group IDs differs from permanent multicast addresses in that a permanent group ID offers a global identifier for a service being offered by numerous servers.
永久组ID允许特定服务的全局标识符（例如，网络时间协议（NTP）被分配组ID 0x40404040）。永久组ID的使用不同于永久多播地址，因为永久组ID为多个服务器提供的服务提供全局标识符。
As an example, consider the NTP example group ID of 0x40404040. An NTP client would be able to access multiple servers and multiple scopes. That is, the NTP client will know that the group ID 0x40404040 identifies an NTP multicast stream regardless of the upper 96 bits of the multicast address.
作为一个例子，考虑0x40404040的NTP示例组ID。NTP客户端将能够访问多个服务器和多个作用域。也就是说，NTP客户端将知道组ID 0x40404040标识NTP多播流，而不管多播地址的上96位如何。
Permanent group IDs are allocated on an Expert Review basis, in the range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant to be used in IPv6 multicast addresses, defined in [UNIMCAST].
永久组ID在专家审查的基础上分配，范围为0x40000000到0x7FFFFFFF。这些永久组ID用于[UNIMCAST]中定义的IPv6多播地址。
Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host. Regardless of the allocation mechanism, all dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1. This will distinguish the dynamically allocated addresses from the permanently assigned multicast addresses, defined in [RFC 2375], at the link-layer on any media that maps the lower portion of the IPv6 multicast address into a link-layer address. It should be noted that the high-order bit of the Group ID will be the same value as the T flag.
动态IPv6多播地址可以由分配服务器或终端主机分配。无论采用何种分配机制，所有动态分配的IPv6多播地址的T位都必须设置为1。这将在将IPv6多播地址的下部映射到链路层地址的任何媒体上的链路层上，将动态分配的地址与[RFC 2375]中定义的永久分配的多播地址区分开来。应注意，组ID的高阶位将与T标志的值相同。
As an example, the permanent IPv6 multicast address FF02::9 maps to an Ethernet group address of 33-33-00-00-00-09. A dynamically allocated IPv6 multicast address of FF32::8000:9 would map to the Ethernet group address 33-33-80-00-00-09.
例如，永久IPv6多播地址FF02:：9映射到以太网组地址33-33-00-00-00-09。动态分配的IPv6多播地址FF32:：8000:9将映射到以太网组地址33-33-80-00-00-09。
The allocation of IPv6 multicast addresses, by a server, is defined in [RFC 2730]. Address management is the responsibility of the allocation protocol and outside the scope of this document. Allocation servers MUST use the group ID range 0x80000000 to 0xFFFFFFFF.
[RFC 2730]中定义了服务器对IPv6多播地址的分配。地址管理由分配协议负责，不在本文件范围内。分配服务器必须使用组ID范围0x8000000到0xFFFFFF。
Host-based allocation allows hosts to self-select IPv6 multicast addresses. One example of host-based allocation is the Zeroconf Multicast Address Allocation Protocol [ZMAAPDOC]. Issues with collision detection, claim notification, etc. are outside the scope of this document and the responsibility of the protocol being used, such as [ZMAAPDOC].
基于主机的分配允许主机自行选择IPv6多播地址。基于主机的分配的一个例子是Zeroconf多播地址分配协议[ZMAAPDOC]。碰撞检测、索赔通知等问题不在本文件范围内，也不属于所用协议的责任范围，例如[ZMAAPDOC]。
The group ID portion of the address is created using either a pseudo-random 32-bit number or a 32-bit number created using the guidelines in [RFC 1750]. The generated group ID MUST fall in the range 0x80000000 to 0xFFFFFFFF. This can be accomplished by setting the high-order bit of the generated number to 1.
地址的组ID部分使用伪随机32位数字或使用[RFC 1750]中的指南创建的32位数字创建。生成的组ID必须在0x8000000到0xFFFFFF的范围内。这可以通过将生成的数字的高位设置为1来实现。
This document requests the creation of a new registry maintained by IANA. This new registry will maintain permanent group ID values. The premise of this new registry is to allow for permanent group IDs to be used across multiple domains utilizing the multicast address architecture defined in [UNIMCAST]. The permanent group IDs will fall in the range 0x40000000 to 0x7FFFFFFF.
本文件要求创建由IANA维护的新注册表。这个新注册表将保持永久的组ID值。此新注册表的前提是允许使用[UNIMCAST]中定义的多播地址体系结构跨多个域使用永久组ID。永久组ID将在0x40000000到0x7FFFFFFF的范围内。
In addition, this document also defines rules for the allocation of permanent IPv6 multicast addresses by IANA. These rules specify different ranges for multicast addresses that are IPv6-only and for IPv6 multicast addresses that have corresponding IPv4 multicast addresses.
此外，本文档还定义了IANA分配永久IPv6多播地址的规则。这些规则为仅为IPv6的多播地址和具有相应IPv4多播地址的IPv6多播地址指定不同的范围。
Following the policies outlined in [RFC 2434]:
遵循[RFC 2434]中概述的政策：
- Permanent IPv6 multicast addresses with corresponding IPv4 multicast addresses, like those defined in [RFC 2375], are allocated with group ID's in the range of 1 to 0x3FFFFFFF on an Expert Review basis, see Section 4.1.
- 具有相应IPv4多播地址的永久IPv6多播地址（如[RFC 2375]中定义的地址）在专家审查的基础上分配组ID，范围为1到0x3FFFFF，请参见第4.1节。
- Permanent IPv6-only multicast addresses are allocated with group ID's in the range 0x100 to 0x3FFFFFFF on an Expert Review basis. - Permanent group ID's are allocated on an Expert Review basis in the range 0x40000000 to 0x7FFFFFFF, see Section 4.2. - The range 0x80000000 to 0xFFFFFFFF is reserved for use by dynamic multicast address allocation mechanisms, see Section 4.3.
- 仅限IPv6的永久多播地址在专家审查的基础上分配，组ID在0x100到0x3FFFFF之间。-永久团体ID在专家审查的基础上分配，范围为0x40000000至0x7FFFFFFF，见第4.2节。-0x8000000到0xFFFFFF的范围保留供动态多播地址分配机制使用，请参见第4.3节。
All approved requests for a permanent IPv6 multicast address will result in the assignment of a unique group ID which shall be reserved in all valid IPv6 multicast scopes.
所有经批准的永久IPv6多播地址请求将导致分配唯一的组ID，该组ID应保留在所有有效的IPv6多播作用域中。
The allocation mechanisms described in this document do not alter the security properties of either the Any Source or Source Specific multicast service models of IPv4 and IPv6.
本文档中描述的分配机制不会改变IPv4和IPv6的任何源或源特定多播服务模型的安全属性。
The potential to allocate large blocks of addresses can lead to Denial-of-Service attacks. A more in-depth discussion of the security issues surrounding dynamic allocation of multicast addresses can be found in [RFC 2908].
分配大块地址的可能性会导致拒绝服务攻击。[RFC 2908]中对围绕多播地址动态分配的安全问题进行了更深入的讨论。
The author would like to thank Dave Thaler, Steve Deering, Allison Mankin, Thomas Narten, and Erik Nordmark for their thorough review of this document.
作者要感谢Dave Thaler、Steve Deering、Allison Mankin、Thomas Narten和Erik Nordmark对本文件的全面审查。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[UNIMCAST] Haberman, B. and D. Thaler, "Unicast Prefix-based IPv6 Multicast Addresses", RFC 3306, June 2002.
[UNIMCAST]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年6月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDRARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1999年3月。
[RFC 2730] 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月。
[RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC 2464]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月。
[RFC 2467] Crawford, M., "Transmission of IPv6 over FDDI Networks", RFC 2467, December 1998.
[RFC 2467]克劳福德，M.，“通过FDDI网络传输IPv6”，RFC 2467，1998年12月。
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC 1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC 2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC 2375]Hinden，R.和S.Deering，“IPv6多播地址分配”，RFC 2375，1998年7月。
[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[RFC 2908]Thaler，D.，Handley，M.和D.Estrin，“互联网多播地址分配架构”，RFC 2908，2000年9月。
[ZMAAPDOC] Catrina, et al, "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", Work In Progress.
[ZMAAPDOC]Catrina等人，“Zeroconf多播地址分配协议（ZMAAP）”，正在进行中。
Author's Address
作者地址
Brian Haberman Consultant Phone: 1-919-949-4828 EMail: bkhabs@nc.rr.com
Brian Haberman顾问电话：1-919-949-4828电子邮件：bkhabs@nc.rr.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。