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




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.


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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.


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.


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.


1.1. Requirements Language
1.1. 需求语言

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].


2. Common IPv6 Deployment Model
2. 通用IPv6部署模型

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].


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].


3. Benefits of Providing Multiple Addresses
3. 提供多个地址的好处

Today, there are many host functions that require more than one IP address to be available to the host, including:


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节)。

4. Problems with Restricting the Number of Addresses per Host
4. 限制每个主机的地址数时出现的问题

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:


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时所做的那样),则通过对每个设备收费来产生额外收入的尝试可能会适得其反,这不会带来额外收入,但会导致更多的运营问题和更高的支持成本。

5. Overcoming Limits Using Network Address Translation
5. 利用网络地址转换克服限制

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.


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.


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.


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.


6. Options for Providing More Than One Address
6. 提供多个地址的选项

Multiple IPv6 addresses can be provided in the following ways:


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.


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].


Table 1: Comparison of Multiple Address Assignment Options


7. Number of Addresses Required
7. 所需地址数

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.


8. Recommendations
8. 建议

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.


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个地址)将容纳当前客户端,但它限制了主机连接时可用的地址数量,因此限制了未来应用程序的开发。

9. Operational Considerations
9. 业务考虑
9.1. Host Tracking
9.1. 主机跟踪

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.


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.


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].


9.2. Address Space Management
9.2. 地址空间管理

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, 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, 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.


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.


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.


9.3. Addressing Link-Layer Scalability Issues via IP Routing
9.3. 通过IP路由解决链路层可伸缩性问题

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.


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


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.


10. Security Considerations
10. 安全考虑

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.


Security issues related to host tracking are discussed in Section 9.1.


11. References
11. 工具书类
11.1. Normative References
11.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<>.

11.2. Informative References
11.2. 资料性引用

[ILA] Herbert, T., "Identifier-locator addressing for network virtualization", Work in Progress, draft-herbert-nvo3- ila-02, March 2016.


[IPv6v4] Japan Internet Exchange, "IPv6v4 Exchange Service", April 2013, <>.


[KA] Roskind, J., "Quick UDP Internet Connections", November 2013, < slides-88-tsvarea-10.pdf>.

[KA]Roskind,J.,“快速UDP互联网连接”,2013年11月< 幻灯片-88-tsvarea-10.pdf>。

[L66] McHardy, P., "netfilter: ipv6: add IPv6 NAT support", Linux commit 58a317f1061c894d2344c0b6a18ab4a64b69b815, August 2012, < git/torvalds/linux.git/commit/ ?id=58a317f1061c894d2344c0b6a18ab4a64b69b815>.

[L66]McHardy,P.,“netfilter:ipv6:添加ipv6 NAT支持”,Linux提交58A317F1061C894D2344C0B6A18AB4A64B69B8152012年8月< 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.


[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, <>.

[RFC1918]Rekhter,Y.,Moskowitz,B.,Karrenberg,D.,de Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,DOI 10.17487/RFC1918,1996年2月<>.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <>.

[RFC2460]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,RFC 2460,DOI 10.17487/RFC2460,1998年12月<>.

[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, DOI 10.17487/RFC2993, November 2000, <>.

[RFC2993]Hain,T,“NAT的建筑含义”,RFC 2993,DOI 10.17487/RFC2993,2000年11月<>.

[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, <>.

[RFC3315]Droms,R.,Ed.,Bound,J.,Volz,B.,Lemon,T.,Perkins,C.,和M.Carney,“IPv6的动态主机配置协议(DHCPv6)”,RFC 3315,DOI 10.17487/RFC3315,2003年7月<>.

[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, <>.

[RFC3633]Troan,O.和R.Droms,“动态主机配置协议(DHCP)版本6的IPv6前缀选项”,RFC 3633,DOI 10.17487/RFC3633,2003年12月<>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <>.

[RFC4291]Hinden,R.和S.Deering,“IP版本6寻址体系结构”,RFC 4291,DOI 10.17487/RFC42912006年2月<>.

[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <>.

[RFC4389]Thaler,D.,Talwar,M.,和C.Patel,“邻居发现代理(ND代理)”,RFC 4389,DOI 10.17487/RFC4389,2006年4月<>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <>.

[RFC4862]Thomson,S.,Narten,T.和T.Jinmei,“IPv6无状态地址自动配置”,RFC 4862,DOI 10.17487/RFC4862,2007年9月<>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <>.

[RFC4941]Narten,T.,Draves,R.,和S.Krishnan,“IPv6中无状态地址自动配置的隐私扩展”,RFC 4941,DOI 10.17487/RFC49411907年9月<>.

[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, DOI 10.17487/RFC5902, July 2010, <>.

[RFC5902]Thaler,D.,Zhang,L.,和G.Lebovitz,“IAB对IPv6网络地址转换的思考”,RFC 5902,DOI 10.17487/RFC5902,2010年7月<>.

[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, <>.

[RFC6434]Jankiewicz,E.,Loughney,J.和T.Narten,“IPv6节点要求”,RFC 6434,DOI 10.17487/RFC6434,2011年12月<>.

[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, <>.

[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月<>.

[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <>.

[RFC6877]Mawatari,M.,Kawashima,M.,和C.Byrne,“464XLAT:有状态和无状态翻译的组合”,RFC 6877,DOI 10.17487/RFC6877,2013年4月<>.

[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, <>.

[RFC7039]Wu,J.,Bi,J.,Bagnulo,M.,Baker,F.,和C.Vogt,Ed.,“源地址验证改进(SAVI)框架”,RFC 7039,DOI 10.17487/RFC7039,2013年10月<>.

[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, <>.

[RFC7217]Gont,F.“使用IPv6无状态地址自动配置(SLAAC)生成语义不透明接口标识符的方法”,RFC 7217,DOI 10.17487/RFC72172014年4月<>.

[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, <>.

[RFC7278]Byrne,C.,Durke,D.,和A.Vizdal,“将IPv6/64前缀从第三代合作伙伴项目(3GPP)移动接口扩展到LAN链路”,RFC 7278,DOI 10.17487/RFC7278,2014年6月<>.

[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, <>.

[RFC7421]Carpenter,B.,Ed.,Chown,T.,Gont,F.,Jiang,S.,Petrescu,A.,和A.Yourtchenko,“IPv6寻址中64位边界的分析”,RFC 7421,DOI 10.17487/RFC7421,2015年1月<>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <>.

[RFC7844]Huitema,C.,Mrugalski,T.,和S.Krishnan,“DHCP客户端的匿名配置文件”,RFC 7844,DOI 10.17487/RFC7844,2016年5月<>.

[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, <>.


[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, <>.

[TS.24327]3GPP,“3GPP无线局域网(WLAN)互通(I-WLAN)和3GPP系统之间的移动性;通用分组无线系统(GPRS)和3GPP I-WLAN方面;第3阶段”,3GPP TS 24.327,2011年6月<>.

[V66] Oracle, "What's New in VirtualBox 4.3?", October 2013, < what_s_new_in_virtualbox>.

[V66]Oracle,“VirtualBox 4.3有什么新功能?”,2013年10月< virtualbox>中的新内容。



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



Vint Cerf Google 1875 Explorer Street 10th Floor Reston, VA 20190 United States of America



Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America



David Schinazi Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America