Network Working Group S. Deering Request for Comments: 4007 Cisco Systems Category: Standards Track B. Haberman Johns Hopkins Univ T. Jinmei Toshiba E. Nordmark Sun Microsystems B. Zill Microsoft March 2005
Network Working Group S. Deering Request for Comments: 4007 Cisco Systems Category: Standards Track B. Haberman Johns Hopkins Univ T. Jinmei Toshiba E. Nordmark Sun Microsystems B. Zill Microsoft March 2005
IPv6 Scoped Address Architecture
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 (2005).
版权所有(C)互联网协会(2005年)。
Abstract
摘要
This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.
本文档指定了不同范围的IPv6地址的体系结构特征、预期行为、文本表示和用法。根据IPv6工作组的一项决定,本文档有意避免单播站点本地地址的语法和用法。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3 4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3 5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11 9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Textual Representation . . . . . . . . . . . . . . . . . . . 15 11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15 11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15 11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17 11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17 11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18 11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 18 11.7. Combinations of Delimiter Characters. . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3 4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3 5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11 9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Textual Representation . . . . . . . . . . . . . . . . . . . 15 11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15 11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15 11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17 11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17 11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18 11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 18 11.7. Combinations of Delimiter Characters. . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 24
Internet Protocol version 6 includes support for addresses of different "scope"; that is, both global and non-global (e.g., link-local) addresses. Although non-global addressing has been introduced operationally in the IPv4 Internet, both in the use of private address space ("net 10", etc.) and with administratively scoped multicast addresses, the design of IPv6 formally incorporates the notion of address scope into its base architecture. This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes.
Internet协议版本6包括对不同“范围”地址的支持;即,全局和非全局(例如,链路本地)地址。尽管在IPv4 Internet中引入了非全局寻址,无论是在专用地址空间(“net 10”等)的使用中还是在管理范围的多播地址中,IPv6的设计都将地址范围的概念正式纳入其基本体系结构。本文档指定了不同范围的IPv6地址的体系结构特征、预期行为、文本表示和用法。
Though the current address architecture specification [1] defines unicast site-local addresses, the IPv6 working group decided to deprecate the syntax and the usage [5] and is now investigating other forms of local IPv6 addressing. The usage of any new forms of
虽然当前的地址体系结构规范[1]定义了单播站点本地地址,但IPv6工作组决定反对该语法和用法[5],目前正在研究其他形式的本地IPv6寻址。使用任何新形式的
local addresses will be documented elsewhere in the future. Thus, this document intentionally focuses on link-local and multicast scopes only.
本地地址将在将来的其他地方记录。因此,本文档有意只关注链路本地和多播范围。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[2]中所述进行解释。
The terms link, interface, node, host, and router are defined in [3]. The definitions of unicast address scopes (link-local and global) and multicast address scopes (interface-local, link-local, etc.) are contained in [1].
术语链路、接口、节点、主机和路由器在[3]中定义。[1]中包含了单播地址范围(链路本地和全局)和多播地址范围(接口本地、链路本地等)的定义。
Every IPv6 address other than the unspecified address has a specific scope; that is, a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. The scope of an address is encoded as part of the address, as specified in [1].
除了未指定的地址之外,每个IPv6地址都有一个特定的范围;也就是说,一个拓扑范围,在此范围内,地址可以用作一个接口或一组接口的唯一标识符。地址的范围被编码为地址的一部分,如[1]中所述。
For unicast addresses, this document discusses two defined scopes:
对于单播地址,本文档讨论两个定义的范围:
o Link-local scope, for uniquely identifying interfaces within (i.e., attached to) a single link only.
o 链接本地范围,仅用于唯一标识单个链接内(即连接到)的接口。
o Global scope, for uniquely identifying interfaces anywhere in the Internet.
o 全局范围,用于唯一标识Internet中任何位置的接口。
The IPv6 unicast loopback address, ::1, is treated as having link-local scope within an imaginary link to which a virtual "loopback interface" is attached.
IPv6单播环回地址::1被视为在虚拟链路内具有链路本地作用域,虚拟“环回接口”连接到该链路。
The unspecified address, ::, is a special case. It does not have any scope because it must never be assigned to any node according to [1]. Note, however, that an implementation might use an implementation dependent semantics for the unspecified address and may want to allow the unspecified address to have specific scopes. For example, implementations often use the unspecified address to represent "any" address in APIs. In this case, implementations may regard the unspecified address with a given particular scope as representing the notion of "any address in the scope". This document does not prohibit such a usage, as long as it is limited within the implementation.
未指定的地址是一个特例。它没有任何作用域,因为根据[1],它决不能分配给任何节点。但是,请注意,实现可能会对未指定的地址使用依赖于实现的语义,并且可能希望允许未指定的地址具有特定的作用域。例如,实现通常使用未指定的地址来表示API中的“任意”地址。在这种情况下,实现可能将具有给定特定范围的未指定地址视为表示“范围中的任何地址”的概念。本文档不禁止此类使用,只要它在实现中受到限制。
[1] defines IPv6 addresses with embedded IPv4 addresses as being part of global addresses. Thus, those addresses have global scope, with regard to the IPv6 scoped address architecture. However, an implementation may use those addresses as if they had other scopes for convenience. For instance, [6] assigns link-local scope to IPv4 auto-configured link-local addresses (the addresses from the prefix 169.254.0.0/16 [7]) and converts those addresses into IPv4-mapped IPv6 addresses in order to perform destination address selection among IPv4 and IPv6 addresses. This would implicitly mean that the IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration link-local addresses have link-local scope. This document does not preclude such a usage, as long as it is limited within the implementation.
[1] 将嵌入IPv4地址的IPv6地址定义为全局地址的一部分。因此,就IPv6作用域地址体系结构而言,这些地址具有全局作用域。但是,为了方便起见,实现可以使用这些地址,就好像它们有其他作用域一样。例如,[6]将链路本地作用域分配给IPv4自动配置的链路本地地址(前缀169.254.0.0/16[7]中的地址),并将这些地址转换为IPv4映射的IPv6地址,以便在IPv4和IPv6地址之间执行目标地址选择。这意味着与IPv4自动配置链路本地地址等效的IPv4映射IPv6地址具有链路本地作用域。本文档不排除这种用法,只要它在实现中受到限制。
Anycast addresses [1] are allocated from the unicast address space and have the same scope properties as unicast addresses. All statements in this document regarding unicast apply equally to anycast.
选播地址[1]是从单播地址空间分配的,与单播地址具有相同的作用域属性。本文件中关于单播的所有声明同样适用于任意广播。
For multicast addresses, there are fourteen possible scopes, ranging from interface-local to global (including link-local). The interface-local scope spans a single interface only; a multicast address of interface-local scope is useful only for loopback delivery of multicasts within a single node; for example, as a form of inter-process communication within a computer. Unlike the unicast loopback address, interface-local multicast addresses may be assigned to any interface.
对于多播地址,有14个可能的作用域,范围从接口本地到全局(包括链路本地)。接口局部范围仅跨越单个接口;接口本地作用域的多播地址仅用于单个节点内多播的环回传送;例如,作为计算机内进程间通信的一种形式。与单播环回地址不同,接口本地多播地址可以分配给任何接口。
There is a size relationship among scopes:
作用域之间存在大小关系:
o For unicast scopes, link-local is a smaller scope than global.
o 对于单播作用域,链路本地作用域小于全局作用域。
o For multicast scopes, scopes with lesser values in the "scop" subfield of the multicast address (Section 2.7 of [1]) are smaller than scopes with greater values, with interface-local being the smallest and global being the largest.
o 对于多播作用域,在多播地址的“scop”子字段中具有较小值的作用域(见[1]第2.7节)小于具有较大值的作用域,其中接口本地最小,全局最大。
However, two scopes of different size may cover the exact same region of topology. For example, a (multicast) site may consist of a single link, in which both link-local and site-local scope effectively cover the same topological span.
但是,两个大小不同的范围可能覆盖完全相同的拓扑区域。例如,(多播)站点可能由单个链路组成,其中链路本地范围和站点本地范围有效地覆盖相同的拓扑跨度。
A scope zone, or simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routers within a particular (multicast) site, and the interfaces attached to those links, comprise a single zone of multicast site-local scope.
作用域区域,或简称为区域,是给定作用域拓扑的连接区域。例如,由特定(多播)站点内的路由器连接的链路集,以及附加到这些链路的接口,包括多播站点本地范围的单个区域。
Note that a zone is a particular instance of a topological region (e.g., Alice's site or Bob's site), whereas a scope is the size of a topological region (e.g., a site or a link).
请注意,分区是拓扑区域(例如Alice的站点或Bob的站点)的特定实例,而范围是拓扑区域(例如站点或链接)的大小。
The zone to which a particular non-global address pertains is not encoded in the address itself but determined by context, such as the interface from which it is sent or received. Thus, addresses of a given (non-global) scope may be re-used in different zones of that scope. For example, two different physical links may each contain a node with the link-local address fe80::1.
特定非全局地址所属的区域不是在地址本身中编码的,而是由上下文(如从中发送或接收地址的接口)确定的。因此,给定(非全局)作用域的地址可以在该作用域的不同区域中重复使用。例如,两个不同的物理链路可能各自包含一个链路本地地址为fe80::1的节点。
Zones of the different scopes are instantiated as follows:
不同作用域的区域实例化如下:
o Each interface on a node comprises a single zone of interface-local scope (for multicast only).
o 节点上的每个接口都包含接口本地作用域的单个区域(仅适用于多播)。
o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast).
o 每个链路和连接到该链路的接口都包含一个链路本地作用域区域(对于单播和多播)。
o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet.
o 有一个单一的全局范围区域(单播和多播),包括Internet中的所有链接和接口。
o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators.
o 网络管理员必须定义和配置除接口本地、链路本地和全局之外的作用域的区域边界。
Zone boundaries are relatively static features, not changing in response to short-term changes in topology. Thus, the requirement that the topology within a zone be "connected" is intended to include links and interfaces that may only be occasionally connected. For example, a residential node or network that obtains Internet access by dial-up to an employer's (multicast) site may be treated as part of the employer's (multicast) site-local zone even when the dial-up link is disconnected. Similarly, a failure of a router, interface, or link that causes a zone to become partitioned does not split that zone into multiple zones. Rather, the different partitions are still considered to belong to the same zone.
分区边界是相对静态的特征,不会随拓扑结构的短期变化而变化。因此,区域内拓扑“连接”的要求旨在包括可能仅偶尔连接的链路和接口。例如,即使在拨号链路断开时,通过拨号到雇主(多播)站点获得因特网接入的住宅节点或网络也可以被视为雇主(多播)站点本地区域的一部分。类似地,导致分区的路由器、接口或链路故障不会将该分区拆分为多个分区。相反,不同的分区仍然被认为属于同一个分区。
Zones have the following additional properties:
分区具有以下附加属性:
o Zone boundaries cut through nodes, not links. (Note that the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.)
o 分区边界穿过节点,而不是链接。(请注意,全局分区没有边界,而接口局部分区的边界仅包含一个接口。)
o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common.
o 同一范围的区域不能重叠;i、 例如,它们可以没有共同的链接或接口。
o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces.
o 给定范围(小于全局范围)的区域完全位于范围更大的区域内。也就是说,一个较小范围的区域不能包含比任何与其共享任何链接或接口的较大范围区域更多的拓扑。
o Each zone is required to be "convex" from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property.
o 从布线角度来看,每个区域都必须是“凸”的;i、 例如,从一个接口发送到同一区域内任何其他接口的数据包永远不会路由到该区域之外。但是,请注意,如果区域包含隧道链路(例如,IPv6-over-IPv6隧道链路[8]),则隧道的较低层网络可以位于区域之外,而不会破坏凸性特性。
Each interface belongs to exactly one zone of each possible scope. Note that this means that an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface.
每个接口只属于每个可能作用域的一个区域。请注意,这意味着无论接口具有何种单播地址或节点在接口上加入哪些多播组,接口都属于作用域。
Because the same non-global address may be in use in more than one zone of the same scope (e.g., the use of link-local address fe80::1 in two separate physical links) and a node may have interfaces attached to different zones of the same scope (e.g., a router normally has multiple interfaces attached to different links), a node requires an internal means to identify to which zone a non-global address belongs. This is accomplished by assigning, within the node, a distinct "zone index" to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index.
因为相同的非全局地址可能在相同作用域的多个区域中使用(例如,在两个单独的物理链路中使用链路本地地址fe80::1),并且节点可能具有连接到相同作用域的不同区域的接口(例如,路由器通常具有连接到不同链路的多个接口),节点需要一种内部方法来标识非全局地址所属的区域。这是通过在节点内将不同的“区域索引”分配给该节点所附加到的相同范围内的每个区域,并通过允许地址的所有内部使用由区域索引限定来实现的。
The assignment of zone indices is illustrated in the example in the figure below:
下图中的示例说明了分区索引的分配:
--------------------------------------------------------------- | a node | | | | | | | | | | | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link
--------------------------------------------------------------- | a node | | | | | | | | | | | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link
Figure 1: Zone Indices Example
图1:区域索引示例
This example node has five interfaces:
此示例节点有五个接口:
A loopback interface to the imaginary loopback link (a phantom link that goes nowhere).
指向虚拟环回链接(无处可去的幻影链接)的环回接口。
Two interfaces to the same Ethernet link.
同一以太网链路的两个接口。
An interface to a point-to-point link.
指向点到点链接的接口。
A tunnel interface (e.g., the abstract endpoint of an IPv6-over-IPv6 tunnel [8], presumably established over either the Ethernet or the point-to-point link).
隧道接口(例如,IPv6-over-IPv6隧道[8]的抽象端点,可能通过以太网或点对点链路建立)。
It is thus attached to five interface-local zones, identified by the interface indices 1 through 5.
因此,它与五个界面局部区域相连,由界面指数1至5确定。
Because the two Ethernet interfaces are attached to the same link, the node is only attached to four link-local zones, identified by link indices 1 through 4. Also note that even if the tunnel interface is established over the Ethernet, the tunnel link gets its own link index, which is different from the index of the Ethernet link zone.
由于两个以太网接口连接到同一链路,因此节点仅连接到四个链路本地区域,由链路索引1到4标识。还要注意的是,即使隧道接口是通过以太网建立的,隧道链路也会获得自己的链路索引,这与以太网链路区域的索引不同。
Each zone index of a particular scope should contain enough information to indicate the scope, so that all indices of all scopes are unique within the node and zone indices themselves can be used for a dedicated purpose. Usage of the index to identify an entry in the Management Information Base (MIB) is an example of the dedicated purpose. The actual representation to encode the scope is implementation dependent and is out of scope of this document. Within this document, indices are simply represented in a format such as "link index 2" for readability.
特定作用域的每个区域索引应包含足够的信息来指示该作用域,以便所有作用域的所有索引在节点内都是唯一的,并且区域索引本身可用于专用目的。使用索引标识管理信息库(MIB)中的条目就是专用目的的一个示例。对范围进行编码的实际表示取决于实现,超出了本文档的范围。在本文档中,为了便于阅读,索引仅以“链接索引2”等格式表示。
The zone indices are strictly local to the node. For example, the node on the other end of the point-to-point link may well use entirely different interface and link index values for that link.
分区索引对于节点来说是严格的局部索引。例如,点到点链接另一端的节点可能会为该链接使用完全不同的接口和链接索引值。
An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone". Unlike other zone indices, the default index does not contain any scope, and the scope is determined by the address that the default index accompanies. An implementation may additionally define a separate default zone for each scope. Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone; e.g., when using global addresses.
实现还应该支持每个范围的“默认”区域的概念。而且,如果支持,每个范围的索引值0应该保留为“使用默认区域”。与其他区域索引不同,默认索引不包含任何范围,范围由默认索引附带的地址确定。实现还可以为每个范围定义单独的默认区域。这些默认索引还可以用作节点仅连接到一个区域的地址的区域限定符;e、 例如,当使用全局地址时。
At present, there is no way for a node to automatically determine which of its interfaces belong to the same zones; e.g., the same link or the same multicast scope zone larger than interface. In the future, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices. Furthermore, to avoid performing manual configuration in most cases, an implementation should, by default, initially assign zone indices only as follows:
目前,节点无法自动确定其哪些接口属于相同的区域;e、 例如,同一链路或同一多播作用域大于接口。将来,可能会制定协议来确定该信息。在没有此类协议的情况下,实施必须提供手动分配和/或重新分配区域索引的方法。此外,为了避免在大多数情况下执行手动配置,在默认情况下,实现最初应仅按以下方式分配分区索引:
o A unique interface index for each interface.
o 每个接口的唯一接口索引。
o A unique link index for each interface.
o 每个接口的唯一链接索引。
Then manual configuration would only be necessary for the less common cases of nodes with multiple interfaces to a single link or of those with interfaces to zones of different (multicast-only) scopes.
然后,手动配置仅适用于对单个链路具有多个接口的节点或对不同(仅多播)范围的区域具有接口的节点的不太常见的情况。
Thus, the default zone index assignments for the example node from Figure 1 would be as illustrated in Figure 2, below. Manual configuration would then be required to, for example, assign the same link index to the two Ethernet interfaces, as shown in Figure 1.
因此,图1中示例节点的默认区域索引分配如下图2所示。然后需要手动配置,例如,将相同的链路索引分配给两个以太网接口,如图1所示。
--------------------------------------------------------------- | a node | | | | | | | | | | | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link
--------------------------------------------------------------- | a node | | | | | | | | | | | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link
Figure 2: Example of Default Zone Indices
图2:默认区域索引示例
As well as initially assigning zone indices, as specified above, an implementation should automatically select a default zone for each scope for which there is more than one choice, to be used whenever an address is specified without a zone index (or with a zone index of zero). For instance, in the example shown in Figure 2, the implementation might automatically select intf2 and link2 as the default zones for each of those two scopes. (One possible selection algorithm is to choose the first zone that includes an interface other than the loopback interface as the default for each scope.) A means must also be provided to assign the default zone for a scope manually, overriding any automatic assignment.
正如上面指定的那样,除了最初分配区域索引外,实现还应该为每个范围自动选择一个默认区域(对于每个范围有多个选择),以便在指定地址时不使用区域索引(或区域索引为零)。例如,在图2所示的示例中,实现可能会自动选择intf2和link2作为这两个作用域的默认区域。(一种可能的选择算法是选择第一个包含除环回接口以外的接口的区域作为每个范围的默认区域。)还必须提供一种方法,手动为范围分配默认区域,覆盖任何自动分配。
The unicast loopback address, ::1, may not be assigned to any interface other than the loopback interface. Therefore, it is recommended that, whenever ::1 is specified without a zone index or with the default zone index, it be interpreted as belonging to the loopback link-local zone, regardless of which link-local zone has been selected as the default. If this is done, then for nodes with only a single non-loopback interface (e.g., a single Ethernet interface), the common case, link-local addresses need not be qualified with a zone index. The unqualified address ::1 would always refer to the link-local zone containing the loopback interface. All other unqualified link-local addresses would refer to the link-local zone containing the non-loopback interface (as long as the default link-local zone was set to be the zone containing the non-loopback interface).
单播环回地址::1不能分配给环回接口以外的任何接口。因此,建议在没有区域索引或使用默认区域索引指定::1时,将其解释为属于环回链路本地区域,而不管选择哪个链路本地区域作为默认区域。如果这样做,那么对于只有单个非环回接口(例如,单个以太网接口)的节点,通常情况下,链路本地地址不需要使用区域索引进行限定。非限定地址::1将始终引用包含环回接口的链接本地区域。所有其他非限定链路本地地址都将引用包含非环回接口的链路本地区域(只要将默认链路本地区域设置为包含非环回接口的区域)。
Because of the requirement that a zone of a given scope fall completely within zones of larger scope (see Section 5, above), two interfaces assigned to different zones of scope S must also be assigned to different zones of all scopes smaller than S. Thus, the manual assignment of distinct zone indices for one scope may require the automatic assignment of distinct zone indices for smaller scopes. For example, suppose that distinct multicast site-local indices 1 and 2 are manually assigned in Figure 1 and that site 1 contains links 1, 2, and 3, but site 2 only contains link 4. This configuration would cause the automatic creation of corresponding admin-local (i.e., multicast "scop" value 4) indices 1 and 2, because admin-local scope is smaller than site-local scope.
由于要求给定范围的区域完全位于较大范围的区域内(见上文第5节),分配给不同范围S的两个接口也必须分配给小于S的所有范围的不同区域。因此,手动为一个作用域分配不同的区域索引可能需要为较小的作用域自动分配不同的区域索引。例如,假设在图1中手动分配了不同的多播站点本地索引1和2,站点1包含链接1、2和3,但站点2仅包含链接4。此配置将导致自动创建相应的管理本地(即多播“scop”值4)索引1和2,因为管理本地作用域小于站点本地作用域。
With the above considerations, the complete set of zone indices for our example node from Figure 1, with the additional configurations here, is shown in Figure 3, below.
考虑到上述因素,图1中示例节点的完整区域索引集以及此处的附加配置如下图3所示。
--------------------------------------------------------------- | a node | | | | | | | | | | | | /--------------------site1--------------------\ /--site2--\ | | | | /-------------------admin1--------------------\ /-admin2--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link
--------------------------------------------------------------- | a node | | | | | | | | | | | | /--------------------site1--------------------\ /--site2--\ | | | | /-------------------admin1--------------------\ /-admin2--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link
Figure 3: Complete Zone Indices Example
图3:完整区域索引示例
Although the above examples show the zones being assigned index values sequentially for each scope, starting at one, the zone index values are arbitrary. An implementation may label a zone with any value it chooses, as long as the index value of each zone of all scopes is unique within the node. Zero SHOULD be reserved to represent the default zone. Implementations choosing to follow the recommended basic API [10] will want to restrict their index values
尽管上面的示例显示了为每个范围顺序分配索引值的分区(从一个开始),但分区索引值是任意的。一个实现可以用它选择的任何值标记一个区域,只要所有作用域的每个区域的索引值在节点中都是唯一的。应保留零以表示默认区域。选择遵循推荐的基本API[10]的实现将希望限制其索引值
to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure.
对于那些可以由sockaddr_in6结构的sin6_scope_id字段表示的。
When an upper-layer protocol sends a packet to a non-global destination address, it must have a means of identifying the intended zone to the IPv6 layer for cases in which the node is attached to more than one zone of the destination address's scope.
当上层协议将数据包发送到非全局目的地地址时,它必须有一种方法,用于在节点连接到目的地地址范围的多个区域的情况下,将预期区域标识到IPv6层。
Although identification of an outgoing interface is sufficient to identify an intended zone (because each interface is attached to no more than one zone of each scope), in many cases that is more specific than desired. For example, when sending to a link-local unicast address from a node that has more than one interface to the intended link (an unusual configuration), the upper layer protocol may not care which of those interfaces is used for the transmission. Rather, it would prefer to leave that choice to the routing function in the IP layer. Thus, the upper-layer requires the ability to specify a zone index, when sending to a non-global, non-loopback destination address.
尽管对外接口的标识足以标识预期区域(因为每个接口连接到每个范围的一个区域),但在许多情况下,这比期望的更具体。例如,当从具有到预定链路的多个接口的节点向链路本地单播地址发送时(不寻常的配置),上层协议可能不关心这些接口中的哪一个用于传输。相反,它更愿意将选择权留给IP层中的路由功能。因此,当发送到非全局、非环回的目标地址时,上层需要能够指定区域索引。
When an upper-layer protocol receives a packet containing a non-global source or destination address, the zone to which that address pertains can be determined from the arrival interface, because the arrival interface can be attached to only one zone of the same scope as that of the address under consideration. However, it is recommended that the IP layer convey to the upper layer the correct zone indices for the arriving source and destination addresses, in addition to the arrival interface identifier.
当上层协议接收到包含非全局源地址或目的地址的分组时,可以从到达接口确定该地址所属的区域,因为到达接口只能连接到与所考虑的地址范围相同的一个区域。但是,除了到达接口标识符外,建议IP层向上层传递到达源地址和目的地址的正确区域索引。
When a router receives a packet addressed to a node other than itself, it must take the zone of the destination and source addresses into account as follows:
当路由器接收到一个地址不是它自己的节点的数据包时,它必须考虑目的地和源地址的区域,如下所示:
o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a (conceptual) routing table specific to that zone (see Section 10). That routing table is restricted to refer to interfaces belonging to that zone.
o 目的地址的区域由数据包的地址范围和到达接口确定。通过在特定于该区域的(概念)路由表中查找目标地址来选择下一跳接口(参见第10节)。该路由表被限制为引用属于该区域的接口。
o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. Additionally, if the packet's destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note that Code 2 is currently left as unassigned in [4], but the IANA will re-assign the value for the new purpose, and [4] will be revised with this change.
o 选择下一跳接口后,将考虑源地址的区域。与目的地址一样,源地址的区域由数据包的地址范围和到达接口确定。如果在所选择的下一跳接口上传输分组将导致分组离开源地址的区域,即,越过源地址范围的区域边界,则丢弃分组。此外,如果数据包的目的地地址是单播地址,则将代码为2(“超出源地址范围”)的ICMP目的地不可访问消息[4]发送到原始数据包的源。请注意,代码2目前在[4]中保留为未分配,但IANA将为新用途重新分配该值,并且[4]将根据此更改进行修订。
Note that even if unicast site-local addresses are deprecated, the above procedure still applies to link-local addresses. Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link.
请注意,即使不推荐使用单播站点本地地址,上述过程仍适用于链接本地地址。因此,如果路由器接收到链路本地目的地地址不是到达链路上路由器自身链路本地地址之一的分组,则期望路由器尝试将该分组转发到该链路上的目的地(取决于通过邻居发现协议成功确定目的地的链路层地址)[9] )。转发的数据包可通过到达接口或通过连接到同一链路的任何其他接口传回。
A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left (Section 4.4 of [3]) first checks the scope of the next address in the Routing Header. If the scope of the next address is smaller than the scope of the original destination address, the node MUST discard the packet. Otherwise, it swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules apply as follows:
一个节点接收到一个地址为自身的数据包,该数据包包含一个剩余段数超过零的路由报头(见[3]第4.4节),该节点首先检查路由报头中下一个地址的范围。如果下一个地址的范围小于原始目的地地址的范围,则节点必须丢弃该数据包。否则,它会将原始目标地址与路由头中的下一个地址交换。然后,上述转发规则适用如下:
o The zone of the new destination address is determined by the scope of the next address and the arrival interface of the packet. The next-hop interface is chosen as per the first bullet of the rules above.
o 新目的地址的区域由下一个地址的范围和数据包的到达接口确定。根据上述规则的第一个项目符号选择下一跳接口。
o After the next-hop interface is chosen, the zone of the source address is considered as per the second bullet of the rules above.
o 选择下一跳接口后,根据上述规则的第二个项目符号考虑源地址的区域。
This check about the scope of the next address ensures that when a packet arrives at its final destination, if that destination is link-local, then the receiving node can know that the packet
这种关于下一个地址范围的检查确保当数据包到达其最终目的地时,如果该目的地是链路本地的,则接收节点可以知道该数据包是本地的
originated on-link. This will help the receiving node send a "response" packet with the final destination of the received packet as the source address without breaking its source zone.
源于链接。这将有助于接收节点发送一个“响应”数据包,该数据包的最终目的地作为源地址,而不会中断其源区域。
Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary in the previously used next address field. For example, consider a case in which a link-border node (e.g., a router) receives a packet with the destination being a link-local address, and the source address a global address. If the packet contains a Routing Header where the next address is a global address, the next-hop interface to the global address may belong to a different link than that of the original destination. This is allowed because the scope of the next address is not smaller than the scope of the original destination.
请注意,尽管通常不可取,但在先前使用的下一个地址字段中,可以使用路由标头跨其关联的区域边界传递非全局地址。例如,考虑链路边界节点(例如路由器)接收目的地为链路本地地址的分组,以及源地址为全局地址的情况。如果包包含下一地址为全局地址的路由报头,则全局地址的下一跳接口可能属于与原始目的地不同的链路。这是允许的,因为下一个地址的范围不小于原始目标的范围。
Note that as unicast site-local addresses are deprecated, and link-local addresses do not need routing, the discussion in this section only applies to multicast scoped routing.
请注意,由于单播站点本地地址已弃用,且链路本地地址不需要路由,因此本节中的讨论仅适用于多播范围的路由。
When a routing protocol determines that it is operating on a zone boundary, it MUST protect inter-zone integrity and maintain intra-zone connectivity.
当路由协议确定它在区域边界上运行时,它必须保护区域间的完整性并保持区域内的连接。
To maintain connectivity, the routing protocol must be able to create forwarding information for the global groups and for all the scoped groups for each of its attached zones. The most straightforward way of doing this is to create (conceptual) forwarding tables for each specific zone.
要保持连接,路由协议必须能够为全局组和其每个连接区域的所有作用域组创建转发信息。最直接的方法是为每个特定区域创建(概念上的)转发表。
To protect inter-zone integrity, routers must be selective in the group information shared with neighboring routers. Routers routinely exchange routing information with neighboring routers. When a router is transmitting this routing information, it must not include any information about zones other than the zones assigned to the interface used to transmit the information.
为了保护区域间的完整性,路由器必须在与相邻路由器共享的组信息中具有选择性。路由器通常与相邻路由器交换路由信息。当路由器传输此路由信息时,除分配给用于传输信息的接口的区域外,不得包含任何关于区域的信息。
* * * * * =========== Organization X * * | | * * | | * +-*----|-------|------+ * | * intf1 intf2 | * | * | * | * intf3 --- * | * | * | *********************************** | | | Router | | | ********************** ********************** | * * | Org. Y --- intf4 * * intf5 --- Org. Z | * * | ********************** ********************** +---------------------+
* * * * * =========== Organization X * * | | * * | | * +-*----|-------|------+ * | * intf1 intf2 | * | * | * | * intf3 --- * | * | * | *********************************** | | | Router | | | ********************** ********************** | * * | Org. Y --- intf4 * * intf5 --- Org. Z | * * | ********************** ********************** +---------------------+
Figure 4: Multi-Organization Multicast Router
图4:多组织多播路由器
As an example, the router in Figure 4 must exchange routing information on five interfaces. The information exchanged is as follows (for simplicity, multicast scopes smaller or larger than the organization scope except global are not considered here):
例如,图4中的路由器必须在五个接口上交换路由信息。交换的信息如下(为简单起见,此处不考虑比组织范围小或大的多播范围(全局范围除外):
o Interface 1 * All global groups * All organization groups learned from Interfaces 1, 2, and 3
o 界面1*所有全局组*从界面1、2和3学习的所有组织组
o Interface 2 * All global groups * All organization groups learned from Interfaces 1, 2, and 3
o 界面2*所有全局组*从界面1、2和3学习的所有组织组
o Interface 3 * All global groups * All organization groups learned from Interfaces 1, 2, and 3
o 接口3*所有全局组*从接口1、2和3学习的所有组织组
o Interface 4 * All global groups * All organization groups learned from Interface 4
o 界面4*所有全局组*从界面4学习的所有组织组
o Interface 5 * All global groups * All organization groups learned from Interface 5
o 界面5*所有全局组*从界面5学习的所有组织组
By imposing route exchange rules, zone integrity is maintained by keeping all zone-specific routing information contained within the zone.
通过强制实施路由交换规则,可以通过将所有特定于区域的路由信息保留在区域内来维护区域完整性。
As already mentioned, to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well. As a common notation to specify the scope zone, an implementation SHOULD support the following format:
如前所述,要在没有歧义的情况下指定IPv6非全局地址,还应指定预期的作用域。作为指定作用域区域的常用符号,实现应支持以下格式:
<address>%<zone_id>
<address>%<zone_id>
where
哪里
<address> is a literal IPv6 address,
<address>是一个文本IPv6地址,
<zone_id> is a string identifying the zone of the address, and
<zone_id>是标识地址区域的字符串,并且
`%' is a delimiter character to distinguish between <address> and <zone_id>.
`%'是分隔符,用于区分<address>和<zone\u id>。
The following subsections describe detailed definitions, concrete examples, and additional notes of the format.
以下小节描述了格式的详细定义、具体示例和附加注释。
The format applies to all kinds of unicast and multicast addresses of non-global scope except the unspecified address, which does not have a scope. The format is meaningless and should not be used for global addresses. The loopback address belongs to the trivial link; i.e., the link attached to the loopback interface. Thus the format should not be used for the loopback address, either. This document does not specify the usage of the format when the <address> is the unspecified address, as the address does not have a scope. This document, however, does not prohibit an implementation from using the format for those special addresses for implementation dependent purposes.
该格式适用于非全局作用域的所有类型的单播和多播地址,但未指定的地址没有作用域。该格式没有意义,不应用于全局地址。环回地址属于普通链路;i、 例如,连接到环回接口的链接。因此,该格式也不应用于环回地址。当<address>是未指定的地址时,本文档不指定格式的用法,因为该地址没有作用域。但是,本文件并不禁止实现将这些特殊地址的格式用于依赖于实现的目的。
In the textual representation, the <zone_id> part should be able to identify a particular zone of the address's scope. Although a zone index is expected to contain enough information to determine the scope and to be unique among all scopes as described in Section 6, the <zone_id> part of this format does not have to contain the scope. This is because the <address> part should specify the appropriate scope. This also means that the <zone_id> part does not have to be unique among all scopes.
在文本表示中,<zone\u id>部分应该能够识别地址范围的特定区域。尽管区域索引应包含足够的信息,以确定范围,并且在第6节所述的所有范围中是唯一的,但此格式的<zone_id>部分不必包含范围。这是因为<address>部分应该指定适当的范围。这也意味着<zone_id>部分不必在所有作用域中都是唯一的。
With this loosened property, an implementation can use a convenient representation as <zone_id>. For example, to represent link index 2, the implementation can simply use "2" as <zone_id>, which would be more readable than other representations that contain the "link" scope.
有了这个松散的属性,一个实现可以使用一个方便的表示形式<zone\u id>。例如,为了表示链接索引2,实现可以简单地使用“2”作为<zone\u id>,这将比包含“link”范围的其他表示更可读。
When an implementation interprets the format, it should construct the "full" zone index, which contains the scope, from the <zone_id> part and the scope specified by the <address> part. (Remember that a zone index itself should contain the scope, as specified in Section 6.)
当实现解释格式时,它应该构造“完整”区域索引,其中包含<zone_id>部分和<address>部分指定的范围中的范围。(请记住,分区索引本身应包含范围,如第6节所述。)
An implementation SHOULD support at least numerical indices that are non-negative decimal integers as <zone_id>. The default zone index, which should typically be 0 (see Section 6), is included in the integers. When <zone_id> is the default, the delimiter characters "%" and <zone_id> can be omitted. Similarly, if a textual representation of an IPv6 address is given without a zone index, it should be interpreted as <address>%<default ID>, where <default ID> is the default zone index of the scope that <address> has.
实现应至少支持非负十进制整数的数值索引,如<zone\u id>。默认区域索引通常应为0(见第6节),包含在整数中。当<zone\u id>为默认值时,可以省略分隔符“%”和<zone\u id>。类似地,如果给出的IPv6地址的文本表示没有区域索引,则应将其解释为<address>%<default ID>,其中<default ID>是<address>具有的作用域的默认区域索引。
An implementation MAY support other kinds of non-null strings as <zone_id>. However, the strings must not conflict with the delimiter character. The precise format and semantics of additional strings is implementation dependent.
实现可以支持其他类型的非空字符串,如<zone\u id>。但是,字符串不得与分隔符字符冲突。附加字符串的精确格式和语义取决于实现。
One possible candidate for these strings would be interface names, as interfaces uniquely disambiguate any scopes. In particular, interface names can be used as "default identifiers" for interfaces and links, because by default there is a one-to-one mapping between interfaces and each of those scopes as described in Section 6.
这些字符串的一个可能候选对象是接口名,因为接口唯一地消除了任何作用域的歧义。特别是,接口名称可以用作接口和链接的“默认标识符”,因为默认情况下,接口与第6节中描述的每个作用域之间存在一对一的映射。
An implementation could also use interface names as <zone_id> for scopes larger than links, but there might be some confusion in this use. For example, when more than one interface belongs to the same (multicast) site, a user would be confused about which interface should be used. Also, a mapping function from an address to a name would encounter the same kind of problem when it prints an address with an interface name as a zone index. This document does not specify how these cases should be treated and leaves it implementation dependent.
对于大于链接的作用域,实现还可以使用接口名作为<zone_id>,但这种使用可能会有一些混淆。例如,当多个接口属于同一个(多播)站点时,用户可能会对应该使用哪个接口感到困惑。此外,从地址到名称的映射函数在打印以接口名称作为区域索引的地址时也会遇到同样的问题。本文档未指定应如何处理这些情况,并使其依赖于实现。
It cannot be assumed that indices are common across all nodes in a zone (see Section 6). Hence, the format MUST be used only within a node and MUST NOT be sent on the wire unless every node that interprets the format agrees on the semantics.
不能假设索引在区域中的所有节点上都是通用的(参见第6节)。因此,该格式必须仅在节点内使用,并且不得在线路上发送,除非解释该格式的每个节点在语义上一致。
The following addresses
下列地址
fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th organization of the node)
fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th organization of the node)
would be represented as follows:
将派代表如下:
fe80::1234%1 ff02::5678%5 ff08::9abc%10
fe80::1234%1 ff02::5678%5 ff08::9abc%10
(Here we assume a natural translation from a zone index to the <zone_id> part, where the Nth zone of any scope is translated into "N".)
(这里我们假设从区域索引到<zone_id>部分的自然转换,其中任何范围的第N个区域都转换为“N”。)
If we use interface names as <zone_id>, those addresses could also be represented as follows:
如果我们将接口名称用作<zone\u id>,那么这些地址也可以表示为:
fe80::1234%ne0 ff02::5678%pvc1.3 ff08::9abc%interface10
fe80::1234%ne0 ff02::5678%pvc1.3 ff08::9abc%interface10
where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs to the 5th link, and "interface10" belongs to the 10th organization.
其中,接口“ne0”属于第一链路,“pvc1.3”属于第五链路,“接口10”属于第十组织。
Applications that are supposed to be used in end hosts such as telnet, ftp, and ssh may not explicitly support the notion of address scope, especially of link-local addresses. However, an expert user (e.g., a network administrator) sometimes has to give even link-local addresses to such applications.
应该在终端主机(如telnet、ftp和ssh)中使用的应用程序可能不明确支持地址范围的概念,尤其是链路本地地址的概念。然而,专家用户(例如,网络管理员)有时甚至必须给出此类应用程序的链接本地地址。
Here is a concrete example. Consider a multi-linked router called "R1" that has at least two point-to-point interfaces (links). Each of the interfaces is connected to another router, "R2" and "R3", respectively. Also assume that the point-to-point interfaces have link-local addresses only.
这里有一个具体的例子。考虑一个称为“R1”的多链路路由器,它至少有两个点对点接口(链路)。每个接口分别连接到另一个路由器“R2”和“R3”。还假设点到点接口仅具有链路本地地址。
Now suppose that the routing system on R2 hangs up and has to be reinvoked. In this situation, we may not be able to use a global address of R2, because this is routing trouble and we cannot expect to have enough routes for global reachability to R2.
现在假设R2上的路由系统挂起,必须重新调用。在这种情况下,我们可能无法使用R2的全局地址,因为这是路由问题,我们不能期望有足够的路由实现R2的全局可达性。
Hence, we have to login R1 first and then try to login R2 by using link-local addresses. In this case, we have to give the link-local address of R2 to, for example, telnet. Here we assume the address is fe80::2.
因此,我们必须先登录R1,然后尝试使用链接本地地址登录R2。在这种情况下,我们必须给出R2的链接本地地址,例如telnet。这里我们假设地址是fe80::2。
Note that we cannot just type
请注意,我们不能只键入
% telnet fe80::2
%telnet fe80::2
here, since R1 has more than one link and hence the telnet command cannot detect which link it should try to use for connecting. Instead, we should type the link-local address with the link index as follows:
这里,由于R1有多个链路,因此telnet命令无法检测它应该尝试使用哪个链路进行连接。相反,我们应该使用链接索引键入链接本地地址,如下所示:
% telnet fe80::2%3
%telnet fe80::2%3
where "3" after the delimiter character `%' corresponds to the link index of the point-to-point link.
其中,分隔符“%”后的“3”对应于点到点链接的链接索引。
An extension to the recommended basic API defines how the format for non-global addresses should be treated in library functions that translate a nodename to an address, or vice versa [11].
推荐的基本API的扩展定义了如何在将节点名转换为地址的库函数中处理非全局地址的格式,反之亦然[11]。
The format defined in this document does not intend to invalidate the original format for non-global addresses; that is, the format without the zone index portion. As described in Section 6, in some common cases with the notion of the default zone index, there can be no ambiguity about scope zones. In such an environment, the implementation can omit the "%<zone_id>" part. As a result, it can act as though it did not support the extended format at all.
本文件中定义的格式无意使非全局地址的原始格式无效;即,不带区域索引部分的格式。如第6节所述,在默认区域索引概念的一些常见情况下,范围区域不可能有歧义。在这种环境中,实现可以省略“%<zone\u id>”部分。因此,它可以表现为根本不支持扩展格式。
There are other kinds of delimiter characters defined for IPv6 addresses. In this subsection, we describe how they should be combined with the format for non-global addresses.
还有为IPv6地址定义的其他类型的分隔符。在本小节中,我们将描述如何将它们与非全局地址的格式相结合。
The IPv6 addressing architecture [1] also defines the syntax of IPv6 prefixes. If the address portion of a prefix is non-global and its scope zone should be disambiguated, the address portion SHOULD be in the format. For example, a link-local prefix fe80::/64 on the second link can be represented as follows:
IPv6寻址体系结构[1]还定义了IPv6前缀的语法。如果前缀的地址部分是非全局的,并且应消除其作用域的歧义,则地址部分的格式应为。例如,第二条链路上的链路本地前缀fe80::/64可以表示为:
fe80::%2/64
fe80::%2/64
In this combination, it is important to place the zone index portion before the prefix length when we consider parsing the format by a name-to-address library function [11]. That is, we can first separate the address with the zone index from the prefix length, and just pass the former to the library function.
在这种组合中,重要的是将区域索引部分放在前缀长度之前,当我们考虑通过名称解析地址库函数的格式(11)。也就是说,我们可以首先将带有区域索引的地址与前缀长度分开,然后将前者传递给库函数。
The preferred format for literal IPv6 addresses in URLs is also defined [12]. When a user types the preferred format for an IPv6 non-global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format.
URL中文字IPv6地址的首选格式也已定义[12]。当用户为应明确指定区域的IPv6非全局地址键入首选格式时,用户可以将非全局地址的格式与首选格式结合使用。
However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the <zone_id> portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the <zone_id> portion of the address.
但是,键入的URL通常是通过网络发送的,如果应用程序在发送之前没有剥离<zone_id>部分,就会造成混乱。请注意,应用程序不需要关心它们正在使用哪种地址,更不用说解析或去掉地址的<zone_id>部分了。
Also, the format for non-global addresses might conflict with the URI syntax [13], since the syntax defines the delimiter character (`%') as the escape character. This conflict would require, for example, that the <zone_id> part for zone 1 with the delimiter be represented as '%251'. It also means that we could not simply copy a non-escaped format from other sources as input to the URI parser. Additionally, if the URI parser does not convert the escaped format before passing it to a name-to-address library, the conversion will fail. All these issues would decrease the benefit of the textual representation described in this section.
此外,非全局地址的格式可能与URI语法[13]冲突,因为该语法将分隔符(`%')定义为转义字符。例如,此冲突需要将带分隔符的分区1的<zone_id>部分表示为“%251”。这也意味着我们不能简单地从其他源复制非转义格式作为URI解析器的输入。此外,如果URI解析器在将转义格式传递到名称到地址库之前不转换转义格式,则转换将失败。所有这些问题都会降低本节中描述的文本表示的好处。
Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. In any case, it is recommended to use an FQDN instead of a literal IPv6 address in a URL, whenever an FQDN is available.
因此,本文档未指定如何将非全局地址的格式与文本IPv6地址的首选格式相结合。在任何情况下,只要FQDN可用,建议在URL中使用FQDN而不是文字IPv6地址。
A limited scope address without a zone index has security implications and cannot be used for some security contexts. For example, a link-local address cannot be used in a traffic selector of a security association established by Internet Key Exchange (IKE) when the IKE messages are carried over global addresses. Also, a link-local address without a zone index cannot be used in access control lists.
没有区域索引的有限作用域地址具有安全含义,不能用于某些安全上下文。例如,当IKE消息通过全局地址传送时,不能在由Internet密钥交换(IKE)建立的安全关联的流量选择器中使用链路本地地址。此外,没有区域索引的链路本地地址不能在访问控制列表中使用。
The routing section of this document specifies a set of guidelines whereby routers can prevent zone-specific information from leaking out of each zone. If, for example, multicast site boundary routers
本文档的路由部分指定了一组指导原则,路由器可以通过这些指导原则防止特定于区域的信息从每个区域泄漏出去。例如,如果多播站点边界路由器
allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised.
如果允许将站点路由信息转发到站点外部,则可能会损害站点的完整性。
Since the use of the textual representation of non-global addresses is restricted to use within a single node, it does not create a security vulnerability from outside the node. However, a malicious node might send a packet that contains a textual IPv6 non-global address with a zone index, intending to deceive the receiving node about the zone of the non-global address. Thus, an implementation should be careful when it receives packets that contain textual non-global addresses as data.
由于非全局地址的文本表示仅限于在单个节点内使用,因此不会从节点外部创建安全漏洞。但是,恶意节点可能会发送包含文本IPv6非全局地址和区域索引的数据包,意图就非全局地址的区域欺骗接收节点。因此,实现在接收包含文本非全局地址作为数据的数据包时应该小心。
This document is a combination of several separate efforts. Atsushi Onoe took a significant role in one of them and deeply contributed to the content of Section 11 as a co-author of a separate proposal.
本文件是几项单独工作的组合。小野Atsushi在其中一项提案中发挥了重要作用,并作为单独提案的合著者对第11条的内容作出了重大贡献。
Many members of the IPv6 working group provided useful comments and feedback on this document. In particular, Margaret Wasserman and Bob Hinden led the working group to make a consensus on IPv6 local addressing. Richard Draves proposed an additional rule to process Routing header containing scoped addresses. Dave Thaler and Francis Dupont gave valuable suggestions to define semantics of zone indices in terms of related API. Pekka Savola reviewed a version of the document very carefully and made detailed comments about serious problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy Gleeson reviewed and helped improve the document during the preparation for publication.
IPv6工作组的许多成员对此文件提供了有用的意见和反馈。特别是Margaret Wasserman和Bob Hinden领导的工作组就IPv6本地寻址达成了共识。Richard Draves提出了一个额外的规则来处理包含作用域地址的路由头。戴夫·泰勒(Dave Thaler)和弗朗西斯·杜邦(Francis Dupont)就根据相关API定义区域索引的语义提出了宝贵的建议。佩卡·萨沃拉非常仔细地审查了该文件的一个版本,并就严重问题提出了详细的意见。Steve Bellovin、Ted Hardie、Bert Wijnen和Timothy Gleeson在准备出版期间审查并帮助改进了该文件。
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[1] Hinden,R.和S.Deering,“互联网协议版本6(IPv6)寻址体系结构”,RFC 3513,2003年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[3] Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,RFC 2460,1998年12月。
[4] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[4] Conta,A.和S.Deering,“互联网协议版本6(IPv6)规范的互联网控制消息协议(ICMPv6)”,RFC 2463,1998年12月。
[5] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[5] Huitema,C.和B.Carpenter,“不推荐现场本地地址”,RFC 38792004年9月。
[6] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[6] Draves,R.,“因特网协议版本6(IPv6)的默认地址选择”,RFC 3484,2003年2月。
[7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of Link-Local IPv4 Addresses", Work in Progress.
[7] Cheshire,S.,Aboba,B.,和E.Guttman,“链路本地IPv4地址的动态配置”,正在进行中。
[8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[8] Conta,A.和S.Deering,“IPv6规范中的通用数据包隧道”,RFC 2473,1998年12月。
[9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] Narten,T.,Nordmark,E.,和W.Simpson,“IP版本6(IPv6)的邻居发现”,RFC24611998年12月。
[10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[10] Gilligan,R.,Thomson,S.,Bound,J.,McCann,J.,和W.Stevens,“IPv6的基本套接字接口扩展”,RFC 3493,2003年2月。
[11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic Socket API", Work in Progress, July 2002.
[11] Gilligan,R.,“IPv6基本套接字API的作用域地址扩展”,正在进行的工作,2002年7月。
[12] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[12] Hinden,R.,Carpenter,B.,和L.Masinter,“URL中文字IPv6地址的格式”,RFC 2732,1999年12月。
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005.
[13] Berners Lee,T.,Fielding,R.,和L.Masinter,“统一资源标识符(URI):通用语法”,RFC 3986,2005年1月。
Authors' Addresses
作者地址
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
Brian Haberman Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
布莱恩·哈伯曼·约翰·霍普金斯大学应用物理实验室美国马里兰州劳雷尔市约翰·霍普金斯路11100号20723-6099
Phone: +1-443-778-1319 EMail: brian@innovationslab.net
Phone: +1-443-778-1319 EMail: brian@innovationslab.net
Tatuya Jinmei Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Saiwai-ku Kawasaki-shi, Kanagawa 212-8582 Japan
Tatuya Jinmei公司研发中心,东芝公司1 Komukai Toshiba cho,日本神奈川市川崎市西围区212-8582
Phone: +81-44-549-2230 Fax: +81-44-520-1841 EMail: jinmei@isl.rdc.toshiba.co.jp
Phone: +81-44-549-2230 Fax: +81-44-520-1841 EMail: jinmei@isl.rdc.toshiba.co.jp
Erik Nordmark 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark 17美国加利福尼亚州门罗公园网络圈94025
Phone: +1 650 786 2921 Fax: +1 650 786 5896 EMail: Erik.Nordmark@sun.com
Phone: +1 650 786 2921 Fax: +1 650 786 5896 EMail: Erik.Nordmark@sun.com
Brian D. Zill Microsoft Research One Microsoft Way Redmond, WA 98052-6399 USA
Brian D.Zill Microsoft Research One Microsoft Way Redmond,WA 98052-6399美国
Phone: +1-425-703-3568 Fax: +1-425-936-7329 EMail: bzill@microsoft.com
Phone: +1-425-703-3568 Fax: +1-425-936-7329 EMail: bzill@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有(C)互联网协会(2005年)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。