Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 7934 V. Cerf
BCP: 204 Google
Category: Best Current Practice S. Cheshire
ISSN: 2070-1721 D. Schinazi
Apple Inc.
July 2016
Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 7934 V. Cerf
BCP: 204 Google
Category: Best Current Practice S. Cheshire
ISSN: 2070-1721 D. Schinazi
Apple Inc.
July 2016
Host Address Availability Recommendations
主机地址可用性建议
Abstract
摘要
This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.
本文档建议网络在连接时为通用终端主机提供多个全局IPv6地址，并介绍了这样做的好处和选项。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第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/rfc7934.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7934.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Common IPv6 Deployment Model . . . . . . . . . . . . . . . . 3
3. Benefits of Providing Multiple Addresses . . . . . . . . . . 3
4. Problems with Restricting the Number of Addresses per Host . 4
5. Overcoming Limits Using Network Address Translation . . . . . 5
6. Options for Providing More Than One Address . . . . . . . . . 6
7. Number of Addresses Required . . . . . . . . . . . . . . . . 8
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
9. Operational Considerations . . . . . . . . . . . . . . . . . 9
9.1. Host Tracking . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Address Space Management . . . . . . . . . . . . . . . . 10
9.3. Addressing Link-Layer Scalability Issues via IP Routing . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Common IPv6 Deployment Model . . . . . . . . . . . . . . . . 3
3. Benefits of Providing Multiple Addresses . . . . . . . . . . 3
4. Problems with Restricting the Number of Addresses per Host . 4
5. Overcoming Limits Using Network Address Translation . . . . . 5
6. Options for Providing More Than One Address . . . . . . . . . 6
7. Number of Addresses Required . . . . . . . . . . . . . . . . 8
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
9. Operational Considerations . . . . . . . . . . . . . . . . . 9
9.1. Host Tracking . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Address Space Management . . . . . . . . . . . . . . . . 10
9.3. Addressing Link-Layer Scalability Issues via IP Routing . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
In most aspects, the IPv6 protocol is very similar to IPv4. This similarity can create a tendency to think of IPv6 as 128-bit IPv4, and thus lead network designers and operators to apply identical configurations and operational practices to both. This is generally a good thing because it eases the transition to IPv6 and the operation of dual-stack networks. However, in some design and operational areas, it can lead to carrying over IPv4 practices that are limiting or not appropriate in IPv6 due to differences between the protocols.
在大多数方面，IPv6协议与IPv4非常相似。这种相似性可能导致将IPv6视为128位IPv4的趋势，从而导致网络设计者和运营商将相同的配置和操作实践应用于两者。这通常是一件好事，因为它简化了向IPv6的过渡和双栈网络的操作。然而，在某些设计和操作领域，由于协议之间的差异，它可能导致IPv4实践在IPv6中受到限制或不适用。
One such area is IP addressing, particularly IP addressing of hosts. This is substantially different because unlike IPv4 addresses, IPv6 addresses are not a scarce resource. In IPv6, a single link provides over four billion times more address space than the whole IPv4 Internet [RFC7421]. Thus, unlike IPv4, IPv6 networks are not forced by address scarcity concerns to provide only one address per host. Furthermore, providing multiple addresses has many benefits, including application functionality and simplicity, privacy, and flexibility to accommodate future applications. Another significant benefit is the ability to provide Internet access without the use of Network Address Translation (NAT). Providing only one IPv6 address per host negates these benefits.
其中一个领域是IP地址，特别是主机的IP地址。这与IPv4地址大不相同，因为IPv6地址不是稀缺资源。在IPv6中，单个链路提供的地址空间是整个IPv4互联网的40多亿倍[RFC7421]。因此，与IPv4不同，IPv6网络不会因地址稀缺问题而强制每个主机只提供一个地址。此外，提供多个地址有许多好处，包括应用程序功能和简单性、隐私性以及适应未来应用程序的灵活性。另一个显著的优点是能够在不使用网络地址转换（NAT）的情况下提供Internet访问。每个主机只提供一个IPv6地址否定了这些好处。
This document details the benefits of providing multiple addresses per host, and the problems with not doing so. It recommends that networks provide general-purpose end hosts with multiple global addresses when they attach and lists current options for doing so. It does not specify any changes to protocols or host behavior.
本文档详细介绍了为每台主机提供多个地址的好处，以及不提供多个地址的问题。它建议网络在连接时为通用终端主机提供多个全局地址，并列出当前的选项。它不指定对协议或主机行为的任何更改。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。
IPv6 is designed to support multiple addresses, including multiple global addresses, per interface (see Section 2.1 of [RFC4291] and Section 5.9.4 of [RFC6434]). Today, many general-purpose IPv6 hosts are configured with three or more addresses per interface: a link-local address, a stable address (e.g., using 64-bit Extended Unique Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]), one or more privacy addresses [RFC4941], and possibly one or more temporary or non-temporary addresses obtained using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
IPv6设计为支持每个接口的多个地址，包括多个全局地址（参见[RFC4291]第2.1节和[RFC6434]第5.9.4节）。如今，许多通用IPv6主机在每个接口上配置了三个或更多地址：链路本地地址、稳定地址（例如，使用64位扩展唯一标识符（EUI-64）或不透明接口标识符[RFC7217]）、一个或多个隐私地址[RFC4941]，以及可能使用IPv6动态主机配置协议（DHCPv6）[RFC3315]获得的一个或多个临时或非临时地址。
In most general-purpose IPv6 networks, hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network. Such networks include all 3GPP networks ([RFC6459], Section 5.2), in addition to Ethernet and Wi-Fi networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862].
在大多数通用IPv6网络中，主机能够从链路前缀配置其他IPv6地址，而无需向网络发出明确请求。除了使用无状态地址自动配置（SLAAC）[RFC4862]的以太网和Wi-Fi网络之外，此类网络还包括所有3GPP网络（[RFC6459]，第5.2节）。
Today, there are many host functions that require more than one IP address to be available to the host, including:
如今，有许多主机功能需要一个以上的IP地址才能供主机使用，包括：
o Privacy addressing to prevent tracking by off-network hosts [RFC4941].
o 防止非网络主机跟踪的隐私寻址[RFC4941]。
o Multiple processors inside the same device. For example, in many mobile devices, both the application processor and the baseband processor need to communicate with the network, particularly for technologies like I-WLAN [TS.24327] where the two processors share the Wi-Fi network connection.
o 同一设备内有多个处理器。例如，在许多移动设备中，应用处理器和基带处理器都需要与网络通信，特别是对于I-WLAN[TS.24327]等技术，其中两个处理器共享Wi-Fi网络连接。
o Extending the network (e.g., "tethering").
o 扩展网络（例如，“栓系”）。
o Running virtual machines on hosts.
o 在主机上运行虚拟机。
o Translation-based transition technologies such as 464XLAT (a combination of stateful and stateless translation) [RFC6877] that translate between IPv4 and IPv6. Some of these technologies require the availability of a dedicated IPv6 address in order to determine whether inbound packets are translated or native ([RFC6877], Section 6.3).
o 基于转换的转换技术，如464XLAT（有状态和无状态转换的组合）[RFC6877]，可在IPv4和IPv6之间转换。其中一些技术需要专用IPv6地址的可用性，以确定入站数据包是转换的还是本机的（[RFC6877]，第6.3节）。
o Identifier-locator addressing (ILA) [ILA].
o 标识符定位器寻址（ILA）[ILA]。
o Future applications (e.g., per-application IPv6 addresses [TARP]).
o 未来的应用程序（例如，每个应用程序的IPv6地址[TARP]）。
Two examples of how the availability of multiple addresses per host has already allowed substantial deployment of new applications without explicit requests to the network are:
每个主机多个地址的可用性已经允许大量部署新应用程序，而无需向网络发出明确请求，这两个示例如下：
o 464XLAT. 464XLAT is usually deployed within a particular network; in this model, the operator can ensure that the network is appropriately configured to provide the customer-side translator (CLAT) with the additional IPv6 address it needs to implement 464XLAT. However, there are deployments where the provider-side translator (PLAT) (i.e., NAT64) is provided as a service by a different network, without the knowledge or cooperation of the residential ISP (e.g., the IPv6v4 Exchange Service [IPv6v4]). This type of deployment is only possible because those residential ISPs provide multiple IP addresses to their users, and thus those users can freely obtain the extra IPv6 address required to run 464XLAT.
o 464XLAT。464XLAT通常部署在特定网络中；在此模型中，运营商可以确保网络经过适当配置，为客户端转换器（CLAT）提供实施464XLAT所需的额外IPv6地址。然而，在一些部署中，提供商端转换器（PLAT）（即NAT64）作为服务由不同的网络提供，而不需要住宅ISP（例如IPv6v4交换服务[IPv6v4]）的了解或合作。这种类型的部署之所以可能，是因为这些住宅ISP向其用户提供多个IP地址，因此这些用户可以自由获得运行464XLAT所需的额外IPv6地址。
o /64 sharing [RFC7278]. When the topology supports it, this is a way to provide IPv6 tethering without needing to wait for network operators to deploy DHCPv6 Prefix Delegation (PD), which is only available in 3GPP release 10 or above ([RFC6459], Section 5.3).
o /64共享[RFC7278]。当拓扑支持时，这是一种提供IPv6连接的方法，无需等待网络运营商部署DHCPv6前缀委派（PD），它仅在3GPP版本10或更高版本中可用（[RFC6459]，第5.3节）。
Providing a restricted number of addresses per host implies that functions that require multiple addresses either will be unavailable (e.g., if the network provides only one IPv6 address per host, or if the host has reached the limit of the number of addresses available) or will only be available after an explicit request to the network is granted. Requiring explicit requests to the network has the following drawbacks:
每个主机提供有限数量的地址意味着需要多个地址的功能将不可用（例如，如果网络每个主机仅提供一个IPv6地址，或者如果主机已达到可用地址数量的限制）或仅在向网络发出明确请求后才可用。要求向网络发出明确的请求有以下缺点：
o Increased latency, because a provisioning operation, and possibly human intervention with an update to the Service Level Agreement (SLA), must complete before the functionality is available.
o 延迟增加，因为在功能可用之前，必须完成资源调配操作，可能还需要人工干预以更新服务级别协议（SLA）。
o Uncertainty, because it is not known if a particular application function will be available until the provisioning operation succeeds or fails.
o 不确定性，因为在配置操作成功或失败之前，不知道特定的应用程序功能是否可用。
o Complexity, because implementations need to deal with failures and somehow present them to the user. Failures may manifest as timeouts, which may be slow and frustrating to users.
o 复杂性，因为实现需要处理故障并以某种方式将其呈现给用户。失败可能表现为超时，这可能很慢，并且会让用户感到沮丧。
o Increased load on the network's provisioning servers.
o 增加了网络资源调配服务器的负载。
Some operators may desire that their networks be configured to limit the number of IPv6 addresses per host. Reasons might include hardware limitations (e.g., Ternary Content-Addressable Memory (TCAM) size or size constraints of the Neighbor Cache table), business models (e.g., a desire to charge the network's users on a per-device basis), or operational consistency with IPv4 (e.g., an IP address management system that only supports one address per host). However, hardware limitations are expected to ease over time, and an attempt to generate additional revenue by charging per device may prove counterproductive if customers respond (as they did with IPv4) by using NAT, which results in no additional revenue, but leads to more operational problems and higher support costs.
一些运营商可能希望将其网络配置为限制每个主机的IPv6地址数。原因可能包括硬件限制（例如，三元内容寻址内存（TCAM）大小或邻居缓存表的大小限制）、业务模式（例如，希望按每个设备向网络用户收费）或与IPv4的操作一致性（例如，每个主机只支持一个地址的IP地址管理系统）. 然而，随着时间的推移，硬件限制有望缓解，如果客户使用NAT进行响应（就像他们使用IPv4时所做的那样），则通过对每个设备收费来产生额外收入的尝试可能会适得其反，这不会带来额外收入，但会导致更多的运营问题和更高的支持成本。
When the network limits the number of addresses available to a host, this can mostly be overcome by end hosts by using NAT, and indeed in IPv4 the scarcity of addresses is often mitigated by using NAT on the host. Thus, the limits could be overcome in IPv6 as well by implementing NAT66 on the host.
当网络限制主机可用的地址数量时，终端主机可以通过使用NAT来克服这一问题，事实上，在IPv4中，在主机上使用NAT通常可以缓解地址的稀缺性。因此，在IPv6中也可以通过在主机上实现NAT66来克服这些限制。
Unfortunately, NAT has well-known drawbacks. For example, it causes application complexity due to the need to implement NAT traversal. It hinders development of new applications. On mobile devices, it reduces battery life due to the necessity of frequent keepalives, particularly for UDP. Applications using UDP that need to work on most of the Internet are forced to send keepalives at least every 30 seconds [KA]. For example, the QUIC protocol uses a 15-second keepalive [QUIC]. Other drawbacks of NAT are well-known and documented [RFC2993]. While IPv4 NAT is inevitable due to the limited amount of IPv4 space available, that argument does not apply to IPv6. Guidance from the Internet Architecture Board (IAB) is that deployment of IPv6 NAT is not desirable [RFC5902].
不幸的是，NAT有众所周知的缺点。例如，由于需要实现NAT遍历，它会导致应用程序的复杂性。它阻碍了新应用的开发。在移动设备上，由于需要频繁保持，特别是UDP，它会缩短电池寿命。使用UDP的应用程序需要在大部分互联网上运行，因此必须至少每30秒发送一次keepalives[KA]。例如，QUIC协议使用15秒的keepalive[QUIC]。NAT的其他缺点是众所周知的，并有文献记载[RFC2993]。由于IPv4可用空间有限，IPv4 NAT不可避免，但该论点不适用于IPv6。互联网体系结构委员会（IAB）的指导意见是，部署IPv6 NAT是不可取的[RFC5902]。
The desire to overcome the problems listed in Section 4 without disabling any features has resulted in developers implementing IPv6 NAT. There are fully stateful address+port NAT66 implementations in client operating systems today: for example, Linux has supported
为了克服第4节中列出的问题而不禁用任何功能，开发人员实现了IPv6 NAT。如今，在客户端操作系统中有完全有状态的地址+端口NAT66实现：例如，Linux支持
NAT66 since 2012 [L66]. At least one popular software hypervisor also implemented NAT66 to work around these issues [V66]. Wide deployment of networks that provide a restricted number of addresses will cause proliferation of NAT66 implementations.
NAT66自2012年起[L66]。至少有一个流行的软件虚拟机监控程序也实现了NAT66来解决这些问题[V66]。广泛部署提供有限数量地址的网络将导致NAT66实现的激增。
This is not a desirable outcome. It is not desirable for users because they may experience application brittleness. It is likely not desirable for network operators either, as they may suffer higher support costs, and even when the decision to provide only one IPv6 address per device is dictated by the network's business model, there may be little in the way of incremental revenue, because devices can share their IPv6 address with other devices. Finally, it is not desirable for operating system manufacturers and application developers, who will have to build more complexity, lengthening development time and/or reducing the time spent on other features.
这不是一个理想的结果。这对于用户来说是不可取的，因为他们可能会经历应用程序的脆弱性。网络运营商可能也不希望这样做，因为他们可能会承受更高的支持成本，甚至当每个设备只提供一个IPv6地址的决定取决于网络的商业模式时，增加收入的途径也可能很少，因为设备可以与其他设备共享其IPv6地址。最后，对于操作系统制造商和应用程序开发人员来说，这是不可取的，他们将不得不构建更复杂的系统，延长开发时间和/或减少在其他功能上花费的时间。
Indeed, it could be argued that the main reason for deploying IPv6, instead of continuing to scale the Internet using only IPv4 and large-scale NAT44, is because doing so can provide all the hosts on the planet with end-to-end connectivity that is constrained not by accidental technical limitations, but only by intentional security policies.
事实上，可以说，部署IPv6而不是继续只使用IPv4和大规模NAT44扩展互联网的主要原因是，这样做可以为地球上的所有主机提供端到端连接，而这种连接不受意外技术限制的限制，而只受有意的安全策略的限制。
Multiple IPv6 addresses can be provided in the following ways:
可以通过以下方式提供多个IPv6地址：
o Using Stateless Address Autoconfiguration (SLAAC) [RFC4862]. SLAAC allows hosts to create global IPv6 addresses on demand by simply forming new addresses from the global prefix(es) assigned to the link. Typically, SLAAC is used on shared links, but it is also possible to use SLAAC while providing a dedicated /64 prefix to each host. This is the case, for example, if the host is connected via a point-to-point link such as in 3GPP networks, on a network where each host has its own dedicated VLAN, or on a wireless network where every Media Access Control (MAC) address is placed in its own broadcast domain.
o 使用无状态地址自动配置（SLAAC）[RFC4862]。SLAAC允许主机根据需要创建全局IPv6地址，只需根据分配给链路的全局前缀形成新地址即可。通常，SLAAC用于共享链路，但也可以在为每个主机提供专用/64前缀的同时使用SLAAC。例如，如果主机通过点对点链路（例如在3GPP网络中）、在每个主机具有其自己的专用VLAN的网络上、或在每个媒体访问控制（MAC）地址位于其自己的广播域中的无线网络上连接，则情况就是如此。
o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 clients only ask for one non-temporary address, but the protocol allows requesting multiple temporary and even multiple non-temporary addresses, and the server could choose to provide multiple addresses. It is also technically possible for a client to request additional addresses using a different DHCP Unique Identifier (DUID), though the DHCPv6 specification implies that this is not expected behavior ([RFC3315], Section 9). The DHCPv6 server will decide whether to grant or reject the request based on information about the client, including its DUID, MAC address, and
o 使用有状态DHCPv6地址分配[RFC3315]。大多数DHCPv6客户端只请求一个非临时地址，但该协议允许请求多个临时甚至多个非临时地址，服务器可以选择提供多个地址。在技术上，客户机也可以使用不同的DHCP唯一标识符（DUID）请求其他地址，尽管DHCPv6规范暗示这不是预期的行为（[RFC3315]，第9节）。DHCPv6服务器将根据有关客户端的信息（包括其DUID、MAC地址和地址）决定是否批准或拒绝请求
more. The maximum number of IPv6 addresses that can be provided in a single DHCPv6 packet, given a typical MTU of 1500 bytes or smaller, is approximately 30.
更多给定1500字节或更小的典型MTU，单个DHCPv6数据包中可以提供的最大IPv6地址数约为30。
o DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD allows the client to request and be delegated a prefix, from which it can autonomously form other addresses. If the prefix is shorter than /64, it can be divided into multiple subnets that can be further delegated to downstream clients. If the prefix is a /64, it can be extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389], or /64 sharing [RFC7278], but it cannot be further subdivided, as a prefix longer than /64 is outside the current IPv6 specifications [RFC7421]. While the DHCPv6 Prefix Delegation specification [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD itself does not require that the client forward IPv6 packets not addressed to itself, and thus does not require that the client be an IPv6 router as defined in the IPv6 specification [RFC2460]. Also, in many cases (such as tethering, or hosting virtual machines), hosts are already forwarding IPv6 packets and thus operating as IPv6 routers as defined in the IPv6 specification [RFC2460].
o DHCPv6前缀委派（PD）[RFC3633]。DHCPv6 PD允许客户端请求并被委派一个前缀，它可以从中自主地形成其他地址。如果前缀短于/64，则可以将其划分为多个子网，这些子网可以进一步委托给下游客户端。如果前缀是a/64，则可以通过L2桥接、邻居发现（ND）代理[RFC4389]或/64共享[RFC7278]对其进行扩展，但不能进一步细分，因为长度超过/64的前缀超出当前IPv6规范[RFC7421]。虽然DHCPv6前缀委派规范[RFC3633]假设DHCPv6客户端是路由器，但DHCPv6 PD本身并不要求客户端转发未寻址到自身的IPv6数据包，因此也不要求客户端是IPv6规范[RFC2460]中定义的IPv6路由器。此外，在许多情况下（如栓系或托管虚拟机），主机已经在转发IPv6数据包，因此作为IPv6规范[RFC2460]中定义的IPv6路由器运行。
+--------------------------+-------+-------------+--------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | |
| | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+
| Can extend network | No+ | No | Yes | Yes |
| | | | | (NAT44) |
| Can number "unlimited" | Yes* | Yes* | No | No |
| endpoints | | | | |
| Uses stateful, request- | No | Yes | Yes | Yes |
| based assignment | | | | |
| Is immune to Layer 3 on- | No | Yes | Yes | Yes |
| link resource exhaustion | | | | |
| attacks | | | | |
+--------------------------+-------+-------------+--------+---------+
+--------------------------+-------+-------------+--------+---------+
| | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 |
| | | IA_NA / | PD | |
| | | IA_TA | | |
+--------------------------+-------+-------------+--------+---------+
| Can extend network | No+ | No | Yes | Yes |
| | | | | (NAT44) |
| Can number "unlimited" | Yes* | Yes* | No | No |
| endpoints | | | | |
| Uses stateful, request- | No | Yes | Yes | Yes |
| based assignment | | | | |
| Is immune to Layer 3 on- | No | Yes | Yes | Yes |
| link resource exhaustion | | | | |
| attacks | | | | |
+--------------------------+-------+-------------+--------+---------+
[*] Subject to network limitations, e.g., ND cache entry size limits. [+] Except on certain networks, e.g., /64 sharing [RFC7278].
[*]受网络限制，例如ND缓存项大小限制。[+]某些网络除外，例如/64共享[RFC7278]。
Table 1: Comparison of Multiple Address Assignment Options
表1：多个地址分配选项的比较
If we itemize the use cases from Section 3, we can estimate the number of addresses currently used in normal operations. In typical implementations, privacy addresses use up to 7 addresses -- one per day ([RFC4941], Section 3.5). Current mobile devices sharing an uplink connection may typically support 8 downstream client devices, with each one requiring one or more addresses. A client might choose to run several virtual machines. Current implementations of 464XLAT require the use of a separate address. Some devices require another address for their baseband chip. Even a host performing just a few of these functions simultaneously might need on the order of 20 addresses at the same time. Future applications designed to use an address per application or even per resource will require many more. These will not function on networks that enforce a hard limit on the number of addresses provided to hosts. Thus, in general it is not possible to estimate in advance how many addresses are required.
如果我们逐条列出第3节中的用例，我们可以估计当前在正常操作中使用的地址数量。在典型的实现中，隐私地址最多使用7个地址——每天一个（[RFC4941]，第3.5节）。共享上行链路连接的当前移动设备通常可以支持8个下游客户端设备，其中每一个都需要一个或多个地址。客户端可能会选择运行多个虚拟机。464XLAT的当前实现需要使用单独的地址。有些设备的基带芯片需要另一个地址。即使一台主机同时执行其中几个功能，也可能需要20个地址。未来设计为每个应用程序甚至每个资源使用地址的应用程序将需要更多的地址。在对提供给主机的地址数量实施硬限制的网络上，这些功能将不起作用。因此，通常不可能预先估计需要多少地址。
In order to avoid the problems described above and preserve the Internet's ability to support new applications that use more than one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts. To support future use cases, it is NOT RECOMMENDED to impose a hard limit on the size of the address pool assigned to a host. Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 address per prefix.
为了避免上述问题并保持Internet支持使用多个IPv6地址的新应用程序的能力，建议IPv6网络部署从每个前缀向通用主机提供多个IPv6地址。为了支持将来的用例，不建议对分配给主机的地址池的大小施加硬限制。特别是，不建议将主机限制为每个前缀只有一个IPv6地址。
Due to the drawbacks imposed by requiring explicit requests for address space (see Section 4), it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests. This can be achieved either by allowing the host to form new addresses autonomously (e.g., via SLAAC) or by providing the host with a dedicated /64 prefix. The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
由于需要显式请求地址空间（参见第4节）带来的缺点，建议网络允许主机在不需要显式请求的情况下使用新地址。这可以通过允许主机自主形成新地址（例如，通过SLAAC）或为主机提供专用/64前缀来实现。前缀可以使用DHCPv6 PD、带有每个设备VLAN的SLAAC或任何其他方式提供。
Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide multiple addresses when the host connects (e.g., the approximately 30 addresses that can fit into a single packet) would accommodate current clients, but it sets a limit on the number of addresses available to hosts when they attach and therefore limits the development of future applications.
当主机连接时，使用有状态地址分配（DHCPv6 IA_NA或IA_TA）提供多个地址（例如，一个数据包中可以容纳的大约30个地址）将容纳当前客户端，但它限制了主机连接时可用的地址数量，因此限制了未来应用程序的开发。
Some network operators -- often operators of networks that provide services to third parties such as university campus networks -- are required to track which IP addresses are assigned to which hosts on their network. Maintaining persistent logs that map user IP addresses and timestamps to hardware identifiers such as MAC addresses may be used to attribute liability for copyright infringement or other illegal activity.
一些网络运营商（通常是向第三方（如大学校园网）提供服务的网络运营商）需要跟踪将哪些IP地址分配给其网络上的哪些主机。维护将用户IP地址和时间戳映射到硬件标识符（如MAC地址）的持久性日志可用于确定版权侵权或其他非法活动的责任。
It is worth noting that this requirement can be met without using DHCPv6 address assignment. For example, it is possible to maintain these mappings by monitoring the IPv6 neighbor table: routers typically allow periodic dumps of the Neighbor Cache via the Simple Network Management Protocol (SNMP) or other means, and many can be configured to log every change to the Neighbor Cache. Using SLAAC with a dedicated /64 prefix for each host simplifies tracking, as it does not require logging every address formed by the host, but only the prefix assigned to the host when it attaches to the network. Similarly, providing address space using DHCPv6 PD has the same tracking properties as DHCPv6 address assignment, but allows the network to provide unrestricted address space.
值得注意的是，无需使用DHCPv6地址分配即可满足此要求。例如，可以通过监视IPv6邻居表来维护这些映射：路由器通常允许通过简单网络管理协议（SNMP）或其他方式定期转储邻居缓存，许多路由器可以配置为记录对邻居缓存的每次更改。为每个主机使用带有专用/64前缀的SLAAC简化了跟踪，因为它不需要记录主机形成的每个地址，只需要记录主机连接到网络时分配给主机的前缀。类似地，使用DHCPv6 PD提供地址空间与DHCPv6地址分配具有相同的跟踪属性，但允许网络提供不受限制的地址空间。
Many large enterprise networks are fully dual stack and implement address monitoring without using or supporting DHCPv6. The authors are directly aware of several networks that operate in this way, including the Universities of Loughborough, Minnesota, Reading, Southampton, and Wisconsin, and Imperial College London, in addition to the enterprise networks of the authors' employers.
许多大型企业网络都是完全双栈的，在不使用或不支持DHCPv6的情况下实现地址监控。作者直接知道有几个网络以这种方式运作，包括明尼苏达州拉夫伯勒大学、雷丁大学、南安普敦大学和威斯康星州大学、伦敦帝国理工学院，以及作者雇主的企业网络。
It should also be noted that using DHCPv6 address assignment does not ensure that the network can reliably track the IPv6 addresses used by hosts. On any shared network without Layer 2 (L2) edge port security, hosts are able to choose their own addresses regardless of what address provisioning methodology the network operator believes is in use. The only way to restrict the addresses used by hosts is to use L2 security mechanisms that enforce that particular IPv6 addresses are used by particular link-layer addresses (for example, Source Address Validation Improvement (SAVI) [RFC7039]). If those mechanisms are available, it is possible to use them to provide tracking; this form of tracking is more secure and reliable than server logs because it operates independently of how addresses are allocated. Finally, tracking address information via DHCPv6 server logs is likely to become decreasingly viable due to ongoing efforts to improve the privacy of DHCPv6 and MAC address randomization [RFC7844].
还应注意，使用DHCPv6地址分配并不能确保网络能够可靠地跟踪主机使用的IPv6地址。在没有第2层（L2）边缘端口安全的任何共享网络上，主机都可以选择自己的地址，而不管网络运营商认为正在使用什么地址供应方法。限制主机使用的地址的唯一方法是使用二级安全机制，强制特定的链路层地址使用特定的IPv6地址（例如，源地址验证改进（SAVI）[RFC7039]）。如果这些机制可用，可以利用它们进行跟踪；这种形式的跟踪比服务器日志更安全可靠，因为它独立于地址的分配方式进行操作。最后，通过DHCPv6服务器日志跟踪地址信息可能变得越来越不可行，因为正在努力改善DHCPv6的隐私和MAC地址随机化[RFC7844]。
In IPv4, all but the world's largest networks can be addressed using private space [RFC1918], with each host receiving one IPv4 address. Many networks can be numbered in 192.168.0.0/16, which has roughly 65 thousand addresses. In IPv6, that is equivalent to a /48, with each host receiving a /64 prefix. Under current Regional Internet Registry (RIR) policies, a /48 is easy to obtain for an enterprise network. Networks that need a bigger block of private space use 10.0.0.0/8, which has roughly 16 million addresses. In IPv6, that is equivalent to a /40, with each host receiving a /64 prefix. Enterprises of such size can easily obtain a /40 under current RIR policies.
在IPv4中，除了世界上最大的网络外，所有网络都可以使用专用空间[RFC1918]寻址，每个主机接收一个IPv4地址。许多网络的编号为192.168.0.0/16，大约有65000个地址。在IPv6中，这相当于a/48，每个主机接收一个/64前缀。根据目前的区域互联网注册（RIR）政策，企业网络很容易获得a/48。需要更大私人空间块的网络使用10.0.0.0/8，大约有1600万个地址。在IPv6中，这相当于a/40，每个主机接收一个/64前缀。在目前的RIR政策下，这种规模的企业可以很容易地获得a/40。
In the above cases, aggregation and routing can be equivalent to IPv4: if a network aggregates per-host IPv4 addresses into prefixes of length /32 - n, it can aggregate per-host /64 prefixes into the same number of prefixes of length /64 - n.
在上述情况下，聚合和路由可以等效于IPv4：如果网络将每个主机的IPv4地址聚合为长度为/32-n的前缀，则可以将每个主机/64前缀聚合为长度为/64-n的相同数量的前缀。
Currently, residential users typically receive one IPv4 address and a /48, /56, or /60 IPv6 prefix. While such networks do not provide enough space to assign a /64 per host, such networks almost universally use SLAAC, and thus do not pose any particular limit to the number of addresses hosts can use.
目前，住宅用户通常会收到一个IPv4地址和/48、/56或/60 IPv6前缀。虽然这样的网络没有提供足够的空间为每个主机分配a/64，但这样的网络几乎普遍使用SLAAC，因此对主机可以使用的地址数量没有任何特定限制。
Unlike IPv4 where addresses came at a premium, in all of these networks there is enough IPv6 address space to supply clients with multiple IPv6 addresses.
与IPv4不同的是，在所有这些网络中，都有足够的IPv6地址空间为客户端提供多个IPv6地址。
The number of IPv6 addresses on a link has a direct impact on networking infrastructure nodes (routers, switches) and other nodes on the link. Setting aside exhaustion attacks via L2 address spoofing, every (L2, IP) address pair impacts networking hardware requirements in terms of memory, Multicast Listener Discovery (MLD) snooping, solicited node multicast groups, etc. Many of these costs are incurred by neighboring hosts.
链路上IPv6地址的数量直接影响到网络基础设施节点（路由器、交换机）和链路上的其他节点。撇开通过L2地址欺骗的耗尽攻击不谈，每个（L2，IP）地址对都会影响网络硬件在内存、多播侦听器发现（MLD）窥探、请求节点多播组等方面的需求。这些成本中的许多都是由相邻主机产生的。
Hosts on such networks that create unreasonable numbers of addresses risk impairing network connectivity for themselves and other hosts on the network, and in extreme cases (e.g., hundreds or thousands of addresses) may even find their network access restricted by denial-of-service protection mechanisms.
此类网络上创建不合理数量地址的主机有可能损害其自身和网络上其他主机的网络连接，在极端情况下（例如，数百或数千个地址），甚至可能发现其网络访问受到拒绝服务保护机制的限制。
We expect these scaling limitations to change over time as hardware and applications evolve. However, switching to a dedicated /64 prefix per host can resolve these scaling limitations. If the prefix
我们预计这些扩展限制会随着硬件和应用程序的发展而改变。但是，每个主机切换到专用/64前缀可以解决这些扩展限制。如果前缀
is provided via DHCPv6 PD, or if the prefix can be used by only one link-layer address (e.g., if the link layer uniquely identifies or authenticates hosts based on MAC addresses), then there will be only one routing entry and one ND cache entry per host on the network. Furthermore, if the host is aware that the prefix is dedicated (e.g., if it was provided via DHCPv6 PD and not SLAAC), it is possible for the host to assign IPv6 addresses from this prefix to an internal virtual interface such as a loopback interface. This obviates the need to perform Neighbor Discovery and Duplicate Address Detection on the network interface for these addresses, reducing network traffic.
通过DHCPv6 PD提供，或者如果前缀只能由一个链路层地址使用（例如，如果链路层根据MAC地址唯一地标识或验证主机），则网络上每个主机将只有一个路由条目和一个ND缓存条目。此外，如果主机知道前缀是专用的（例如，如果它是通过DHCPv6 PD而不是SLAAC提供的），则主机可以将IPv6地址从该前缀分配给内部虚拟接口，例如环回接口。这样就无需在网络接口上为这些地址执行邻居发现和重复地址检测，从而减少了网络流量。
Thus, assigning a dedicated /64 prefix per host is operationally prudent. Clearly, however, it requires more IPv6 address space than using shared links, so the benefits provided must be weighed with the operational overhead of address space management.
因此，为每个主机分配专用/64前缀在操作上是谨慎的。然而，很明显，它需要比使用共享链路更多的IPv6地址空间，因此，所提供的好处必须与地址空间管理的操作开销进行权衡。
As mentioned in Section 9.3, on shared networks using SLAAC, it is possible for hosts to attempt to exhaust network resources and possibly deny service to other hosts by creating unreasonable numbers (e.g., hundreds or thousands) of addresses. Networks that provide access to untrusted hosts can mitigate this threat by providing a dedicated /64 prefix per host. It is also possible to mitigate the threat by limiting the number of ND cache entries that can be created for a particular host, but care must be taken to ensure that the network does not prevent the legitimate use of multiple IP addresses by non-malicious hosts.
如第9.3节所述，在使用SLAAC的共享网络上，主机可能会尝试耗尽网络资源，并可能通过创建不合理的地址数（如数百或数千）来拒绝向其他主机提供服务。提供对不受信任主机的访问的网络可以通过为每个主机提供专用的/64前缀来减轻这种威胁。还可以通过限制可为特定主机创建的ND缓存项的数量来减轻威胁，但必须注意确保网络不会阻止非恶意主机合法使用多个IP地址。
Security issues related to host tracking are discussed in Section 9.1.
第9.1节讨论了与主机跟踪相关的安全问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[ILA] Herbert, T., "Identifier-locator addressing for network virtualization", Work in Progress, draft-herbert-nvo3- ila-02, March 2016.
[ILA]Herbert，T.，“网络虚拟化的标识符定位器寻址”，正在进行的工作，草稿-Herbert-nvo3-ILA-022016年3月。
[IPv6v4] Japan Internet Exchange, "IPv6v4 Exchange Service", April 2013, <http://www.jpix.ad.jp/en/service/ipv6v4.html>.
[IPv6v4]日本互联网交换，“IPv6v4交换服务”，2013年4月<http://www.jpix.ad.jp/en/service/ipv6v4.html>.
[KA] Roskind, J., "Quick UDP Internet Connections", November 2013, <http://www.ietf.org/proceedings/88/slides/ slides-88-tsvarea-10.pdf>.
[KA]Roskind，J.，“快速UDP互联网连接”，2013年11月<http://www.ietf.org/proceedings/88/slides/ 幻灯片-88-tsvarea-10.pdf>。
[L66] McHardy, P., "netfilter: ipv6: add IPv6 NAT support", Linux commit 58a317f1061c894d2344c0b6a18ab4a64b69b815, August 2012, <https://git.kernel.org/cgit/linux/kernel/ git/torvalds/linux.git/commit/ ?id=58a317f1061c894d2344c0b6a18ab4a64b69b815>.
[L66]McHardy，P.，“netfilter:ipv6:添加ipv6 NAT支持”，Linux提交58A317F1061C894D2344C0B6A18AB4A64B69B8152012年8月<https://git.kernel.org/cgit/linux/kernel/ git/torvalds/linux.git/commit/？id=58a317f1061c894d2344c0b6a18ab4a64b69b815>。
[QUIC] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Work in Progress, draft-tsvwg-quic-protocol-02, January 2016.
[QUIC]Hamilton，R.，Iyengar，J.，Swett，I.，和A.Wilk，“QUIC:HTTP/2基于UDP的安全可靠传输”，正在进行的工作，草案-tsvwg-QUIC-protocol-02，2016年1月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, DOI 10.17487/RFC2993, November 2000, <http://www.rfc-editor.org/info/rfc2993>.
[RFC2993]Hain，T，“NAT的建筑含义”，RFC 2993，DOI 10.17487/RFC2993，2000年11月<http://www.rfc-editor.org/info/rfc2993>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，DOI 10.17487/RFC4389，2006年4月<http://www.rfc-editor.org/info/rfc4389>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年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, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, DOI 10.17487/RFC5902, July 2010, <http://www.rfc-editor.org/info/rfc5902>.
[RFC5902]Thaler，D.，Zhang，L.，和G.Lebovitz，“IAB对IPv6网络地址转换的思考”，RFC 5902，DOI 10.17487/RFC5902，2010年7月<http://www.rfc-editor.org/info/rfc5902>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, <http://www.rfc-editor.org/info/rfc6434>.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 6434，DOI 10.17487/RFC6434，2011年12月<http://www.rfc-editor.org/info/rfc6434>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>.
[RFC6459]Korhonen，J.，Ed.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，DOI 10.17487/RFC6459，2012年1月<http://www.rfc-editor.org/info/rfc6459>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，DOI 10.17487/RFC6877，2013年4月<http://www.rfc-editor.org/info/rfc6877>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <http://www.rfc-editor.org/info/rfc7039>.
[RFC7039]Wu，J.，Bi，J.，Bagnulo，M.，Baker，F.，和C.Vogt，Ed.，“源地址验证改进（SAVI）框架”，RFC 7039，DOI 10.17487/RFC7039，2013年10月<http://www.rfc-editor.org/info/rfc7039>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年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, DOI 10.17487/RFC7278, June 2014, <http://www.rfc-editor.org/info/rfc7278>.
[RFC7278]Byrne，C.，Durke，D.，和A.Vizdal，“将IPv6/64前缀从第三代合作伙伴项目（3GPP）移动接口扩展到LAN链路”，RFC 7278，DOI 10.17487/RFC7278，2014年6月<http://www.rfc-editor.org/info/rfc7278>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>.
[RFC7421]Carpenter，B.，Ed.，Chown，T.，Gont，F.，Jiang，S.，Petrescu，A.，和A.Yourtchenko，“IPv6寻址中64位边界的分析”，RFC 7421，DOI 10.17487/RFC7421，2015年1月<http://www.rfc-editor.org/info/rfc7421>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户端的匿名配置文件”，RFC 7844，DOI 10.17487/RFC7844，2016年5月<http://www.rfc-editor.org/info/rfc7844>.
[TARP] Gleitz, PM. and SB. Bellovin, "Transient Addressing for Related Processes: Improved Firewalling by Using IPv6 and Multiple Addresses per Host", In Proceedings of the Eleventh Usenix Security Symposium, August 2001, <https://www.usenix.org/legacy/events/sec01/gleitz.html>.
[TARP]格雷茨，首相。和某人。Bellovin，“相关进程的瞬态寻址：通过使用IPv6和每个主机的多个地址改进防火墙”，发表于第十一届Usenix安全研讨会论文集，2001年8月<https://www.usenix.org/legacy/events/sec01/gleitz.html>.
[TS.24327] 3GPP, "Mobility between 3GPP Wireless Local Area Network (WLAN) interworking (I-WLAN) and 3GPP systems; General Packet Radio System (GPRS) and 3GPP I-WLAN aspects; Stage 3", 3GPP TS 24.327, June 2011, <http://www.3gpp.org/DynaReport/24327.htm>.
[TS.24327]3GPP，“3GPP无线局域网（WLAN）互通（I-WLAN）和3GPP系统之间的移动性；通用分组无线系统（GPRS）和3GPP I-WLAN方面；第3阶段”，3GPP TS 24.327，2011年6月<http://www.3gpp.org/DynaReport/24327.htm>.
[V66] Oracle, "What's New in VirtualBox 4.3?", October 2013, <https://blogs.oracle.com/fatbloke/entry/ what_s_new_in_virtualbox>.
[V66]Oracle，“VirtualBox 4.3有什么新功能？”，2013年10月<https://blogs.oracle.com/fatbloke/entry/ virtualbox>中的新内容。
Acknowledgements
致谢
The authors thank Tore Anderson, Brian Carpenter, David Farmer, Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng (Will) Liu, Shin Miyakawa, Dieter Siegmund, Mark Smith, Sander Steffann, Fred Templin, and James Woodyatt for their input and contributions.
作者感谢Tore Anderson、Brian Carpenter、David Farmer、Wesley George、Geoff Huston、Erik Kline、Victor Kuarsingh、Shucheng（Will）Liu、Shin Miyakawa、Dieter Siegmund、Mark Smith、Sander Steffann、Fred Templin和James Woodyatt的投入和贡献。
Authors' Addresses
作者地址
Lorenzo Colitti Google Roppongi 6-10-1 Minato, Tokyo 106-6126 Japan
洛伦佐·科利蒂谷歌六本木6-10-1日本东京米纳托106-6126
Email: lorenzo@google.com
Email: lorenzo@google.com
Vint Cerf Google 1875 Explorer Street 10th Floor Reston, VA 20190 United States of America
美国弗吉尼亚州雷斯顿探索者街1875号10楼维特塞夫谷歌公司，邮编：20190
Email: vint@google.com
Email: vint@google.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
斯图尔特·柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Email: cheshire@apple.com
Email: cheshire@apple.com
David Schinazi Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
美国加利福尼亚州库珀蒂诺市无限环路1号苹果公司，邮编95014
Email: dschinazi@apple.com
Email: dschinazi@apple.com