Internet Engineering Task Force (IETF) S. Venaas
Request for Comments: 6676 R. Parekh
Category: Informational G. Van de Velde
ISSN: 2070-1721 Cisco Systems
T. Chown
University of Southampton
M. Eubanks
Iformata Communications
August 2012
Internet Engineering Task Force (IETF) S. Venaas
Request for Comments: 6676 R. Parekh
Category: Informational G. Van de Velde
ISSN: 2070-1721 Cisco Systems
T. Chown
University of Southampton
M. Eubanks
Iformata Communications
August 2012
Multicast Addresses for Documentation
文档的多播地址
Abstract
摘要
This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes.
本文档讨论了应将哪些多播地址用于文档目的，并保留了此类用途的多播地址。一些多播地址是从AS数字或单播地址派生的。本文档还解释了如何将这些用于文档目的。
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/rfc6676.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6676.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
2. IPv4 Multicast Documentation Addresses ..........................3
2.1. Administratively Scoped IPv4 Multicast Addresses ...........3
2.2. GLOP Multicast Addresses ...................................3
2.3. Unicast Prefix-Based IPv4 Multicast Addresses ..............4
3. IPv6 Multicast Documentation Addresses ..........................4
3.1. Unicast Prefix-Based IPv6 Multicast Addresses ..............5
3.2. Embedded-RP IPv6 Multicast Addresses .......................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. Acknowledgments .................................................6
7. Informative References ..........................................6
1. Introduction ....................................................2
2. IPv4 Multicast Documentation Addresses ..........................3
2.1. Administratively Scoped IPv4 Multicast Addresses ...........3
2.2. GLOP Multicast Addresses ...................................3
2.3. Unicast Prefix-Based IPv4 Multicast Addresses ..............4
3. IPv6 Multicast Documentation Addresses ..........................4
3.1. Unicast Prefix-Based IPv6 Multicast Addresses ..............5
3.2. Embedded-RP IPv6 Multicast Addresses .......................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. Acknowledgments .................................................6
7. Informative References ..........................................6
It is often useful in documentation, IETF documents, etc., to provide examples containing IP multicast addresses. For documentation where examples of general purpose multicast addresses are needed, one should use multicast addresses that will never be assigned or in actual use. There is a risk that addresses used in examples may accidentally be used. It is then important that the same addresses not be used by other multicast applications or services. It may also be beneficial to filter out such addresses from multicast signalling and to filter out multicast data sent to such addresses.
在文档、IETF文档等中，提供包含IP多播地址的示例通常很有用。对于需要通用多播地址示例的文档，应使用永远不会分配或实际使用的多播地址。示例中使用的地址存在意外使用的风险。因此，重要的是，其他多播应用程序或服务不能使用相同的地址。从多播信令中过滤出这样的地址并过滤出发送到这样的地址的多播数据也是有益的。
For unicast, there are both IPv4 and IPv6 addresses reserved for this purpose; see [RFC5737] and [RFC3849], respectively. This document reserves multicast addresses for this same purpose.
对于单播，有IPv4和IPv6地址保留用于此目的；分别参见[RFC5737]和[RFC3849]。本文档保留多播地址以用于相同目的。
There are also some multicast addresses that are derived from AS numbers or unicast addresses. For examples where such addresses are desired, one should derive them from the AS numbers and unicast addresses reserved for documentation purposes. This document also discusses the use of these.
还有一些多播地址是从AS数字或单播地址派生的。例如，如果需要这样的地址，应该从AS编号和为文档目的保留的单播地址中派生出来。本文件还讨论了这些工具的使用。
For Any-Source Multicast (ASM), the IPv4 multicast addresses allocated for documentation purposes are 233.252.0.0 - 233.252.0.255 (233.252.0.0/24).
对于任何源多播（ASM），为文档目的分配的IPv4多播地址为233.252.0.0-233.252.0.255（233.252.0.0/24）。
For Source-Specific Multicast (SSM), it is less important which multicast addresses are used, since a host/application joins a channel identified by both source and group. Any source addresses used in SSM examples should be unicast addresses reserved for documentation purposes. There are three unicast address ranges provided for documentation use in [RFC5737]. The ranges are 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24.
对于源特定多播（SSM），使用哪些多播地址不太重要，因为主机/应用程序加入由源和组标识的通道。SSM示例中使用的任何源地址都应该是为文档目的保留的单播地址。[RFC5737]中提供了三个单播地址范围供文档使用。范围为192.0.2.0/24、198.51.100.0/24和203.0.113.0/24。
Sometimes one wants to give examples where a specific type of address is desired. For example, for text about multicast scoping, one might want the examples to use addresses that are to be used for administrative scoping. See below for guidance on how to construct specific types of example addresses.
有时，我们想举例说明需要哪种特定类型的地址。例如，对于有关多播作用域的文本，可能希望示例使用用于管理作用域的地址。有关如何构造特定类型的示例地址的指导，请参见下文。
Administratively scoped IPv4 multicast addresses [RFC2365] are reserved for scoped multicast. They can be used within a site or an organization. Apart from a small set of scope-relative addresses, these addresses are not assigned. The high order /24 in every scope is reserved for relative assignments. A relative assignment is an integer offset from the highest address in the scope and represents an IPv4 address. For documentation purposes, the integer offset is 10. This provides one multicast address per scope.
管理作用域IPv4多播地址[RFC2365]保留给作用域多播。它们可以在站点或组织中使用。除了一小组作用域相对地址之外，这些地址没有分配。每个作用域中的高阶/24保留用于相对分配。相对分配是范围中最高地址的整数偏移量，表示IPv4地址。出于文档目的，整数偏移量为10。这为每个作用域提供一个多播地址。
For example in the Local Scope 239.255.0.0/16, the multicast address for documentation purposes is 239.255.255.245.
例如，在本地范围239.255.0.0/16中，用于文档目的的多播地址是239.255.255.245。
GLOP [RFC3180] is a method for deriving IPv4 multicast group addresses from 16-bit AS numbers. For examples where GLOP addresses are desired, the addresses should be derived from the AS numbers reserved for documentation use.
GLOP[RFC3180]是一种从16位AS数字派生IPv4多播组地址的方法。例如，如果需要GLOP地址，则地址应从保留供文档使用的AS编号派生。
The 16-bit AS numbers reserved for documentation use in [RFC5398] are 64496 - 64511. By use of [RFC3180], we then get 16 /24 multicast prefixes for documentation use. The first one is 233.251.240.0/24, and the last one is 233.251.255.0/24.
[RFC5398]中为文档使用保留的16位AS编号为64496-64511。通过使用[RFC3180]，我们可以得到16/24多播前缀供文档使用。第一个是233.251.240.0/24，最后一个是233.251.255.0/24。
IPv4 multicast addresses can be derived from IPv4 unicast prefixes, see [RFC6034]. For examples where this type of address is desired, the addresses should be derived from the unicast addresses reserved for documentation purposes, see [RFC5737].
IPv4多播地址可以从IPv4单播前缀派生，请参阅[RFC6034]。例如，如果需要这种类型的地址，则地址应从为文档目的保留的单播地址派生，请参见[RFC5737]。
There are three unicast address ranges provided for documentation use in [RFC5737]. The ranges are 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24. Using [RFC6034], this leaves the unicast prefix-based IPv4 multicast addresses 234.192.0.2, 234.198.51.100, and 234.203.0.113.
[RFC5737]中提供了三个单播地址范围供文档使用。范围为192.0.2.0/24、198.51.100.0/24和203.0.113.0/24。使用[RFC6034]，这将保留基于单播前缀的IPv4多播地址234.192.0.2、234.198.51.100和234.203.0.113。
For Any-Source Multicast (ASM), the IPv6 multicast addresses allocated for documentation purposes are FF0X::DB8:0:0/96. This is a /96 prefix so that it can be used with group IDs, according to the allocation guidelines in [RFC3307]. Also note that for these addresses, the transient flag, or "T-flag" as defined in [RFC4291], is zero. This is because they are permanently assigned. There can be no permanently assigned addresses for documentation purposes with the transient flag set to one, since the flag set to one means that they are not permanently assigned.
对于任何源多播（ASM），为文档目的分配的IPv6多播地址为FF0X:：DB8:0:0/96。根据[RFC3307]中的分配指南，这是一个/96前缀，因此可以与组ID一起使用。还请注意，对于这些地址，[RFC4291]中定义的瞬态标志或“T标志”为零。这是因为它们是永久分配的。临时标志设置为1时，不能为文档目的永久分配地址，因为标志设置为1意味着它们不是永久分配的。
For Source-Specific Multicast (SSM), it is less important which multicast addresses are used, since a host/application joins a channel identified by both source and group. Any source addresses used in SSM examples should be unicast addresses reserved for documentation purposes. The IPv6 unicast prefix reserved for documentation purposes is 2001:DB8::/32, see [RFC3849].
对于源特定多播（SSM），使用哪些多播地址不太重要，因为主机/应用程序加入由源和组标识的通道。SSM示例中使用的任何源地址都应该是为文档目的保留的单播地址。为文档目的保留的IPv6单播前缀为2001:DB8:：/32，请参阅[RFC3849]。
Sometimes one wants to give examples where a specific type of address is desired. For example, for text about multicast scoping, one might want the examples to use addresses that are to be used for administrative scoping. See below for guidance on how to construct specific types of example addresses.
有时，我们想举例说明需要哪种特定类型的地址。例如，对于有关多播作用域的文本，可能希望示例使用用于管理作用域的地址。有关如何构造特定类型的示例地址的指导，请参见下文。
IPv6 multicast addresses can be derived from IPv6 unicast prefixes, see [RFC3306]. For examples where this type of address is desired, the addresses should be derived from the unicast addresses reserved for documentation purposes.
IPv6多播地址可以从IPv6单播前缀派生，请参阅[RFC3306]。例如，如果需要这种类型的地址，则地址应该从为文档目的保留的单播地址派生。
The IPv6 unicast prefix reserved for documentation purposes is 2001: DB8::/32, see [RFC3849]. This allows a wide range of different IPv6 multicast addresses. Using just the base /32 prefix, one gets the IPv6 multicast prefixes FF3X:20:2001:DB8::/64 -- one for each available scope X. One can also produce longer prefixes from this. Just as an example, one can pick a /64 prefix 2001:DB8:DEAD: BEEF::/64, which gives the multicast prefixes FF3X:40:2001:DB8:DEAD: BEEF::/96 -- one for each available scope X.
为文档目的保留的IPv6单播前缀为2001:DB8:：/32，请参阅[RFC3849]。这允许多种不同的IPv6多播地址。仅使用base/32前缀，就可以获得IPv6多播前缀FF3X:20:2001:DB8:：/64——每个可用作用域X对应一个前缀。还可以由此产生更长的前缀。例如，可以选择一个/64前缀2001:DB8:DEAD:BEEF:：/64，它给出了多播前缀FF3X:40:2001:DB8:DEAD:BEEF:：/96——每个可用作用域X对应一个前缀。
There is a type of IPv6 multicast address called an "Embedded-RP" address, where the IPv6 address of a Rendezvous-Point (RP) is embedded inside the multicast address, see [RFC3956]. For examples where this type of address is desired, the addresses should be derived from the unicast addresses reserved for documentation purposes, see [RFC3849].
有一种称为“嵌入式RP”地址的IPv6多播地址，其中集合点（RP）的IPv6地址嵌入在多播地址中，请参见[RFC3956]。例如，如果需要这种类型的地址，则地址应从为文档目的保留的单播地址派生，请参见[RFC3849]。
For documentation purposes, the RP address can be any address from the range 2001:DB8::/32 that follows the constraints specified in [RFC3956]. One example address could be 2001:DB8::1. The Embedded-RP multicast prefixes might then be FF7X:120:2001:DB8::/96. Another example could be the RP address 2001:DB8:BEEF:FEED::7, which gives the prefixes FF7X:740:2001:DB8:BEEF:FEED::/96. See also the examples in [RFC3956].
出于文档目的，RP地址可以是范围2001:DB8:：/32中的任何地址，该范围遵循[RFC3956]中指定的约束。一个示例地址可以是2001:DB8:：1。嵌入的RP多播前缀可能是FF7X:120:2001:DB8:：/96。另一个例子是RP地址2001:DB8:BEEF:FEED:：7，它给出了前缀FF7X:740:2001:DB8:BEEF:FEED:：/96。另请参见[RFC3956]中的示例。
The use of specific multicast addresses for documentation purposes has no negative impact on security.
出于文档目的使用特定的多播地址对安全性没有负面影响。
IANA has added a reference to this document for the IPv4 MCAST-TEST-NET allocation so that all the different documentation multicast assignments reference this document.
IANA为IPv4 MCAST-TEST-NET分配添加了对此文档的引用，以便所有不同的文档多播分配都引用此文档。
IANA has assigned a scope-relative IPv4 address for documentation purposes.
IANA为文档目的分配了一个作用域相对IPv4地址。
IANA has assigned "variable-scope" IPv6 multicast addresses for documentation purposes. This is a /96 prefix.
IANA已分配“可变作用域”IPv6多播地址，以便于记录。这是一个/96前缀。
The authors thank Roberta Maglione, Leonard Giuliano and Dave Thaler for providing comments on this document.
作者感谢Roberta Maglione、Leonard Giuliano和Dave Thaler对本文件的评论。
[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月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849]Huston，G.，Lord，A.，和P.Smith，“为文档保留IPv6地址前缀”，RFC 3849，2004年7月。
[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月。
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, December 2008.
[RFC5398]Huston，G.，“文件使用的自主系统（AS）编号保留”，RFC 5398，2008年12月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月。
[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast Addresses", RFC 6034, October 2010.
[RFC6034]Thaler，D.，“基于单播前缀的IPv4多播地址”，RFC60342010年10月。
Authors' Addresses
作者地址
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: stig@cisco.com
Stig Venaas Cisco Systems Tasman Drive San Jose，CA 95134美国电子邮件：stig@cisco.com
Rishabh Parekh Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: riparekh@cisco.com
Rishabh Parekh Cisco Systems Tasman Drive San Jose，CA 95134美国电子邮件：riparekh@cisco.com
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 476 476 022 EMail: gvandeve@cisco.com
Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831比利时电话：+32 476 476 022电子邮件：gvandeve@cisco.com
Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
南安普顿南安普敦大学汉菲尔德郡SO17 17BJ提姆tjc@ecs.soton.ac.uk
Marshall Eubanks Iformata Communications 130 W. Second Street Dayton, Ohio 45402 US Phone: +1 703 501 4376 EMail: marshall.eubanks@iformata.com URI: http://www.iformata.com/
Marshall Eubanks Iformata Communications美国俄亥俄州代顿第二大街西130号45402电话：+1 703 501 4376电子邮件：Marshall。eubanks@iformata.comURI:http://www.iformata.com/