Network Working Group D. Johnson
Request for Comments: 2526 Carnegie Mellon University
Category: Standards Track S. Deering
Cisco Systems, Inc.
March 1999
Network Working Group D. Johnson
Request for Comments: 2526 Carnegie Mellon University
Category: Standards Track S. Deering
Cisco Systems, Inc.
March 1999
Reserved IPv6 Subnet Anycast 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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.
IP版本6寻址体系结构将“选播”地址定义为分配给一个或多个网络接口（通常属于不同节点）的IPv6地址，其属性是发送到选播地址的数据包路由到具有该地址的“最近”接口，根据路由协议的距离度量。本文档在每个子网前缀中定义了一组保留选播地址，并列出了这些保留子网选播地址的初始分配。
IP Version 6 (IPv6) defines a new type of address, known as an "anycast" address, that allows a packet to be routed to one of a number of different nodes all responding to the same address [2, 3]. The anycast address may be assigned to one or more network interfaces (typically on different nodes), with the network delivering each packet addressed to this address to the "nearest" interface based on the notion of "distance" determined by the routing protocols in use.
IP版本6（IPv6）定义了一种新的地址类型，称为“选播”地址，该地址允许将数据包路由到多个不同节点中的一个，所有节点都响应相同的地址[2,3]。选播地址可被分配给一个或多个网络接口（通常在不同节点上），其中网络基于所使用的路由协议确定的“距离”概念将寻址到此地址的每个分组传送到“最近的”接口。
The uses of anycast addresses are still evolving, but such addresses offer the potential for a number of important services [5, 6]. For example, an anycast address may be used to allow nodes to access one of a collection of servers providing a well-known service, without manual configuration in each node of the list of servers; or an
选播地址的使用仍在不断发展，但此类地址提供了许多重要服务的潜力[5,6]。例如，选播地址可用于允许节点访问提供已知服务的服务器集合中的一个，而无需在服务器列表的每个节点中进行手动配置；或
anycast address may be used in a source route to force routing through a specific internet service provider, without limiting routing to a single specific router providing access to that ISP.
选播地址可以在源路由中使用，以强制路由通过特定的internet服务提供商，而不限制路由到提供对该ISP访问的单个特定路由器。
IPv6 defines a required Subnet-Router anycast address [3] for all routers within a subnet prefix, and allows additional anycast addresses to be taken from the unicast address space. This document defines an additional set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.
IPv6为子网前缀内的所有路由器定义了所需的子网路由器选播地址[3]，并允许从单播地址空间获取额外的选播地址。本文档在每个子网前缀中定义了一组额外的保留选播地址，并列出了这些保留子网选播地址的初始分配。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Within each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
在每个子网中，最高的128个接口标识符值保留为子网选播地址分配。
The construction of a reserved subnet anycast address depends on the type of IPv6 addresses used within the subnet, as indicated by the format prefix in the addresses. In particular, for IPv6 address types required to have 64-bit interface identifiers in EUI-64 format, the universal/local bit MUST be set to 0 (local) in all reserved subnet anycast addresses, to indicate that the interface identifier in the address is not globally unique. IPv6 addresses of this type are currently specified to be those having format prefixes 001 through 111, except for Multicast Addresses (1111 1111) [3].
保留子网选播地址的构造取决于子网内使用的IPv6地址类型，如地址中的格式前缀所示。特别是，对于需要具有EUI-64格式的64位接口标识符的IPv6地址类型，必须在所有保留子网选播地址中将通用/本地位设置为0（本地），以指示地址中的接口标识符不是全局唯一的。此类型的IPv6地址当前指定为具有格式前缀001到111的地址，但多播地址（1111 1111）[3]除外。
Specifically, for IPv6 address types required to have to have 64-bit interface identifiers in EUI-64 format, these reserved subnet anycast addresses are constructed as follows:
具体而言，对于需要具有EUI-64格式的64位接口标识符的IPv6地址类型，这些保留子网选播地址的构造如下：
| 64 bits | 57 bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
| 64 bits | 57 bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
For other IPv6 address types (that is, with format prefixes other than those listed above), the interface identifier is not in EUI-64 format and may be other than 64 bits in length; these reserved subnet anycast addresses for such address types are constructed as follows:
对于其他IPv6地址类型（即，格式前缀不是上面列出的前缀），接口标识符不是EUI-64格式，长度可能不是64位；这些地址类型的保留子网选播地址构造如下：
| n bits | 121-n bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
| n bits | 121-n bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
The subnet prefix here consists of all fields of the IPv6 address except the interface identifier field. The interface identifier field in these reserved subnet anycast addresses is formed from a 7-bit anycast identifier ("anycast ID"), with the remaining (highest order) bits filled with all one's; however, for interface identifiers in EUI-64 format, the universal/local bit in the interface identifier MUST be set to 0. The anycast identifier identifies a particular reserved anycast address within the subnet prefix, from the set of reserved subnet anycast addresses.
此处的子网前缀由IPv6地址的所有字段组成，接口标识符字段除外。这些保留子网选播地址中的接口标识符字段由7位选播标识符（“选播ID”）构成，剩余的（最高阶）位填充了所有的；但是，对于EUI-64格式的接口标识符，接口标识符中的通用/本地位必须设置为0。选播标识符从保留子网选播地址集中标识子网前缀内的特定保留选播地址。
The motivation for reserving the highest addresses from each subnet rather than the lowest addresses, is to avoid conflicting with some existing official and unofficial uses of the low-numbered addresses in a subnet. For example, these low-numbered addresses are often used for the ends of a point-to-point link, for tunnel endpoints, for manually configured unicast addresses when a hardware token is not available for the network interface, and even for manually configured static addresses for the routers on a link. Reserving only 128 values for anycast identifiers (rather than perhaps 256) means that the minimum possible size of interface identifiers in an IPv6 address is 8 bits (including room in the subnet for unicast addresses as well as reserved subnet anycast addresses), allowing the division between subnet prefix and interface identifier in this case to be byte-aligned.
保留每个子网中的最高地址而不是最低地址的动机是为了避免与子网中低编号地址的某些现有官方和非官方使用相冲突。例如，这些编号较低的地址通常用于点到点链路的端部、隧道端点、网络接口没有硬件令牌时手动配置的单播地址，甚至用于链路上路由器的手动配置静态地址。仅为选播标识符保留128个值（而不是256个）意味着IPv6地址中接口标识符的最小可能大小为8位（包括单播地址子网中的空间以及保留的子网选播地址），在这种情况下，允许子网前缀和接口标识符之间的划分按字节对齐。
As with all IPv6 anycast addresses [3], these reserved subnet anycast addresses are allocated from the IPv6 unicast address space. All reserved subnet anycast addresses as defined in this document are reserved on all links, with all subnet prefixes. They MUST NOT be used for unicast addresses assigned to any interface.
与所有IPv6选播地址[3]一样，这些保留子网选播地址是从IPv6单播地址空间分配的。本文档中定义的所有保留子网选播地址都保留在所有链接上，并带有所有子网前缀。它们不得用于分配给任何接口的单播地址。
Currently, the following anycast identifiers for these reserved subnet anycast addresses are defined:
目前，为这些保留子网选播地址定义了以下选播标识符：
Decimal Hexadecimal Description
------- ----------- -----------
127 7F Reserved
126 7E Mobile IPv6 Home-Agents anycast [4]
0-125 00-7D Reserved
Decimal Hexadecimal Description
------- ----------- -----------
127 7F Reserved
126 7E Mobile IPv6 Home-Agents anycast [4]
0-125 00-7D Reserved
Additional anycast identifiers are expected to be defined in the future.
预计将来会定义更多的选播标识符。
To illustrate the construction of reserved subnet anycast addresses, this section details the construction of the reserved Mobile IPv6 Home-Agents subnet anycast address [4]. As noted in Section 3, the 7-bit anycast identifier for the Mobile IPv6 Home-Agents anycast address is 126 (decimal) or 7E (hexadecimal).
为了说明保留子网选播地址的构造，本节详细介绍了保留移动IPv6 Home Agent子网选播地址的构造[4]。如第3节所述，移动IPv6 Home Agent选播地址的7位选播标识符为126（十进制）或7E（十六进制）。
For IPv6 addresses containing a format prefix indicating that interface identifiers are required to be 64 bits in length and are required to be in EUI-64 format (currently format prefixes 001 through 111, except for 1111 1111 [3]), the reserved Mobile IPv6 Home-Agents subnet anycast address consists of the 64-bit subnet prefix followed by the 64-bit interface identifier shown below:
对于包含格式前缀的IPv6地址，该格式前缀指示接口标识符的长度必须为64位，并且必须为EUI-64格式（目前的格式前缀为001到111，1111 1111[3]除外），保留的移动IPv6 Home Agent子网选播地址由64位子网前缀和64位接口标识符组成，如下所示：
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|1111110111111111|1111111111111111|1111111111111111|1111111111111110|
+----------------+----------------+----------------+----------------+
^ ^^^^^^^
+--- universal/local bit anycast identifier ---+-----+
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|1111110111111111|1111111111111111|1111111111111111|1111111111111110|
+----------------+----------------+----------------+----------------+
^ ^^^^^^^
+--- universal/local bit anycast identifier ---+-----+
For other IPv6 address types, the interface identifier may be other than 64 bits in length and is not in EUI-64 format. In this example, assume that the length of the interface identifier is 64 bits, to allow clear comparison with the example given above (although interface identifiers of lengths other than 64 bits follow the same general construction of the interface identifier shown here). In this case, the reserved Mobile IPv6 Home-Agents subnet anycast address consists of the 64-bit subnet prefix followed by the 64-bit interface identifier shown below:
对于其他IPv6地址类型，接口标识符的长度可能不是64位，并且不是EUI-64格式。在此示例中，假设接口标识符的长度为64位，以允许与上面给出的示例进行清晰的比较（尽管长度不是64位的接口标识符遵循此处所示的接口标识符的相同一般构造）。在这种情况下，保留的移动IPv6 Home Agent子网选播地址由64位子网前缀和64位接口标识符组成，如下所示：
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|1111111111111111|1111111111111111|1111111111111111|1111111111111110|
+----------------+----------------+----------------+----------------+
^^^^^^^
anycast identifier ---+-----+
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|1111111111111111|1111111111111111|1111111111111111|1111111111111110|
+----------------+----------------+----------------+----------------+
^^^^^^^
anycast identifier ---+-----+
This document defines a set of reserved subnet anycast addresses, based on a set of anycast identifiers within each subnet prefix in the IPv6 unicast address space. As future needs arise, new anycast identifiers may be defined. Such anycast identifiers MUST be reserved within all subnet prefixes, and so the assignment of these anycast identifiers requires centralized administration. New values SHOULD be assigned in descending numerical order and are expected to be assigned only with IESG approval.
本文档基于IPv6单播地址空间中每个子网前缀内的一组选播标识符定义了一组保留子网选播地址。随着未来需求的出现，可以定义新的选播标识符。这些选播标识符必须保留在所有子网前缀中，因此这些选播标识符的分配需要集中管理。新值应按数字降序分配，且仅在获得IESG批准后才能分配。
The use of any type of reserved anycast addresses poses a security concern only in allowing potential attackers a well-known address to attack. By designating certain services to be located at specific reserved anycast addresses, an attacker may more profitably focus an attack against such a specific service. Any such attack, however, is best dealt with in each service that uses a reserved anycast address.
使用任何类型的保留选播地址只会在允许潜在攻击者攻击已知地址时引起安全问题。通过指定特定服务位于特定的保留选播地址，攻击者可以更有利地集中攻击此类特定服务。但是，最好在使用保留选播地址的每个服务中处理任何此类攻击。
RFC 1546, which originally proposed the idea of anycasting in IP, also points out a number of security considerations with the use of anycasting in general [6].
RFC 1546最初提出了IP中任意广播的想法，同时也指出了一般使用任意广播时的一些安全注意事项[6]。
References
工具书类
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] Deering，S.和R.Hinden，“互联网协议版本6（IPv6）规范”，RFC 2460，1998年12月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[3] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[4] David B. Johnson and Charles Perkins, "Mobility Support in IPv6", Work in Progress.
[4] David B.Johnson和Charles Perkins，“IPv6中的移动支持”，正在进行中。
[5] Steve King et al, "The Case for IPv6", Work in Progress.
[5] Steve King等人，“IPv6案例”，正在进行中。
[6] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[6] 帕特里奇，C.，门德斯，T.和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
Authors' Addresses
作者地址
David B. Johnson Carnegie Mellon University Computer Science Department 5000 Forbes Avenue Pittsburgh, PA 15213-3891 USA
美国宾夕法尼亚州匹兹堡福布斯大道5000号大卫·B·约翰逊卡内基梅隆大学计算机科学系15213-3891
Phone: +1 412 268-7399
Fax: +1 412 268-5576
EMail: dbj@cs.cmu.edu
Phone: +1 412 268-7399
Fax: +1 412 268-5576
EMail: dbj@cs.cmu.edu
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E.Deering Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1 408 527-8213
Fax: +1 408 527-8254
EMail: deering@cisco.com
Phone: +1 408 527-8213
Fax: +1 408 527-8254
EMail: deering@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。