Internet Engineering Task Force (IETF) B. Carpenter, Ed.
Request for Comments: 7421 Univ. of Auckland
Category: Informational T. Chown
ISSN: 2070-1721 Univ. of Southampton
F. Gont
SI6 Networks / UTN-FRH
S. Jiang
Huawei Technologies Co., Ltd
A. Petrescu
CEA, LIST
A. Yourtchenko
Cisco
January 2015
Internet Engineering Task Force (IETF) B. Carpenter, Ed.
Request for Comments: 7421 Univ. of Auckland
Category: Informational T. Chown
ISSN: 2070-1721 Univ. of Southampton
F. Gont
SI6 Networks / UTN-FRH
S. Jiang
Huawei Technologies Co., Ltd
A. Petrescu
CEA, LIST
A. Yourtchenko
Cisco
January 2015
Analysis of the 64-bit Boundary in IPv6 Addressing
IPv6寻址中64位边界的分析
Abstract
摘要
The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.
IPv6单播寻址格式包括用于将数据包路由到子网的前缀和用于指定连接到该子网的给定接口的接口标识符之间的分隔。目前，接口标识符几乎在每种情况下都定义为64位，留下64位作为子网前缀。本文件描述了该固定边界的优点，并分析了将其视为可变边界所涉及的问题。
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/rfc7421.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7421.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Advantages of a Fixed Identifier Length . . . . . . . . . . . 4
3. Arguments for Shorter Identifier Lengths . . . . . . . . . . 5
3.1. Insufficient Address Space Delegated . . . . . . . . . . 5
3.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 6
3.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 7
3.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 7
4. Effects of Varying the Interface Identifier Length . . . . . 8
4.1. Interaction with IPv6 Specifications . . . . . . . . . . 8
4.2. Possible Failure Modes . . . . . . . . . . . . . . . . . 10
4.3. Experimental Observations . . . . . . . . . . . . . . . . 12
4.3.1. Survey of the processing of Neighbor Discovery
Options with Prefixes Other than /64 . . . . . . . . 12
4.3.2. Other Observations . . . . . . . . . . . . . . . . . 14
4.4. Implementation and Deployment Issues . . . . . . . . . . 14
4.5. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Advantages of a Fixed Identifier Length . . . . . . . . . . . 4
3. Arguments for Shorter Identifier Lengths . . . . . . . . . . 5
3.1. Insufficient Address Space Delegated . . . . . . . . . . 5
3.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 6
3.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 7
3.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 7
4. Effects of Varying the Interface Identifier Length . . . . . 8
4.1. Interaction with IPv6 Specifications . . . . . . . . . . 8
4.2. Possible Failure Modes . . . . . . . . . . . . . . . . . 10
4.3. Experimental Observations . . . . . . . . . . . . . . . . 12
4.3.1. Survey of the processing of Neighbor Discovery
Options with Prefixes Other than /64 . . . . . . . . 12
4.3.2. Other Observations . . . . . . . . . . . . . . . . . 14
4.4. Implementation and Deployment Issues . . . . . . . . . . 14
4.5. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Rather than simply overcoming the IPv4 address shortage by doubling the address size to 64 bits, IPv6 addresses were originally chosen to be 128 bits long to provide flexibility and new possibilities. In particular, the notion of a well-defined interface identifier was added to the IP addressing model. The IPv6 addressing architecture [RFC4291] specifies that a unicast address is divided into n bits of subnet prefix followed by (128-n) bits of interface identifier (IID). The bits in the IID may have significance only in the process of deriving the IID; once it is derived, the entire identifier should be treated as an opaque value [RFC7136]. Also, since IPv6 routing is entirely based on variable length prefixes (also known as variable length subnet masks), there is no basic architectural assumption that n has any particular fixed value. All IPv6 routing protocols support prefixes of any length up to /128.
IPv6地址最初被选择为128位，以提供灵活性和新的可能性，而不是简单地通过将地址大小加倍到64位来克服IPv4地址短缺。特别是，在IP寻址模型中添加了定义良好的接口标识符的概念。IPv6寻址体系结构[RFC4291]规定，单播地址分为n位子网前缀，后跟（128-n）位接口标识符（IID）。IID中的位可能仅在推导IID的过程中才有意义；一旦它被导出，整个标识符应被视为不透明值[RFC7136]。此外，由于IPv6路由完全基于可变长度前缀（也称为可变长度子网掩码），因此没有基本的体系结构假设n具有任何特定的固定值。所有IPv6路由协议都支持长度不超过/128的前缀。
The IID is of basic importance in the IPv6 stateless address autoconfiguration (SLAAC) process [RFC4862]. However, it is important to understand that its length is a parameter in the SLAAC process, and it is determined in a separate link-type specific document (see the definition of "interface identifier" in Section 2 of RFC 4862). The SLAAC protocol does not define its length or assume any particular length. Similarly, DHCPv6 [RFC3315] does not include a prefix length in its address assignment.
IID在IPv6无状态地址自动配置（SLAAC）过程中至关重要[RFC4862]。但是，重要的是要了解其长度是SLAAC过程中的一个参数，并在单独的链路类型特定文档中确定（请参阅RFC 4862第2节中“接口标识符”的定义）。SLAAC协议未定义其长度或假定任何特定长度。类似地，DHCPv6[RFC3315]在其地址分配中不包括前缀长度。
The notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80. There were two motivations for setting it at /64. One was the original "8+8" proposal [ODELL] that eventually led to the Identifier-Locator Network Protocol (ILNP) [RFC6741], which required a fixed point for the split between local and wide-area parts of the address. The other was the expectation that 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) addresses would become widespread in place of 48-bit addresses, coupled with the plan at that time that auto-configured addresses would normally be based on interface identifiers derived from MAC addresses.
地址中a/64边界的概念是在IPv6的初始设计之后引入的，这段时间预计为a/80。将其设置为/64有两个动机。一个是最初的“8+8”方案[ODELL]，最终导致了标识符定位器网络协议（ILNP）[RFC6741]，该协议要求在地址的本地和广域部分之间划分一个固定点。另一个是期望64位扩展唯一标识符（EUI-64）媒体访问控制（MAC）地址将取代48位地址变得广泛，再加上当时的计划，即自动配置的地址通常基于从MAC地址派生的接口标识符。
As a result, RFC 4291 describes a method of forming interface identifiers from IEEE EUI-64 hardware addresses [IEEE802], and this specifies that such interface identifiers are 64 bits long. Various other methods of forming interface identifiers also specify a length of 64 bits. The addressing architecture, as modified by [RFC7136], states that:
因此，RFC 4291描述了从IEEE EUI-64硬件地址[IEEE802]形成接口标识符的方法，并且这指定了这样的接口标识符为64位长。形成接口标识符的各种其他方法也指定64位的长度。[RFC7136]修改的寻址体系结构规定：
For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.
对于所有单播地址（以二进制值000开头的地址除外），接口ID的长度要求为64位。如果从IEEE MAC层地址派生，则必须以修改后的EUI-64格式构造。
The de facto length of almost all IPv6 interface identifiers is therefore 64 bits. The only documented exception is in [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers, among other things, to avoid a loop condition known as the ping-pong problem.
因此，几乎所有IPv6接口标识符的实际长度都是64位。唯一记录在案的例外是[RFC6164]，它标准化了路由器之间点到点链路的127位前缀，以避免称为乒乓问题的循环情况。
With that exception, and despite the comments above about the routing architecture and the design of SLAAC, using an IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications, so results may vary.
除此之外，尽管上面对SLAAC的路由架构和设计进行了评论，但使用小于64位的IID和大于64位的子网前缀超出了当前的IPv6规范，因此结果可能会有所不同。
The question is often asked why the subnet prefix boundary is set rigidly at /64. The first purpose of this document is to explain the advantages of the fixed IID length. Its second purpose is to analyze, in some detail, the effects of hypothetically varying the IID length. The fixed-length limits the practical length of a routing prefix to 64 bits, whereas architecturally, and from the point of view of routing protocols, it could be any value up to /128, as in the case of host routes. Whatever the length of the IID, the longest match is done on the concatenation of prefix and IID. Here, we mainly discuss the question of a shorter IID, which would allow a longer subnet prefix. The document makes no proposal for a change to the IID length.
经常有人问，为什么子网前缀边界严格设置为/64。本文件的第一个目的是解释固定IID长度的优点。第二个目的是详细分析假设改变IID长度的影响。固定长度将路由前缀的实际长度限制为64位，而从体系结构和路由协议的角度来看，它可以是不超过/128的任何值，就像主机路由一样。无论IID的长度如何，最长的匹配都是在前缀和IID的串联上完成的。这里，我们主要讨论一个较短的IID问题，这将允许较长的子网前缀。该文件没有提出改变IID长度的建议。
The following three sections describe, in turn, the advantages of the fixed-length IID, some arguments for shorter lengths, and the expected effects of varying the length.
以下三节依次介绍了固定长度IID的优点、较短长度的一些参数以及改变长度的预期效果。
As mentioned in Section 1, the existence of an IID of a given length is a necessary part of IPv6 stateless address autoconfiguration (SLAAC) [RFC4862]. This length is normally the same for all nodes on a given link that is running SLAAC. Even though this length is a parameter for SLAAC, determined separately for the link-layer media type of each interface, a globally fixed IID length for all link-layer media is the simplest solution and is consistent with the principles of Internet host configuration described in [RFC5505].
如第1节所述，给定长度的IID的存在是IPv6无状态地址自动配置（SLAAC）的必要部分[RFC4862]。对于运行SLAAC的给定链路上的所有节点，此长度通常相同。尽管该长度是SLAAC的一个参数，为每个接口的链路层介质类型单独确定，但所有链路层介质的全局固定IID长度是最简单的解决方案，并且与[RFC5505]中描述的互联网主机配置原则一致。
An interface identifier of significant length, clearly separated from the subnet prefix, makes it possible to limit the traceability of a host computer by varying the identifier. This is discussed further in Section 4.5.
有效长度的接口标识符（与子网前缀明确分开）可以通过改变标识符来限制主机的可跟踪性。这将在第4.5节中进一步讨论。
An interface identifier of significant length guarantees that there are always enough addresses in any subnet to add one or more real or virtual interfaces. There might be other limits, but IP addressing will never get in the way.
有效长度的接口标识符保证任何子网中始终有足够的地址来添加一个或多个实接口或虚拟接口。可能还有其他限制，但IP地址永远不会成为障碍。
The addressing architecture [RFC4291] [RFC7136] sets the IID length at 64 bits for all unicast addresses and therefore for all media supporting SLAAC. An immediate effect of fixing the IID length at 64 bits is, of course, that it fixes the subnet prefix length also at 64 bits, regardless of the aggregate prefix assigned to the site concerned, which in accordance with [RFC6177] should be /56 or shorter. This situation has various specific advantages:
寻址体系结构[RFC4291][RFC7136]将所有单播地址的IID长度设置为64位，因此也将所有支持SLAAC的媒体的IID长度设置为64位。当然，将IID长度固定在64位的直接效果是，它将子网前缀长度也固定在64位，而不管分配给相关站点的聚合前缀是多少，根据[RFC6177]，聚合前缀应为/56或更短。这种情况有各种特殊优势：
o Everything is the same. Compared to IPv4, there is no more calculating leaf subnet sizes, no more juggling between subnets, and fewer consequent errors. Network design is therefore simpler and much more straightforward. This is of importance for all types of networks -- enterprise, campus, small office, or home networks -- and for all types of operator, from professional to consumer.
o 一切都一样。与IPv4相比，无需更多地计算叶子网大小，无需更多地在子网之间进行杂耍，以及更少的后续错误。因此，网络设计更简单、更直观。这对于所有类型的网络——企业、校园、小型办公室或家庭网络——以及从专业到消费者的所有类型的运营商都很重要。
o Adding a subnet is easy -- just take another /64 from the pool. No estimates, calculations, consideration, or judgement is needed.
o 添加子网很简单——只需从池中再添加一个/64即可。不需要估计、计算、考虑或判断。
o Router configurations are homogeneous and easier to understand.
o 路由器配置是同质的，更容易理解。
o Documentation is easier to write and easier to read; training is easier.
o 文档更易于编写和阅读；训练更容易。
The remainder of this document describes arguments that have been made against the current fixed IID length and analyzes the effects of a possible change. However, the consensus of the IETF is that the benefits of keeping the length fixed at 64 bits and the practical difficulties of changing it outweigh the arguments for change.
本文档的其余部分描述了针对当前固定IID长度所做的论证，并分析了可能更改的影响。然而，IETF的共识是，将长度固定在64位的好处和更改它的实际困难超过了更改的理由。
In this section, we describe arguments for scenarios where shorter IIDs, implying prefixes longer than /64, have been used or proposed.
在本节中，我们将介绍使用或建议使用较短IID（表示前缀长于/64）的场景的参数。
A site may not be delegated a sufficiently generous prefix from which to allocate a /64 prefix to all of its internal subnets. In this case, the site may either determine that it does not have enough address space to number all its network elements and thus, at the very best, be only partially operational, or it may choose to use
一个站点可能没有被授予一个足够慷慨的前缀，从中可以向其所有内部子网分配/64前缀。在这种情况下，站点可以确定其没有足够的地址空间来对其所有网元进行编号，因此，在最好的情况下，只能部分运行，也可以选择使用
internal prefixes longer than /64 to allow multiple subnets and the hosts within them to be configured with addresses.
长度大于/64的内部前缀，允许使用地址配置多个子网及其内的主机。
In this case, the site might choose, for example, to use a /80 per subnet in combination with hosts using either manually configured addressing or DHCPv6 [RFC3315].
在这种情况下，站点可能会选择（例如）将每个子网的a/80与使用手动配置寻址或DHCPv6[RFC3315]的主机结合使用。
Scenarios that have been suggested where an insufficient prefix might be delegated include home or small office networks, vehicles, building services, and transportation services (e.g., road signs). It should be noted that the homenet architecture text [RFC7368] states that Customer Premises Equipment (CPE) should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally.
建议的前缀不足的场景包括家庭或小型办公室网络、车辆、建筑服务和交通服务（例如，路标）。应该注意的是，HONENET体系结构文本[RCF7368]指出，客户驻地设备（CPE）应该考虑到缺少足够的地址空间是一个错误条件，而不是使用比内部长/ 64长的前缀。
Another scenario occasionally suggested is one where the Internet address registries actually begin to run out of IPv6 prefix space, such that operators can no longer assign reasonable prefixes to users in accordance with [RFC6177]. It is sometimes suggested that assigning a prefix such as /48 or /56 to every user site (including the smallest) as recommended by [RFC6177] is wasteful. In fact, the currently released unicast address space, 2000::/3, contains 35 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a small fraction have been allocated. Allowing for a conservative estimate of allocation efficiency, i.e., an HD-ratio of 0.94 [RFC4692], approximately 5 trillion /48 prefixes can be allocated. Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 prefixes can be allocated. Furthermore, with only 2000::/3 currently committed for unicast addressing, we still have approximately 85% of the address space in reserve. Thus, there is no objective risk of prefix depletion by assigning /48 or /56 prefixes even to the smallest sites.
偶尔提出的另一种情况是，互联网地址注册中心实际上开始耗尽IPv6前缀空间，因此运营商无法再根据[RFC6177]为用户分配合理的前缀。有时有人建议，按照[RFC6177]的建议，为每个用户站点（包括最小的）分配一个前缀，如/48或/56，这是浪费。事实上，当前发布的单播地址空间2000:：/3包含35万亿/48个前缀（（2**45=35184372088832），其中只有一小部分已分配。允许保守估计分配效率，即HD比率为0.94[RFC4692]，可以分配大约5万亿/48个前缀。即使放宽HD比率为0.89，也可以分配大约1万亿/48个前缀。此外，目前只有2000:：/3用于单播寻址，我们仍保留大约85%的地址空间。因此，不存在前缀耗尽的客观风险y将/48或/56前缀分配给最小的站点。
Some operators have argued that more prefix bits are needed to allow an aggregated hierarchical addressing scheme within a campus or corporate network. However, if a campus or enterprise gets a /48 prefix (or shorter), then that already provides 16 bits for hierarchical allocation. In any case, flat IGP routing is widely and successfully used within rather large networks, with hundreds of routers and thousands of end systems. Therefore, there is no objective need for additional prefix bits to support hierarchy and aggregation within enterprises.
一些运营商认为，需要更多的前缀位，才能在校园或公司网络中实现聚合层次寻址方案。但是，如果校园或企业获得/48前缀（或更短），那么它已经为分层分配提供了16位。在任何情况下，平面IGP路由都在相当大的网络中得到了广泛和成功的应用，有数百个路由器和数千个终端系统。因此，客观上不需要额外的前缀位来支持企业内的层次结构和聚合。
Some network operators wish to know and audit nodes that are active on a network, especially those that are allowed to communicate off-link or off-site. They may also wish to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN, or site, in order to prevent potential resource-depletion attacks or other problems spreading beyond a certain scope of control. It has been argued that this type of control would be easier if only long network prefixes with relatively small numbers of possible hosts per network were used, reducing the discovery problem. However, such sites most typically operate using DHCPv6, which means that all legitimate hosts are automatically known to the DHCPv6 servers, which is sufficient for audit purposes. Such hosts could, if desired, be limited to a small range of IID values without changing the /64 subnet length. Any hosts inadvertently obtaining addresses via SLAAC can be audited through Neighbor Discovery (ND) logs.
一些网络运营商希望了解和审核网络上活动的节点，特别是允许在非链接或非现场通信的节点。他们还可能希望限制可从特定主机、LAN或站点获取的活动地址和会话的总数，以防止潜在的资源消耗攻击或其他问题超出一定的控制范围。有人认为，如果只使用长的网络前缀和每个网络可能的主机数量相对较少的话，这种类型的控制将更容易，从而减少发现问题。但是，此类站点通常使用DHCPv6运行，这意味着DHCPv6服务器自动知道所有合法主机，这就足以用于审计目的。如果需要，这样的主机可以被限制在IID值的小范围内，而不改变/64子网长度。任何无意中通过SLAAC获取地址的主机都可以通过邻居发现（ND）日志进行审核。
A site may be concerned that it is open to ND cache exhaustion attacks [RFC3756], whereby an attacker sends a large number of messages in rapid succession to a series of (most likely inactive) host addresses within a specific subnet. Such an attack attempts to fill a router's ND cache with ND requests pending completion, which results in denying correct operation to active devices on the network.
站点可能会担心它会受到ND缓存耗尽攻击[RFC3756]，从而攻击者会将大量消息快速连续发送到特定子网内的一系列（很可能是非活动的）主机地址。这种攻击试图用等待完成的ND请求填充路由器的ND缓存，从而导致拒绝网络上活动设备的正确操作。
One potential way to mitigate this attack would be to consider using a /120 prefix, thus limiting the number of addresses in the subnet to be similar to an IPv4 /24 prefix, which should not cause any concerns for ND cache exhaustion. Note that the prefix does need to be quite long for this scenario to be valid. The number of theoretically possible ND cache slots on the segment needs to be of the same order of magnitude as the actual number of hosts. Thus, small increases from the /64 prefix length do not have a noticeable impact; even 2^32 potential entries, a factor of two billion decrease compared to 2^64, is still more than enough to exhaust the memory on current routers. Given that most link-layer mappings cause SLAAC to assume a 64-bit network boundary, in such an approach hosts would likely need to use DHCPv6 or be manually configured with addresses.
减轻这种攻击的一种可能的方法是考虑使用A/120前缀，从而限制子网中的地址数目类似于IPv4／24前缀，这不应该引起ND缓存耗尽的任何顾虑。请注意，前缀确实需要相当长才能使此场景有效。段上理论上可能的ND缓存插槽数量需要与主机的实际数量具有相同的数量级。因此，从/64前缀长度的微小增加不会产生明显的影响；即使是2^32个潜在条目，与2^64相比减少了20亿倍，仍然足以耗尽当前路由器上的内存。鉴于大多数链路层映射导致SLAAC采用64位网络边界，在这种方法中，主机可能需要使用DHCPv6或手动配置地址。
It should be noted that several other mitigations of the ND cache attack are described in [RFC6583], and that limiting the size of the cache and the number of incomplete entries allowed would also defeat the attack. For the specific case of a point-to-point link between routers, this attack is indeed mitigated by a /127 prefix [RFC6164].
应该注意的是，ND缓存攻击的其他几种缓解措施在[RFC6583]中进行了描述，限制缓存的大小和允许的不完整条目的数量也会挫败该攻击。对于路由器之间的点到点链路的特定情况，此攻击确实通过/127前缀[RFC6164]得以缓解。
This section of the document analyzes the impact and effects of varying the length of an IPv6 unicast IID by reducing it to less than 64 bits.
本节将分析通过将IPv6单播IID的长度减少到64位以下而改变其长度的影响。
The precise 64-bit length of the IID is widely mentioned in numerous RFCs describing various aspects of IPv6. It is not straightforward to distinguish cases where this has normative impact or affects interoperability. This section aims to identify specifications that contain an explicit reference to the 64-bit length. Regardless of implementation issues, the RFCs themselves would all need to be updated if the 64-bit rule was changed, even if the updates were small, which would involve considerable time and effort.
IID的精确64位长度在描述IPv6各个方面的众多RFC中被广泛提及。区分这会对规范产生影响或影响互操作性的情况并不容易。本节旨在确定包含对64位长度的明确引用的规范。无论实现问题如何，如果64位规则发生更改，RFC本身都需要更新，即使更新很小，这将需要花费大量的时间和精力。
First and foremost, the RFCs describing the architectural aspects of IPv6 addressing explicitly state, refer, and repeat this apparently immutable value: Addressing Architecture [RFC4291], IPv6 Address Assignment to End Sites [RFC6177], Reserved IIDs [RFC5453], and ILNP Node Identifiers [RFC6741]. Customer edge routers impose /64 for their interfaces [RFC7084]. The IPv6 Subnet Model [RFC5942] points out that the assumption of a /64 prefix length is a potential implementation error.
首先也是最重要的是，描述IPv6寻址的体系结构方面的RFC明确地声明、引用并重复这个显然不可变的值：寻址体系结构[RFC4291]、到终端站点的IPv6地址分配[RFC6177]、保留IID[RFC5453]和ILNP节点标识符[RFC6741]。客户边缘路由器为其接口设置/64[RFC7084]。IPv6子网模型[RFC5942]指出，假定a/64前缀长度是一个潜在的实现错误。
Numerous IPv6-over-foo documents make mandatory statements with
respect to the 64-bit length of the IID to be used during the
Stateless Autoconfiguration. These documents include [RFC2464]
(Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)),
[RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet),
[RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre
Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121]
[RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS]
(Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE]
(BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and
[IPv6-G9959] (IPv6 packets over ITU-T G.9959).
Numerous IPv6-over-foo documents make mandatory statements with
respect to the 64-bit length of the IID to be used during the
Stateless Autoconfiguration. These documents include [RFC2464]
(Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)),
[RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet),
[RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre
Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121]
[RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS]
(Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE]
(BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and
[IPv6-G9959] (IPv6 packets over ITU-T G.9959).
To a lesser extent, the address configuration RFCs themselves may in some ways assume the 64-bit length of an IID (e.g, RFC 4862 for the link-local addresses, DHCPv6 for the potentially assigned EUI-64-based IP addresses, and Optimistic Duplicate Address Detection [RFC4429] that computes 64-bit-based collision probabilities).
在较小程度上，地址配置RFC本身可以以某些方式假定IID的64位长度（例如，RFC 4862用于链路本地地址，DHCPv6用于潜在分配的基于EUI-64的IP地址，以及计算基于64位的冲突概率的乐观重复地址检测[RFC4429]）。
The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and MLDv2 [RFC3810] protocols mandate that all queries be sent with a link-local source address, with the exception of MLD messages sent
多播侦听器发现版本1（MLDv1）[RFC2710]和MLDv2[RFC3810]协议要求所有查询都使用链路本地源地址发送，但发送的MLD消息除外
using the unspecified address when the link-local address is tentative [RFC3590]. At the time of publication of RFC 2710, the IPv6 addressing architecture specified link-local addresses with 64-bit interface identifiers. MLDv2 explicitly specifies the use of the fe80::/64 link-local prefix and bases the querier election algorithm on the link-local subnet prefix of length /64.
当链路本地地址为暂定地址时，使用未指定的地址[RFC3590]。在发布RFC 2710时，IPv6寻址体系结构使用64位接口标识符指定了链路本地地址。MLDv2明确指定fe80:：/64链路本地前缀的使用，并将查询器选择算法基于长度为/64的链路本地子网前缀。
The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 20-bit hash function generation, which relies on splitting an IPv6 address in two equally sized, 64-bit-length parts.
“IPv6流标签规范”[RFC6437]给出了一个生成20位哈希函数的示例，该函数依赖于将IPv6地址拆分为两个大小相等的64位长度部分。
The basic transition mechanisms [RFC4213] refer to IIDs of length 64 for link-local addresses; other transition mechanisms such as Teredo [RFC4380] assume the use of IIDs of length 64. Similar assumptions are found in 6to4 [RFC3056] and 6rd [RFC5969]. Translation-based transition mechanisms such as NAT64 and NPTv6 have some dependency on prefix length, discussed below.
基本转换机制[RFC4213]指长度为64的IID，用于链路本地地址；其他转换机制，如Teredo[RFC4380]假设使用长度为64的IID。类似的假设见6to4[RFC3056]和6rd[RFC5969]。基于翻译的转换机制（如NAT64和NPTv6）对前缀长度有一定的依赖性，如下所述。
The proposed method [RFC7278] of extending an assigned /64 prefix from a smartphone's cellular interface to its WiFi link relies on prefix length, and implicitly on the length of the IID, to be valued at 64.
将分配的/64前缀从智能手机的蜂窝接口扩展到其WiFi链路的拟议方法[RFC7278]依赖于前缀长度，并且隐含地依赖于IID的长度，其值为64。
The Cryptographically Generated Addresses (CGA) and Hash-Based Addresses (HBA) specifications rely on the 64-bit identifier length (see below), as do the Privacy extensions [RFC4941] and some examples in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296].
加密生成的地址（CGA）和基于哈希的地址（HBA）规范依赖于64位标识符长度（见下文），隐私扩展[RFC4941]和“Internet密钥交换版本2（IKEv2）”[RFC7296]中的一些示例也是如此。
464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. However, it also discusses the possibility of using the interface address on the device as the end point for the traffic, thus potentially removing this dependency.
464XLAT[RFC6877]明确提到获取/64个前缀。但是，它还讨论了使用设备上的接口地址作为流量端点的可能性，从而可能消除这种依赖性。
[RFC2526] reserves a number of subnet anycast addresses by reserving some anycast IIDs. An anycast IID so reserved cannot be less than 7 bits long. This means that a subnet prefix length longer than /121 is not possible, and a subnet of exactly /121 would be useless since all its identifiers are reserved. It also means that half of a /120 is reserved for anycast. This could of course be fixed in the way described for /127 in [RFC6164], i.e., avoiding the use of anycast within a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 neighbor discovery capability [RFC4861] [RFC7094]; therefore, applications and their developers would expect it to be available.
[RFC2526]通过保留一些选播IID来保留多个子网选播地址。如此保留的选播IID的长度不能小于7位。这意味着子网前缀长度不可能超过/121，而恰好为/121的子网将是无用的，因为它的所有标识符都是保留的。这也意味着a/120的一半保留给选播。这当然可以用[RFC6164]中描述的/127的方式来修复，即避免在/120子网中使用选播。请注意，对“链路选播”的支持是一种标准的IPv6邻居发现功能[RFC4861][RFC7094]；因此，应用程序及其开发人员都希望它可用。
The Mobile IP home network models [RFC4887] rely heavily on the /64 subnet length and assume a 64-bit IID.
移动IP家庭网络模型[RFC4887]严重依赖/64子网长度，并采用64位IID。
While preparing this document, it was noted that many other IPv6 specifications refer to mandatory alignment on 64-bit boundaries, 64-bit data structures, 64-bit counters in MIBs, 64-bit sequence numbers and cookies in security, etc. Finally, the number "64" may be considered "magic" in some RFCs, e.g., 64k limits in DNS and Base64 encodings in MIME. None of this has any influence on the length of the IID but might confuse a careless reader.
在编写本文档时，注意到许多其他IPv6规范涉及64位边界、64位数据结构、MIB中的64位计数器、安全中的64位序列号和cookie等的强制对齐。最后，数字“64”在某些RFC中可能被视为“魔法”，例如。，DNS中的64k限制和MIME中的Base64编码。这些都不会影响IID的长度，但可能会让粗心的读者感到困惑。
This section discusses several specific aspects of IPv6 where we can expect operational failures with subnet prefixes other than /64.
本节讨论IPv6的几个特定方面，在这些方面，我们可以预期使用子网前缀而不是/64的操作失败。
o Router implementations: Router implementors might interpret IETF specifications such as [RFC6164] and [RFC7136] as indicating that prefixes between /65 and /126 (inclusive) for unicast packets on-the-wire are invalid and that operational practices that utilize prefix lengths in this range may fail on some devices, as discussed in Section 4.3.2.
o 路由器实现：路由器实现者可能会将[RFC6164]和[RFC7136]等IETF规范解释为表明线路上单播数据包的/65和/126（含）之间的前缀无效，并且使用此范围前缀长度的操作实践可能会在某些设备上失败，如第4.3.2节所述。
o Multicast: [RFC3306] defines a method for generating IPv6 multicast group addresses based on unicast prefixes. This method assumes a longest prefix of 64 bits. If a longer prefix is used, there is no way to generate a specific multicast group address using this method. In such cases, the administrator would need to use an "artificial" prefix from within their allocation (a /64 or shorter) from which to generate the group address. This prefix would not correspond to a real subnet.
o 多播：[RFC3306]定义了一种基于单播前缀生成IPv6多播组地址的方法。此方法假定最长前缀为64位。如果使用更长的前缀，则无法使用此方法生成特定的多播组地址。在这种情况下，管理员需要在其分配（a/64或更短）中使用“人工”前缀来生成组地址。此前缀与实际子网不对应。
Similarly, [RFC3956], which specifies the Embedded Rendezvous Point (RP)) allowing IPv6 multicast rendezvous point addresses to be embedded in the multicast group address, would also fail, as the scheme assumes a maximum prefix length of 64 bits.
类似地，[RFC3956]指定了嵌入的集合点（RP）），允许IPv6多播集合点地址嵌入到多播组地址中，也会失败，因为该方案假定最大前缀长度为64位。
o CGA: The Cryptographically Generated Address format [RFC3972] is heavily based on a /64 interface identifier. [RFC3972] has defined a detailed algorithm showing how to generate a 64-bit interface identifier from a public key and a 64-bit subnet prefix. Changing the /64 boundary would certainly invalidate the current CGA definition. However, the CGA might benefit in a redefined version if more bits are used for interface identifiers (which means shorter prefix length). For now, 59 bits are used for cryptographic purposes. The more bits are available, the stronger CGA could be. Conversely, longer prefixes would weaken CGA.
o CGA：加密生成的地址格式[RFC3972]主要基于a/64接口标识符。[RFC3972]定义了一个详细的算法，说明如何从公钥和64位子网前缀生成64位接口标识符。更改/64边界肯定会使当前CGA定义无效。但是，如果接口标识符使用更多的位（这意味着前缀长度更短），则CGA在重新定义的版本中可能会受益。目前，59位用于加密目的。可用位越多，CGA越强。相反，较长的前缀会削弱CGA。
o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] are flexible for the prefix length. [RFC6052] has defined multiple address formats for NAT64. In Section 2 of
o NAT64：无状态NAT64[RFC6052]和有状态NAT64[RFC6146]对于前缀长度都是灵活的。[RFC6052]为NAT64定义了多种地址格式。在
"IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the network-specific prefix could be one of /32, /40, /48, /56, /64, and /96. The remaining part of the IPv6 address is constructed by a 32-bit IPv4 address, an 8-bit u byte and a variable length suffix (there is no u byte and suffix in the case of the 96-bit Well-Known Prefix). NAT64 is therefore OK with a subnet boundary out to /96 but not longer.
“IPv4嵌入式IPv6地址前缀和格式”[RFC6052]，特定于网络的前缀可以是/32、/40、/48、/56、/64和/96之一。IPv6地址的其余部分由32位IPv4地址、8位u字节和可变长度后缀构成（对于96位众所周知的前缀，没有u字节和后缀）。因此，NAT64可以将子网边界设置为/96，但不会更长。
o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 prefix. When the NPTv6 Translator is configured with a /48 or shorter prefix, the 64-bit interface identifier is kept unmodified during translation. However, the /64 boundary might be changed as long as the "inside" and "outside" prefixes have the same length.
o NPTv6:IPv6到IPv6网络前缀转换[RFC6296]也绑定到/64边界。NPTv6将一个/64前缀映射到另一个/64前缀。当NPTv6转换器配置了/48或更短的前缀时，64位接口标识符在转换期间保持不变。但是，只要“内部”和“外部”前缀具有相同的长度，就可以更改/64边界。
o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is designed around the /64 boundary, since it relies on locally unique 64-bit node identifiers (in the interface identifier field). While a redesign to use longer prefixes is not inconceivable, this would need major changes to the existing specification for the IPv6 version of ILNP.
o ILNP：标识符定位器网络协议（ILNP）[RFC6741]是围绕/64边界设计的，因为它依赖于本地唯一的64位节点标识符（在接口标识符字段中）。虽然重新设计使用更长的前缀并非不可想象，但这需要对ILNP的IPv6版本的现有规范进行重大修改。
o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in its insecure form treats IPv6 addresses as opaque 128-bit objects. However, to secure the protocol against spoofing, it is essential to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs are generated using a procedure that assumes a 64-bit identifier. Therefore, in effect, secure shim6 is affected by the /64 boundary exactly like CGAs.
o Shim6:IPv6多宿主垫片协议（Shim6）[RFC5533]以其不安全的形式将IPv6地址视为不透明的128位对象。然而，为了保护协议免受欺骗，必须使用CGA（见上文）或HBA[RFC5535]。与CGA一样，HBA是使用假定64位标识符的过程生成的。因此，实际上，secure shim6与CGA一样受到/64边界的影响。
o Duplicate address risk: If SLAAC was modified to work with shorter IIDs, the statistical risk of hosts choosing the same pseudo-random identifier [RFC7217] would increase correspondingly. The practical impact of this would range from slight to dramatic, depending on how much the IID length was reduced. In particular, a /120 prefix would imply an 8-bit IID and address collisions would be highly probable.
o 重复地址风险：如果SLAAC被修改为使用较短的IID，主机选择相同伪随机标识符[RFC7217]的统计风险将相应增加。根据IID长度减少的程度，这项措施的实际影响从轻微到剧烈不等。特别是，a/120前缀意味着8位IID，地址冲突的可能性很大。
o The link-local prefix: While RFC 4862 is careful not to define any specific length of link-local prefix within fe80::/10, the addressing architecture [RFC4291] does define the link-local IID length to be 64 bits. If different hosts on a link used IIDs of different lengths to form a link-local address, there is potential for confusion and unpredictable results. Typically today the choice of 64 bits for the link-local IID length is hard-coded per interface, in accordance with the relevant IPv6-over-foo specification, and systems behave as if the link-local prefix was actually fe80::/64. There might be no way to change this except
o 链路本地前缀：虽然RFC 4862小心地不在fe80:：/10中定义任何特定长度的链路本地前缀，但寻址体系结构[RFC4291]将链路本地IID长度定义为64位。如果链路上的不同主机使用不同长度的IID来形成链路本地地址，则可能会出现混乱和不可预测的结果。通常今天，根据相关的IPv6 over foo规范，链路本地IID长度的64位选择是每个接口的硬编码，系统的行为就像链路本地前缀实际上是fe80:：/64。可能没有办法改变这一点，除非
conceivably by manual configuration, which will be impossible if the host concerned has no local user interface.
可以想象，通过手动配置，如果相关主机没有本地用户界面，这将是不可能的。
It goes without saying that if prefixes longer than /64 are to be used, all hosts must be capable of generating IIDs shorter than 64 bits, in order to follow the auto-configuration procedure correctly [RFC4862].
不言而喻，如果要使用长于/64的前缀，所有主机必须能够生成小于64位的IID，以便正确遵循自动配置过程[RFC4862]。
4.3.1. Survey of the processing of Neighbor Discovery Options with Prefixes Other than /64
4.3.1. 对前缀不是/64的邻居发现选项处理的调查
This section provides a survey of the processing of Neighbor Discovery options that include prefixes that are different than /64.
本节概述了对邻居发现选项的处理，这些选项包括不同于/64的前缀。
The behavior of nodes was assessed with respect to the following options:
根据以下选项评估节点的行为：
o PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit set.
o PIO-A：带有位集的前缀信息选项（PIO）[RFC4861]。
o PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit set.
o PIO-L：设置了L位的前缀信息选项（PIO）[RFC4861]。
o PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A and L bits set.
o PIO-AL：设置了A和L位的前缀信息选项（PIO）[RFC4861]。
o RIO: Route Information Option (RIO) [RFC4191].
o RIO：路线信息选项（RIO）[RFC4191]。
In the tables below, the following notation is used:
在下表中，使用了以下符号：
NOT-SUP: This option is not supported (i.e., it is ignored no matter the prefix length used).
NOT-SUP：不支持此选项（即，无论使用的前缀长度如何，都将忽略此选项）。
LOCAL: The corresponding prefix is considered "on-link".
本地：相应的前缀被视为“在链接上”。
ROUTE: The corresponding route is added to the IPv6 routing table.
路由：将相应的路由添加到IPv6路由表中。
NOT-DEF: The default configuration is NOT-SUP, but there is an option to enable ROUTE.
NOT-DEF：默认配置为NOT-SUP，但有一个启用路由的选项。
IGNORE: The option is ignored as an error.
忽略：该选项作为错误被忽略。
+--------------------+--------+-------+--------+---------+
| Operating System | PIO-A | PIO-L | PIO-AL | RIO |
+--------------------+--------+-------+--------+---------+
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
+--------------------+--------+-------+--------+---------+
| Operating System | PIO-A | PIO-L | PIO-AL | RIO |
+--------------------+--------+-------+--------+---------+
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
Table 1: Processing of ND options with prefixes longer than /64
表1：前缀大于/64的ND选项的处理
+--------------------+--------+-------+--------+---------+
| Operating System | PIO-A | PIO-L | PIO-AL | RIO |
+--------------------+--------+-------+--------+---------+
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
+--------------------+--------+-------+--------+---------+
| Operating System | PIO-A | PIO-L | PIO-AL | RIO |
+--------------------+--------+-------+--------+---------+
| FreeBSD 9.0 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Linux 3.0.0-15 | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| Linux-current | IGNORE | LOCAL | LOCAL | NOT-DEF |
+--------------------+--------+-------+--------+---------+
| NetBSD 5.1 | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| OpenBSD-current | IGNORE | LOCAL | LOCAL | NOT-SUP |
+--------------------+--------+-------+--------+---------+
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+
Table 2: Processing of ND options with prefixes shorter than /64
表2：前缀小于/64的ND选项的处理
The results obtained can be summarized as follows:
所得结果可总结如下：
o The "A" bit in the Prefix Information Options is honored only if the prefix length is 64. This is consistent with [RFC4862], at least for the case where the IID length is defined to be 64 bits in the corresponding link-type-specific document, which is the
o 仅当前缀长度为64时，前缀信息选项中的“A”位才有效。这与[RFC4862]一致，至少对于IID长度在相应的链路类型特定文档中定义为64位的情况，这是
case for all currently published such documents. [RFC4862] defines the case where the sum of the advertised prefix length and the IID length does not equal 128 as an error condition.
所有当前发布的此类文件的案例。[RFC4862]将播发前缀长度和IID长度之和不等于128的情况定义为错误条件。
o The "L" bit in the Prefix Information Options is honored for any arbitrary prefix length (whether shorter or longer than /64).
o 前缀信息选项中的“L”位适用于任意前缀长度（无论短于或长于/64）。
o Nodes that support the Route Information Option allow such routes to be specified with prefixes of any arbitrary length (whether shorter or longer than /64)
o 支持Route Information（路由信息）选项的节点允许使用任意长度（短于或长于/64）的前缀指定此类路由
Participants in the V6OPS working group have indicated that some forwarding devices have been shown to work correctly with long prefixes such as /80 or /96. Indeed, it is to be expected that forwarding based on the longest prefix match will work for any prefix length, and no reports of this completely failing have been noted. Also, DHCPv6 is in widespread use without any dependency on the /64 boundary. Reportedly, there are deployments of /120 subnets configured using DHCPv6.
V6OPS工作组的参与者表示，一些转发设备在使用长前缀（如/80或/96）时工作正常。事实上，可以预期，基于最长前缀匹配的转发将适用于任何前缀长度，并且没有关于完全失败的报告。此外，DHCPv6正在广泛使用，对/64边界没有任何依赖性。据报道，有使用DHCPv6配置的/120子网部署。
There have been definite reports that some routers have a performance drop-off or even resource exhaustion for prefixes longer than /64 due to design issues. In particular, some routing chip designs allocate much less space for longer prefixes than for prefixes up to /64 for the sake of savings in memory, power, and lookup latency. Some devices need special-case code to handle point-to-point links according to [RFC6164].
有明确的报告称，由于设计问题，一些路由器的前缀长度超过/64时，性能下降甚至资源耗尽。特别是，为了节省内存、电源和查找延迟，一些路由芯片设计为更长的前缀分配的空间比为高达/64的前缀分配的空间少得多。根据[RFC6164]，一些设备需要特殊情况代码来处理点对点链接。
It has been reported that at least one type of switch has a content-addressable memory limited to 144 bits, which is indeed a typical value for commodity components [TCAM]. This means that packet filters or access control lists cannot be defined based on 128-bit addresses and two 16-bit port numbers; the longest prefix that could be used in such a filter is a /112.
据报道，至少有一种交换机的内容寻址内存限制在144位，这确实是商品组件[TCAM]的典型值。这意味着不能基于128位地址和两个16位端口号定义包过滤器或访问控制列表；在这种过滤器中可以使用的最长前缀是a/112。
From an early stage, implementations and deployments of IPv6 assumed the /64 subnet length, even though routing was based on prefixes of any length. As shown above, this became anchored in many specifications (Section 4.1) and in important aspects of implementations commonly used in local area networks (Section 4.3). In fact, a programmer might be lulled into assuming a comfortable rule of thumb that subnet prefixes are always /64 and an IID is always of length 64. Apart from the limited evidence in Section 4.3.1, we cannot tell without code inspections or tests
从早期阶段开始，IPv6的实现和部署就采用/64子网长度，即使路由是基于任何长度的前缀。如上所示，这在许多规范（第4.1节）和局域网中常用的实现的重要方面（第4.3节）中都有所体现。事实上，程序员可能会被误导，以为子网前缀总是/64，IID总是长度64，这是一条舒适的经验法则。除了第4.3.1节中的有限证据外，我们无法在没有代码检查或测试的情况下进行判断
whether existing stacks are able to handle a flexible IID length or whether they would require modification to do so. A conforming implementation of an IPv6-over-foo that specifies a 64 bit IID for foo links will of course only support 64. But in a well designed stack, the IP layer itself will treat that 64 as a parameter, so changing the IID length in the IPv6-over-foo code should be all that is necessary.
现有堆栈是否能够处理灵活的IID长度，或者是否需要修改才能处理。为foo链接指定64位IID的IPv6 over foo的一致性实现当然只支持64位。但在设计良好的堆栈中，IP层本身会将该64视为一个参数，因此在IPv6 over foo代码中更改IID长度应该是所有必要的。
The main practical consequence of the existing specifications is that deployments in which longer subnet prefixes are used cannot make use of SLAAC-configured addresses and require either manually configured addresses or DHCPv6. To reverse this argument, if it was considered desirable to allow auto-configured addresses with subnet prefixes longer than /64, all of the specifications identified above as depending on /64 would have to be modified with due regard to interoperability with unmodified stacks. In fact, [RFC7217] allows for this possibility. Then, modified stacks would have to be developed and deployed. It might be the case that some stacks contain dependencies on the /64 boundary that are not directly implied by the specifications, and any such hidden dependencies would also need to be found and removed.
现有规范的主要实际结果是，使用较长子网前缀的部署不能使用SLAAC配置的地址，并且需要手动配置的地址或DHCPv6。为了扭转这一论点，如果认为允许自动配置的地址的子网前缀长于/64是可取的，则必须在适当考虑到与未修改堆栈的互操作性的情况下修改上面标识为依赖于/64的所有规范。事实上，[RFC7217]允许这种可能性。然后，必须开发和部署修改后的堆栈。可能的情况是，某些堆栈在/64边界上包含规范未直接暗示的依赖项，并且还需要找到并删除任何此类隐藏的依赖项。
At least one DHCPv6 client unconditionally installs a /64 prefix as on-link when it configures an interface with an address, although some specific operating system vendors seem to change this default behavior by tweaking a client-side script. This is in clear violation of the IPv6 subnet model [RFC5942]. The motivation for this choice is that if there is no router on the link, the hosts would fail to communicate with each other using the configured addresses because the "on-link assumption" was removed in [RFC4861]. This is not really about the magic number of 64, but an implementation may sometimes pick an arbitrary value of prefix length due to the removal of the on-link assumption, and the value chosen will most likely be 64.
至少有一个DHCPv6客户端在配置带有地址的接口时无条件地将/64前缀安装为on link，尽管某些特定操作系统供应商似乎通过调整客户端脚本来更改此默认行为。这显然违反了IPv6子网模型[RFC5942]。这种选择的动机是，如果链路上没有路由器，主机将无法使用配置的地址彼此通信，因为[RFC4861]中删除了“链路上假设”。这并不是关于神奇的数字64，但由于删除了链路上的假设，实现有时可能会选择前缀长度的任意值，并且选择的值很可能是64。
Typical IP Address Management (IPAM) tools treat /64 as the default subnet length but allow users to specify longer subnet prefixes if desired. Clearly, all IPAM tools and network management systems would need to be checked in detail.
典型的IP地址管理（IPAM）工具将/64视为默认子网长度，但允许用户根据需要指定更长的子网前缀。显然，需要详细检查所有IPAM工具和网络管理系统。
Finally, IPv6 is already deployed at many sites, with a large number of staff trained on the basis of the existing standards, supported by documentation and tools based on those standards. Numerous existing middlebox devices are also based on those standards. These people, documents, tools, and devices represent a very large investment that would be seriously impacted by a change in the /64 boundary.
最后，IPv6已经在许多站点部署，大量工作人员根据现有标准进行了培训，并得到了基于这些标准的文档和工具的支持。许多现有的中间盒设备也基于这些标准。这些人员、文档、工具和设备代表了一项巨大的投资，将受到/64边界变化的严重影响。
The length of the interface identifier has implications for privacy [ADDRESS-PRIVACY]. In any case in which the value of the identifier is intended to be hard to guess, whether or not it is cryptographically generated, it is apparent that more bits are better. For example, if there are only 20 bits to be guessed, then at most just over a million guesses are needed, which is well within the capacity of a low-cost attack mechanism. It is hard to state in general how many bits are enough to protect privacy, since this depends on the resources available to the attacker, but it seems clear that a privacy solution needs to resist an attack requiring billions rather than millions of guesses. Trillions would be better, suggesting that at least 40 bits should be available. Thus, we can argue that subnet prefixes longer than say /80 might raise privacy concerns by making the IID guessable.
接口标识符的长度对隐私[地址-隐私]有影响。在标识符的值难以猜测的任何情况下，无论其是否以加密方式生成，显然比特越多越好。例如，如果只需要猜测20位，那么最多只需要超过一百万次猜测，这在低成本攻击机制的能力范围内。通常很难说明多少位足以保护隐私，因为这取决于攻击者可用的资源，但似乎很明显，隐私解决方案需要抵抗需要数十亿而不是数百万次猜测的攻击。万亿更好，这意味着至少应该有40位可用。因此，我们可以认为，子网前缀长于say/80可能会使IID变得可猜测，从而引起隐私问题。
A prefix long enough to limit the number of addresses comparably to an IPv4 subnet, such as /120, would create exactly the same situation for privacy as IPv4 except for the absence of NAT. In particular, a host would be forced to pick a new IID when roaming to a new network to avoid collisions. As mentioned earlier, it is likely that SLAAC will not be used on such a subnet.
一个足够长的前缀可以将地址数量限制在与IPv4子网相当的范围内，例如/120，除了没有NAT之外，它将创建与IPv4完全相同的隐私情况。特别是，主机在漫游到新网络时将被迫选择新的IID以避免冲突。如前所述，SLAAC很可能不会在这样的子网上使用。
In addition to the privacy issues mentioned in Section 4.5 and the issues mentioned with CGAs and HBAs in Section 4.2, the length of the subnet prefix affects the matter of defense against scanning attacks [HOST-SCANNING]. Assuming the attacker has discovered or guessed the prefix length, a longer prefix reduces the space that the attacker needs to scan, e.g., to only 256 addresses if the prefix is /120. On the other hand, if the attacker has not discovered the prefix length and assumes it to be /64, routers can trivially discard attack packets that do not fall within an actual subnet.
除了第4.5节中提到的隐私问题以及第4.2节中提到的CGA和HBA问题外，子网前缀的长度还影响扫描攻击的防御问题[主机扫描]。假设攻击者发现或猜测了前缀长度，则较长的前缀会减少攻击者需要扫描的空间，例如，如果前缀为/120，则仅扫描256个地址。另一方面，如果攻击者没有发现前缀长度并假定它为/64，路由器可以轻易丢弃不属于实际子网的攻击数据包。
However, assume that an attacker finds one valid address "A" and assumes that it is within a long prefix such as a /120. The attacker then starts a scanning attack by scanning "outwards" from A, by trying A+1, A-1, A+2, A-2, etc. This attacker will easily find all hosts in any subnet with a long prefix, because they will have addresses close to A. We therefore conclude that any prefix containing densely packed valid addresses is vulnerable to a scanning attack, without the attacker needing to guess the prefix length. Therefore, to preserve IPv6's advantage over IPv4 in resisting scanning attacks, it is important that subnet prefixes are short enough to allow sparse allocation of identifiers within each subnet. The considerations are similar to those for privacy, and we can again
但是，假设攻击者找到一个有效地址“A”，并假设它位于长前缀（如A/120）内。然后，攻击者通过尝试a+1、a-1、a+2、a-2等从a“向外”扫描来启动扫描攻击。该攻击者将很容易找到任何子网中具有长前缀的所有主机，因为它们的地址接近a。因此，我们得出结论，任何包含密集有效地址的前缀都容易受到扫描攻击，攻击者无需猜测前缀长度。因此，为了保持IPv6在抵御扫描攻击方面优于IPv4，子网前缀必须足够短，以允许在每个子网内稀疏分配标识符。考虑因素与隐私类似，我们可以再次
argue that prefixes longer than say /80 might significantly increase vulnerability. Ironically, this argument is exactly converse to the argument for longer prefixes to resist an ND cache attack, as described in Section 3.4.
认为前缀长度超过say/80可能会显著增加漏洞。具有讽刺意味的是，此参数与使用更长前缀来抵抗ND缓存攻击的参数正好相反，如第3.4节所述。
Denial-of-service attacks related to Neighbor Discovery are discussed in Section 3.4 and in [RFC6583]. One of the mitigations suggested by that document is "sizing subnets to reflect the number of addresses actually in use", but the fact that this greatly simplifies scanning attacks is not noted. For further discussion of scanning attacks, see [HOST-SCANNING].
第3.4节和[RFC6583]中讨论了与邻居发现相关的拒绝服务攻击。该文件建议的缓解措施之一是“调整子网的大小以反映实际使用的地址数”，但没有注意到这大大简化了扫描攻击的事实。有关扫描攻击的进一步讨论，请参阅[主机扫描]。
Note that, although not known at the time of writing, there might be other resource exhaustion attacks available, similar in nature to the ND cache attack. We cannot exclude that such attacks might be exacerbated by sparsely populated subnets such as a /64. It should also be noted that this analysis assumes a conventional deployment model with a significant number of end-systems located in a single LAN broadcast domain. Other deployment models might lead to different conclusions.
请注意，尽管在撰写本文时未知，但可能存在其他可用的资源耗尽攻击，其性质类似于ND缓存攻击。我们不能排除人口稀少的子网（如a/64）可能会加剧此类攻击。还应注意的是，该分析假设传统部署模型中有大量终端系统位于单个LAN广播域中。其他部署模型可能会得出不同的结论。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464]Crawford，M.，“通过以太网传输IPv6数据包”，RFC 2464，1998年12月<http://www.rfc-editor.org/info/rfc2464>.
[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998, <http://www.rfc-editor.org/info/rfc2467>.
[RFC2467]克劳福德，M.，“通过FDDI网络传输IPv6数据包”，RFC2467，1998年12月<http://www.rfc-editor.org/info/rfc2467>.
[RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998, <http://www.rfc-editor.org/info/rfc2470>.
[RFC2470]Crawford，M.，Narten，T.，和S.Thomas，“通过令牌环网传输IPv6数据包”，RFC 24701998年12月<http://www.rfc-editor.org/info/rfc2470>.
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999, <http://www.rfc-editor.org/info/rfc2492>.
[RFC2492]Armitage，G.，Schulter，P.，和M.Jork，“ATM网络上的IPv6”，RFC 2492，1999年1月<http://www.rfc-editor.org/info/rfc2492>.
[RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet Networks", RFC 2497, January 1999, <http://www.rfc-editor.org/info/rfc2497>.
[RFC2497]Souvatzis，I.，“通过ARCnet网络传输IPv6数据包”，RFC 2497，1999年1月<http://www.rfc-editor.org/info/rfc2497>.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999, <http://www.rfc-editor.org/info/rfc2526>.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月<http://www.rfc-editor.org/info/rfc2526>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999, <http://www.rfc-editor.org/info/rfc2529>.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月<http://www.rfc-editor.org/info/rfc2529>.
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, May 1999, <http://www.rfc-editor.org/info/rfc2590>.
[RFC2590]Conta，A.，Malis，A.，和M.Mueller，“通过帧中继网络传输IPv6数据包规范”，RFC 25901999年5月<http://www.rfc-editor.org/info/rfc2590>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月<http://www.rfc-editor.org/info/rfc2710>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001, <http://www.rfc-editor.org/info/rfc3056>.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月<http://www.rfc-editor.org/info/rfc3056>.
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001, <http://www.rfc-editor.org/info/rfc3146>.
[RFC3146]Fujisawa，K.和A.Onoe，“通过IEEE 1394网络传输IPv6数据包”，RFC 3146，2001年10月<http://www.rfc-editor.org/info/rfc3146>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002, <http://www.rfc-editor.org/info/rfc3306>.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月<http://www.rfc-editor.org/info/rfc3306>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33151003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003, <http://www.rfc-editor.org/info/rfc3590>.
[RFC3590]Haberman，B.，“多播侦听器发现（MLD）协议的源地址选择”，RFC 35902003年9月<http://www.rfc-editor.org/info/rfc3590>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月<http://www.rfc-editor.org/info/rfc3810>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 39562004年11月<http://www.rfc-editor.org/info/rfc3956>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月<http://www.rfc-editor.org/info/rfc3972>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月<http://www.rfc-editor.org/info/rfc4191>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月<http://www.rfc-editor.org/info/rfc4213>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006, <http://www.rfc-editor.org/info/rfc4338>.
[RFC4338]DeSanti，C.，Carlson，C.，和R.Nixon，“通过光纤通道传输IPv6，IPv4和地址解析协议（ARP）数据包”，RFC 4338，2006年1月<http://www.rfc-editor.org/info/rfc4338>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月<http://www.rfc-editor.org/info/rfc4380>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006, <http://www.rfc-editor.org/info/rfc4429>.
[RFC4429]Moore，N.，“IPv6的乐观重复地址检测（DAD）”，RFC 44292006年4月<http://www.rfc-editor.org/info/rfc4429>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007, <http://www.rfc-editor.org/info/rfc5072>.
[RFC5072]Varada，S.，Haskins，D.，和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月<http://www.rfc-editor.org/info/rfc5072>.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008, <http://www.rfc-editor.org/info/rfc5121>.
[RFC5121]Patil，B.，Xia，F.，Sarikaya，B.，Choi，JH.，和S.Madanapalli，“通过IEEE 802.16网络上的IPv6聚合子层传输IPv6”，RFC 51212008年2月<http://www.rfc-editor.org/info/rfc5121>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月<http://www.rfc-editor.org/info/rfc5214>.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009, <http://www.rfc-editor.org/info/rfc5453>.
[RFC5453]Krishnan，S.，“保留IPv6接口标识符”，RFC 54532009年2月<http://www.rfc-editor.org/info/rfc5453>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月<http://www.rfc-editor.org/info/rfc5533>.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009, <http://www.rfc-editor.org/info/rfc5535>.
[RFC5535]Bagnulo，M.，“基于哈希的地址（HBA）”，RFC5352009年6月<http://www.rfc-editor.org/info/rfc5535>.
[RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009, <http://www.rfc-editor.org/info/rfc5692>.
[RFC5692]Jeon，H.，Jeong，S.，和M.Riegel，“通过IEEE 802.16网络通过以太网传输IP”，RFC 5692，2009年10月<http://www.rfc-editor.org/info/rfc5692>.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010, <http://www.rfc-editor.org/info/rfc5942>.
[RFC5942]Singh，H.，Beebee，W.和E.Nordmark，“IPv6子网模型：链路和子网前缀之间的关系”，RFC 59422010年7月<http://www.rfc-editor.org/info/rfc5942>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月<http://www.rfc-editor.org/info/rfc5969>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月<http://rfc-editor.org/info/rfc6146>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>.
[RFC6164]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，RFC 61642011年4月<http://www.rfc-editor.org/info/rfc6164>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.
[RFC6177]Narten，T.，Huston，G.和L.Roberts，“终端站点的IPv6地址分配”，BCP 157，RFC 6177，2011年3月<http://www.rfc-editor.org/info/rfc6177>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月<http://www.rfc-editor.org/info/rfc6296>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，2011年11月<http://www.rfc-editor.org/info/rfc6437>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，2013年11月<http://www.rfc-editor.org/info/rfc7084>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[ADDRESS-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, draft-ietf-6man-ipv6-address-generation-privacy-02, October 2014.
[ADDRESS-PRIVACY]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的隐私考虑”，正在进行的工作，草稿-ietf-6man-IPv6-ADDRESS-Generation-PRIVACY-022014年10月。
[AERO-TRANS] Templin, F., "Transmission of IP Packets over AERO Links", Work in Progress, draft-templin-aerolink-46, October 2014.
[AERO-TRANS]Templin，F.，“航空链路上IP数据包的传输”，正在进行的工作，draft-Templin-aerolink-46，2014年10月。
[BLUETOOTH-LE] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Work in Progress, draft-ietf-6lowpan-btle-12, February 2013.
[BLUETOOTH-LE]Nieminen，J.，Savolainen，T.，Isomaki，M.，Patil，B.，Shelby，Z.，和C.Gomez，“通过蓝牙低能量传输IPv6数据包”，正在进行的工作，草案-ietf-6lowpan-btle-12，2013年2月。
[HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host-scanning-04, June 2014.
[主机扫描]Gont，F.和T.Chown，“IPv6网络中的网络侦察”，正在进行的工作，草稿-ietf-opsec-IPv6-HOST-SCANNING-042014年6月。
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2001 (R2007), 2007.
[IEEE802]IEEE，“局域网和城域网的IEEE标准：概述和体系结构”，IEEE标准802-2001（R2007），2007年。
[IPv6-G9959] Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", Work in Progress, draft-ietf-6lo-lowpanz-08, October 2014.
[IPv6-G9959]Brandt，A.和J.Buron，“通过ITU-T G.9959网络传输IPv6数据包”，正在进行的工作，草案-ietf-6lo-lowpanz-08，2014年10月。
[IPv6-TRANS] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", Work in Progress, draft-ietf-6lo-6lobac-00, July 2014.
[IPv6 TRANS]Lynn，K.，Ed.，Martocci，J.，Neilson，C.，和S.Donaldson，“通过MS/TP网络传输IPv6”，正在进行的工作，草稿-ietf-6lo-6lobac-00，2014年7月。
[ODELL] O'Dell, M., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, draft-odell-8+8-00, October 1996.
[ODELL]O'Dell，M.，“8+8-IPv6的替代寻址体系结构”，正在进行的工作，草稿-ODELL-8+8-00，1996年10月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, <http://www.rfc-editor.org/info/rfc2629>.
[RFC2629]Rose，M.“使用XML编写I-D和RFC”，RFC 26292999年6月<http://www.rfc-editor.org/info/rfc2629>.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>.
[RFC3756]Nikander，P.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月<http://www.rfc-editor.org/info/rfc3756>.
[RFC4692] Huston, G., "Considerations on the IPv6 Host Density Metric", RFC 4692, October 2006, <http://www.rfc-editor.org/info/rfc4692>.
[RFC4692]Huston，G.，“关于IPv6主机密度度量的考虑”，RFC 46922006年10月<http://www.rfc-editor.org/info/rfc4692>.
[RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC 4887, July 2007, <http://www.rfc-editor.org/info/rfc4887>.
[RFC4887]Thubert，P.，Wakikawa，R.，和V.Devarapalli，“网络移动性家庭网络模型”，RFC 4887，2007年7月<http://www.rfc-editor.org/info/rfc4887>.
[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009, <http://www.rfc-editor.org/info/rfc5505>.
[RFC5505]Aboba，B.，Thaler，D.，Andersson，L.，和S.Cheshire，“互联网主机配置原则”，RFC 5505，2009年5月<http://www.rfc-editor.org/info/rfc5505>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://rfc-editor.org/info/rfc6583>.
[RFC6583]Gashinsky，I.，Jaeggli，J.，和W.Kumari，“操作邻居发现问题”，RFC 65832012年3月<http://rfc-editor.org/info/rfc6583>.
[RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, November 2012, <http://www.rfc-editor.org/info/rfc6741>.
[RFC6741]阿特金森，RJ.，“标识符定位器网络协议（ILNP）工程注意事项”，RFC 67412012年11月<http://www.rfc-editor.org/info/rfc6741>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，2013年4月<http://www.rfc-editor.org/info/rfc6877>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, January 2014, <http://www.rfc-editor.org/info/rfc7094>.
[RFC7094]McPherson，D.，Oran，D.，Thaler，D.，和E.Osterweil，“IP选播的架构考虑”，RFC 7094，2014年1月<http://www.rfc-editor.org/info/rfc7094>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 2014, <http://www.rfc-editor.org/info/rfc7278>.
[RFC7278]Byrne，C.，Durke，D.，和A.Vizdal，“将IPv6/64前缀从第三代合作伙伴项目（3GPP）移动接口扩展到LAN链路”，RFC 7278，2014年6月<http://www.rfc-editor.org/info/rfc7278>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC, 7368, October 2014.
[RFC7368]Chown，T.，Ed.，Arkko，J.，Brandt，A.，Troan，O.，和J.Weil，“IPv6家庭网络架构原则”，RFC，7368，2014年10月。
[TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic Approaches to Redesigning TCAM-Based Systems", ACM SIGMETRICS'08 467-468, 2008.
[TCAM]Meiners，C.，Liu，A.，和E.Torng，“重新设计基于TCAM系统的算法方法”，ACM SIGMETRICS'08 467-468，2008年。
Acknowledgements
致谢
This document was inspired by a vigorous discussion on the V6OPS working group mailing list with at least 20 participants. Later, valuable comments were received from Ran Atkinson, Fred Baker, Steven Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other participants in the 6MAN working group. An extremely detailed review by Mark Smith was especially helpful.
本文件的灵感来源于与至少20名与会者就V6OPS工作组邮件列表进行的热烈讨论。后来，Ran Atkinson、Fred Baker、Steven Blake、Lorenzo Coletti、David Farmer、Bill Fenner、Ray Hunter、Paraskevi Iliadou、Jen Linkova、Philip Matthews、Matthew Petach、Scott Schmit、Tatuya Jinmei、Fred Templin、Ole Troan、Stig Venaas以及6MAN工作组的许多其他参与者提出了宝贵的意见。马克·史密斯（Mark Smith）的一篇极其详细的评论尤其有用。
This document was originally produced using the xml2rfc tool [RFC2629].
本文档最初使用xml2rfc工具[RFC2629]生成。
Authors' Addresses
作者地址
Brian Carpenter (editor) Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand EMail: brian.e.carpenter@gmail.com
Brian Carpenter（编辑）奥克兰大学计算机科学系PB 92019奥克兰1142新西兰电子邮件：布瑞恩。carpenter@gmail.com
Tim Chown University of Southampton Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
提姆南安普顿南安普敦大学，汉普郡SO171BJ英国电子邮件：tjc@ecs.soton.ac.uk
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina EMail: fgont@si6networks.com
Fernando Gont SI6 Networks/UTN-FRH Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷电子邮件：fgont@si6networks.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com
中国北京海淀区北青路156号华为校园盛江华为技术有限公司Q14邮编：100095电子邮件：jiangsheng@huawei.com
Alexandru Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France EMail: Alexandru.Petrescu@cea.fr
Alexandru Petrescu CEA，列出CEA Saclay Gif sur Yvette，Ile de France 91190法国电子邮件：Alexandru。Petrescu@cea.fr
Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem 1830 Belgium EMail: ayourtch@cisco.com
Andrew Yourtchenko Cisco 7a de Kleetlaan Diegem 1830比利时电子邮件：ayourtch@cisco.com