Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 8273 Comcast Cable
Category: Informational G. Van de Velde
ISSN: 2070-1721 Nokia
December 2017
Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 8273 Comcast Cable
Category: Informational G. Van de Velde
ISSN: 2070-1721 Nokia
December 2017
Unique IPv6 Prefix per Host
每个主机的唯一IPv6前缀
Abstract
摘要
This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.
本文档概述了一种利用现有IPv6协议允许为主机分配唯一IPv6前缀（而不是共享IPv6前缀中的唯一IPv6地址）的方法。在唯一服务提供商IPv6地址上使用唯一IPv6前缀的好处包括改进主机隔离和增强共享网段上的订户管理。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8273.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8273.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation and Scope of Applicability . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Assignment of IPv6 Unique Prefixes . . . . . . . . . . . . . 4
5. Best Practices for IPv6 Neighbor Discovery . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation and Scope of Applicability . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Assignment of IPv6 Unique Prefixes . . . . . . . . . . . . . 4
5. Best Practices for IPv6 Neighbor Discovery . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The concepts in this document were originally developed as part of a large-scale production deployment of IPv6 support for a provider-managed shared-access network service.
本文档中的概念最初是作为大规模生产部署的一部分开发的，该部署支持由提供商管理的共享访问网络服务的IPv6。
A shared-access network service is a service offering in which a particular Layer 2 (L2) access network (e.g., Wi-Fi) is shared and used by multiple visiting devices (i.e., subscribers). Many service providers offering shared-access network services have legal requirements, or find it good practice, to provide isolation between the connected visitor devices to control potential abuse of the shared-access network.
共享接入网络服务是一种服务产品，其中特定的第2层（L2）接入网络（例如，Wi-Fi）由多个访问设备（例如，用户）共享和使用。许多提供共享接入网络服务的服务提供商都有法律要求，或者认为在连接的访问者设备之间提供隔离以控制共享接入网络的潜在滥用是一种良好的做法。
A network implementing a unique IPv6 prefix per host can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as Duplicate Address Detection (DAD) reply spoofing, Neighbor Discovery (ND) cache exhaustion, malicious redirects, and rogue Router Advertisements (RAs). This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping.
每个主机实现唯一IPv6前缀的网络可以简单地确保设备之间不能发送数据包，除非通过第一跳路由器。这将自动为依赖链路本地ICMPv6数据包的设备之间的攻击提供强健的保护，例如重复地址检测（DAD）应答欺骗、邻居发现（ND）缓存耗尽、恶意重定向和恶意路由器广告（RAs）。这种形式的保护比其他机制（如DAD代理、强制转发或ND窥探）更具可扩展性和健壮性。
In this document IPv6 support does not preclude support for IPv4; however, the primary objective for this work was to make it so that user equipment (UE) were capable of an IPv6-only experience from a network operator's perspective. In the context of this document, UE can be 'regular' end-user equipment as well as a server in a data center, assuming a shared network (wired or wireless) exists.
在本文档中，IPv6支持并不排除对IPv4的支持；然而，这项工作的主要目标是使用户设备（UE）能够从网络运营商的角度获得仅限IPv6的体验。在本文档的上下文中，假设存在共享网络（有线或无线），UE可以是“常规”终端用户设备以及数据中心中的服务器。
Details of IPv4 support are out of scope for this document. This document will also, in general, outline the requirements that must be satisfied by UE to allow for an IPv6-only experience.
IPv4支持的详细信息不在本文档的范围内。一般而言，本文件还将概述UE必须满足的要求，以实现仅限IPv6的体验。
In most current deployments, assignment of UE IPv6 addresses is commonly done using IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] and/or DHCP IA_NA (Identity Association - Non-temporary Address) [RFC3315]. During the time when this approach was developed and subsequently deployed, it was observed that some operating systems did not support the use of DHCPv6 for the acquisition of IA_NA per [RFC7934]. To not exclude any known IPv6 implementations, IPv6-SLAAC-based subscriber and address management is the recommended technology to reach the highest percentage of connected IPv6 devices on a provider-managed shared-access network service. In addition, an IA_NA-only network is not recommended per Section 8 of [RFC7934]. This document will detail the mechanics involved for IPv6-SLAAC-based address and subscriber management coupled with stateless DHCPv6, where beneficial.
在大多数当前部署中，UE IPv6地址的分配通常使用IPv6无状态地址自动配置（SLAAC）[RFC4862]和/或DHCP IA_NA（身份关联-非临时地址）[RFC3315]完成。在开发并随后部署此方法的过程中，观察到一些操作系统不支持使用DHCPv6来获取IA_NA per[RFC7934]。为了不排除任何已知的IPv6实施，建议使用基于IPv6 SLAAC的订户和地址管理技术，以达到提供商管理的共享访问网络服务上连接的IPv6设备的最高百分比。此外，根据[RFC7934]第8节，不建议仅使用IA_NA网络。本文档将详细介绍基于IPv6 SLAAC的地址和订户管理以及无状态DHCPv6（如果有益的话）所涉及的机制。
This document focuses upon the process for UE to obtain a unique IPv6 prefix.
本文档重点介绍UE获取唯一IPv6前缀的过程。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The motivation for this work falls into the following categories:
这项工作的动机分为以下几类：
o Give deployment advice for IPv6 that will allow a stable and secure IPv6-only experience, even if IPv4 support is present
o 为IPv6提供部署建议，以提供稳定、安全的仅限IPv6的体验，即使存在IPv4支持
o Ensure support for IPv6 is efficient and does not impact the performance of the underlying network and, in turn, the customer experience
o 确保对IPv6的支持是高效的，并且不会影响基础网络的性能，进而影响客户体验
o Allow for the greatest flexibility across host implementations to allow for the widest range of addressing and configuration mechanisms to be employed. Ensure that the widest population of UE implementations can leverage the availability of IPv6
o 允许主机实现最大的灵活性，以允许采用最广泛的寻址和配置机制。确保最大数量的UE实现可以利用IPv6的可用性
o Lay the technological foundation for future work related to the use of IPv6 over shared media, requiring optimized subscriber management
o 为IPv6在共享媒体上的使用奠定了技术基础，需要优化的用户管理
o Ensure that two devices (subscriber/hosts), both attached to the same provider-managed shared-access network, should only be able to communicate through the provider-managed first-hop router. Often, service providers have legal requirements, or find it good practice, to provide isolation between the connected visitor devices in order to control potential abuse of the shared-access network.
o 确保连接到同一提供商管理的共享访问网络的两个设备（订户/主机）只能通过提供商管理的第一跳路由器进行通信。通常，服务提供商有法律要求，或者认为这是一种良好的做法，在连接的访问者设备之间提供隔离，以控制共享访问网络的潜在滥用。
o Provide guidelines regarding best common practices around IPv6 ND [RFC4861] and IPv6-address-management settings between the first-hop router and directly connected hosts/subscribers.
o 提供有关第一跳路由器和直接连接的主机/订阅者之间的IPv6 ND[RFC4861]和IPv6地址管理设置的最佳常见做法的指南。
The first-hop router discussed in this document is the L3 Edge router responsible for the communication with the devices (hosts and subscribers) directly connected to a provider-managed shared-access network; it is also responsible for transporting traffic between the directly connected devices and between directly connected devices and remote devices.
本文档中讨论的第一跳路由器是L3边缘路由器，负责与直接连接到提供商管理的共享接入网络的设备（主机和用户）进行通信；它还负责在直接连接的设备之间以及直接连接的设备和远程设备之间传输流量。
The work detailed in this document is focused on providing details regarding best common practices of the IPv6 ND and related IPv6- address-management settings between the first-hop router and directly connected hosts/subscribers. The documented best current practice helps a service provider to better manage the provider-managed shared-access network on behalf of the connected devices.
本文档中详细介绍的工作重点是提供有关第一跳路由器和直接连接的主机/订阅者之间IPv6 ND和相关IPv6地址管理设置的最佳通用实践的详细信息。记录在案的最佳当前实践有助于服务提供商代表连接的设备更好地管理由提供商管理的共享访问网络。
This document recommends providing a unique IPv6 prefix to devices connected to the provider-managed shared-access network. Each unique IPv6 prefix can function as a control-plane anchor point to make sure that each device receives expected subscriber policy and service levels (throughput, QoS, security, parental control, subscriber-mobility management, etc.).
本文档建议为连接到提供商管理的共享访问网络的设备提供唯一的IPv6前缀。每个唯一的IPv6前缀都可以用作控制平面锚定点，以确保每个设备接收到预期的订户策略和服务级别（吞吐量、QoS、安全性、家长控制、订户移动性管理等）。
When a UE connects to the provider-managed shared-access network, it will initiate the IP configuration phase. During this phase, the UE will, from an IPv6 perspective, attempt to learn the default IPv6 gateway, the IPv6 prefix information, the DNS information [RFC8106], and the remaining information required to establish globally routable IPv6 connectivity. For that purpose, the subscriber sends an RS (Router Solicitation) message.
当UE连接到提供商管理的共享接入网络时，它将启动IP配置阶段。在此阶段，UE将从IPv6的角度尝试了解默认IPv6网关、IPv6前缀信息、DNS信息[RFC8106]以及建立全局可路由IPv6连接所需的其余信息。为此，订户发送RS（路由器请求）消息。
The first-hop router receives this subscriber RS message and starts the process of composing the response to the subscriber-originated RS message. The first-hop router will answer using a solicited RA to the subscriber.
第一跳路由器接收此订户RS消息，并开始编写对源自订户的RS消息的响应的过程。第一跳路由器将使用请求的RA应答订户。
When the first-hop router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the unique IPv6 prefix contained in the RA. This is achieved by sending a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in Sections 6.2.4 and 6.2.6 of [RFC4861]; but, instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the unique IPv6 prefix contained in the RA MUST be used as the link-layer destination [RFC6085]. Or, optionally in some cases, a solicited RA response could be sent (unicast) to the link-local address of the subscriber as detailed in Section 6.2.6 of [RFC4861]; nevertheless, unsolicited RAs are always sent to the all-nodes group.
当第一跳路由器发送请求的RA响应或定期发送未经请求的RA时，RA必须仅发送给已分配RA中包含的唯一IPv6前缀的订户。如[RFC4861]第6.2.4节和第6.2.6节所述，这是通过向所有节点组发送请求的RA响应或非请求的RA来实现的；但是，与使用与所有节点组关联的链路层多播地址不同，已分配RA中包含的唯一IPv6前缀的订户的链路层单播地址必须用作链路层目的地[RFC6085]。或者，可选地，在某些情况下，可将请求的RA响应发送（单播）到订户的链路本地地址，如[RFC4861]第6.2.6节所述；然而，未经请求的RAs总是发送到所有节点组。
This solicited RA contains two important parameters for the subscriber to consume: a unique IPv6 prefix (currently a /64 prefix) and some flags. The unique IPv6 prefix can be derived from a locally managed pool or aggregate IPv6 block assigned to the first-hop router or from a centrally allocated pool. The flags indicate that the subscriber should use SLAAC and/or DHCPv6 for address assignment; it may indicate whether the autoconfigured address is on/off-link and if 'Other' information (e.g., DNS server address) needs to be requested.
此请求的RA包含订阅者要使用的两个重要参数：唯一的IPv6前缀（当前为/64前缀）和一些标志。唯一的IPv6前缀可以从本地管理的池或分配给第一跳路由器的聚合IPv6块或从中央分配的池派生。这些标志指示订户应使用SLAAC和/或DHCPv6进行地址分配；它可能指示自动配置的地址是否为开/关链接，以及是否需要请求“其他”信息（例如DNS服务器地址）。
The IPv6 RA flags used for best common practice in IPv6-SLAAC-based provider-managed shared-access networks are:
在基于IPv6 SLAAC的提供商管理的共享访问网络中，用于最佳通用做法的IPv6 RA标志为：
o M-flag = 0 (The subscriber address is not managed through DHCPv6); this flag may be set to 1 in the future if/when DHCPv6-prefix-delegation support is desired.)
o M-flag=0（用户地址不通过DHCPv6管理）；如果/当需要DHCPv6前缀委派支持时，该标志可能在将来设置为1。）
o O-flag = 1 (DHCPv6 is used to request configuration information, i.e., DNS, NTP information, not for IPv6 addressing.)
o O-flag=1（DHCPv6用于请求配置信息，即DNS、NTP信息，而不是IPv6寻址。）
o A-flag = 1 (The subscriber can configure itself using SLAAC.)
o A-flag=1（订阅者可以使用SLAAC配置自身。）
o L-flag = 0 (The prefix is not an on-link prefix, which means that the subscriber will never assume destination addresses that match the prefix are on-link and will always send packets to those addresses to the appropriate gateway according to route selection rules.)
o L-flag=0（前缀不是链路上前缀，这意味着订阅者永远不会假定与前缀匹配的目的地地址在链路上，并且将始终根据路由选择规则将数据包发送到这些地址到适当的网关。）
The use of a unique IPv6 prefix per subscriber adds an additional level of protection and efficiency. The protection exists because all external communication of a connected device is directed to the first-hop router as required by [RFC4861]. Best efficiency is achieved because the recommended RA flags allow the broadest support on connected devices to receive a valid IPv6 address (i.e., privacy addresses [RFC4941] or SLAAC [RFC4862]).
每个订户使用唯一的IPv6前缀可增加额外的保护级别和效率。保护之所以存在，是因为连接设备的所有外部通信都按照[RFC4861]的要求定向到第一跳路由器。由于推荐的RA标志允许连接设备上最广泛的支持来接收有效的IPv6地址（即隐私地址[RFC4941]或SLAAC[RFC4862]），因此实现了最佳效率。
The architected result of designing the RA as documented above is that each subscriber gets its own unique IPv6 prefix. Each host can consequently use SLAAC or any other method of choice to select its /128 unique address. Either stateless DHCPv6 [RFC3736] or IPv6 Router Advertisement Options for DNS Configuration [RFC8106] can be used to get the IPv6 address of the DNS server. If the subscriber desires to send anything external, including towards other subscriber devices (assuming device-to-device communications is enabled and supported), then, due to the L-bit being unset, [RFC4861] requires that this traffic be sent to the first-hop router.
如上所述设计RA的架构结果是，每个订阅者都有自己唯一的IPv6前缀。因此，每个主机都可以使用SLAAC或任何其他选择的方法来选择其/128唯一地址。DNS配置的无状态DHCPv6[RFC3736]或IPv6路由器播发选项[RFC8106]可用于获取DNS服务器的IPv6地址。如果用户希望发送任何外部信息，包括向其他用户设备发送信息（假设启用并支持设备间通信），则由于L位未设置，[RFC4861]要求将该通信发送到第一跳路由器。
After the subscriber received the RA and the associated flags, it will assign itself a 128-bit IPv6 address using SLAAC. Since the address is composed by the subscriber device itself, it will need to verify that the address is unique on the shared network. The subscriber will, for that purpose, perform the DAD algorithm. This will occur for each address the UE attempts to utilize on the provider-managed shared-access network.
订户收到RA和相关标志后，将使用SLAAC为自己分配一个128位IPv6地址。由于地址由订户设备本身组成，因此需要验证该地址在共享网络上是否唯一。为此，订户将执行DAD算法。这将针对UE试图在提供商管理的共享接入网络上利用的每个地址发生。
An operational consideration when using IPv6-address assignment with IPv6 SLAAC is that after the onboarding procedure, the subscriber will have a prefix with certain preferred and valid lifetimes. The first-hop router extends these lifetimes by sending an unsolicited RA, the applicable MaxRtrAdvInterval on the first-hop router MUST, therefore, be lower than the preferred lifetime. One consequence of this process is that the first-hop router never knows when a subscriber stops using addresses from a prefix, and additional procedures are required to help the first-hop router to gain this information. When using stateful DHCPv6 IA_NA for IPv6-subscriber-address assignment, this uncertainty on the first-hop router does not have an impact due to the stateful nature of the assignment of DHCPv6 IA_NA addresses.
在IPv6 SLAAC中使用IPv6地址分配时的一个操作注意事项是，在登录过程之后，订户将具有具有特定首选和有效生存期的前缀。第一跳路由器通过发送未经请求的RA来延长这些生存期，因此，第一跳路由器上适用的MaxRtrAdvInterval必须低于首选生存期。该过程的一个结果是，第一跳路由器永远不知道订户何时停止使用前缀中的地址，并且需要额外的过程来帮助第一跳路由器获得该信息。当使用有状态DHCPv6 IA_NA进行IPv6订户地址分配时，由于DHCPv6 IA_NA地址分配的有状态性质，第一跳路由器上的这种不确定性不会产生影响。
The following is a reference table of the key IPv6 router and neighbor discovery timers for provider-managed shared-access networks:
以下是提供商管理的共享访问网络的关键IPv6路由器和邻居发现计时器的参考表：
o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = 300 s (or when battery consumption is a concern 686 s, see note below)
o 最大IPv6路由器播发间隔（MaxRtrAdvInterval）=300秒（或当电池消耗为686秒时，请参见下面的注释）
o IPv6 Router Lifetime = 3600 s (see note below)
o IPv6路由器生存期=3600秒（参见下面的注释）
o Reachable time = 30 s
o 可达时间=30秒
o IPv6 Valid Lifetime = 3600 s
o IPv6有效生存期=3600秒
o IPv6 Preferred Lifetime = 1800 s
o IPv6首选生存期=1800秒
o Retransmit timer = 0 s
o 重传计时器=0秒
Note: When servicing large numbers of battery powered devices, [RFC7772] suggests a maximum of seven RAs per hour and a 45-90 minute IPv6 Router Lifetime. To achieve a maximum of seven RAs per hour, the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is the important parameter, and it MUST be greater than or equal to 514 seconds (1/7 of an hour). Further, as discussed in Section 6.2.1. of [RFC4861], MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval; therefore, MaxRtrAdvInterval MUST additionally be greater than or equal to 686 seconds. As for the recommended IPv6 Router Lifetime, since this technique requires that RAs be sent using the link-layer unicast address of the subscriber, the concerns over multicast delivery discussed in [RFC7772] are already mitigated; therefore, the above suggestion of 3600 seconds (an hour) seems sufficient for this use case.
注意：在为大量电池供电的设备提供服务时，[RFC7772]建议每小时最多7个RAs，IPv6路由器寿命为45-90分钟。要实现每小时最多7个RAs，最小IPv6路由器播发间隔（MinRtrAdvInterval）是一个重要参数，它必须大于或等于514秒（1/7小时）。此外，如第6.2.1节所述。在[RFC4861]中，MinRtrAdvInterval<=0.75*MaxRtrAdvInterval；因此，MaxRtrAdvInterval还必须大于或等于686秒。至于建议的IPv6路由器生存期，由于该技术要求使用订户的链路层单播地址发送RAs，因此[RFC7772]中讨论的多播交付问题已经得到缓解；因此，上述3600秒（一小时）的建议对于这个用例来说似乎足够了。
IPv6 SLAAC requires the router to maintain neighbor state, which implies costs in terms of memory, power, message exchanges, and message processing. Stale entries can prove an unnecessary burden, especially on Wi-Fi interfaces. It is RECOMMENDED that stale neighbor state be removed quickly.
IPv6 SLAAC要求路由器保持邻居状态，这意味着内存、电源、消息交换和消息处理方面的成本。过时的条目可能会带来不必要的负担，尤其是在Wi-Fi接口上。建议快速删除过时的邻居状态。
When employing stateless IPv6 address assignment, a number of widely deployed operating systems will attempt to utilize [RFC4941] temporary 'private' addresses.
当采用无状态IPv6地址分配时，许多广泛部署的操作系统将尝试使用[RFC4941]临时“专用”地址。
Similarly, when using this technology in a data center, the UE server may need to use several addresses from the same unique IPv6 prefix, for example, because is using multiple virtual hosts, containers, etc., in the bridged-virtual switch. This can lead to the
类似地，当在数据中心中使用该技术时，UE服务器可能需要使用来自相同唯一IPv6前缀的多个地址，例如，因为在桥接虚拟交换机中使用多个虚拟主机、容器等。这可能导致
consequence that a UE has multiple /128 addresses from the same IPv6 prefix. The first-hop router MUST be able to handle the presence and use of multiple globally routable IPv6 addresses.
结果是UE具有来自同一IPv6前缀的多个/128地址。第一跳路由器必须能够处理多个全局可路由IPv6地址的存在和使用。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The mechanics of IPv6 privacy extensions [RFC4941] are compatible with assignment of a unique IPv6 prefix per host. However, when combining both IPv6 privacy extensions and a unique IPv6 prefix per host, a reduced privacy experience for the subscriber is introduced. This is because a prefix may be associated with a subscriber, even when the subscriber has implemented IPv6 privacy extensions [RFC4941]. If the operator assigns the same unique prefix to the same link-layer address every time a host connects, any remote party who is aware of this fact can easily track a host simply by tracking its assigned prefix. This nullifies the benefit provided by privacy addresses [RFC4941]. If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.
IPv6隐私扩展机制[RFC4941]与为每个主机分配唯一的IPv6前缀兼容。但是，当结合IPv6隐私扩展和每个主机的唯一IPv6前缀时，会减少订阅者的隐私体验。这是因为前缀可能与订户关联，即使订户已实现IPv6隐私扩展[RFC4941]。如果运营商在每次主机连接时都将相同的唯一前缀分配给相同的链路层地址，则知道这一事实的任何远程方都可以通过跟踪其分配的前缀轻松地跟踪主机。这使隐私地址[RFC4941]提供的好处无效。如果主机希望在此类网络上维护隐私，则应确保其链路层地址定期更改或随机化。
No other additional security considerations are made in this document.
本文件中没有其他安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc3315>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004, <https://www.rfc-editor.org/info/rfc3736>.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，DOI 10.17487/RFC3736，2004年4月<https://www.rfc-editor.org/info/rfc3736>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<https://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, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<https://www.rfc-editor.org/info/rfc4941>.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, DOI 10.17487/RFC6085, January 2011, <https://www.rfc-editor.org/info/rfc6085>.
[RFC6085]Gundavelli，S.，Townsley，M.，Troan，O.，和W.Dec，“以太网上IPv6多播数据包的地址映射”，RFC 6085，DOI 10.17487/RFC6085，2011年1月<https://www.rfc-editor.org/info/rfc6085>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772]Yourtchenko，A.和L.Coletti，“降低路由器广告的能耗”，BCP 202，RFC 7772，DOI 10.17487/RFC7772，2016年2月<https://www.rfc-editor.org/info/rfc7772>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.
[RFC7934]Coletti，L.，Cerf，V.，Cheshire，S.，和D.Schinazi，“主机地址可用性建议”，BCP 204，RFC 7934，DOI 10.17487/RFC79342016年7月<https://www.rfc-editor.org/info/rfc7934>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 8106，DOI 10.17487/RFC8106，2017年3月<https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
致谢
The authors would like to explicitly thank David Farmer and Lorenzo Colitti for their extended contributions and suggested text.
作者要明确感谢David Farmer和Lorenzo Coletti的长期贡献和建议文本。
In addition, the authors would like to thank the following, in alphabetical order, for their contributions:
此外，作者谨按字母顺序感谢以下各方的贡献：
Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Killian Desmedt, Wim Henderickx, Brad Hilgenfeld, Erik Kline, Suresh Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, and Sanjay Wadhwa
弗雷德·贝克、本·坎贝尔、布赖恩·卡彭特、蒂姆·周恩、基利安·德斯米德、维姆·亨德里克斯、布拉德·希尔根菲尔德、埃里克·克莱恩、苏雷什·克里希南、沃伦·库马里、托马斯·林恩、乔迪·帕莱特、菲尔·桑德森、科琳·西曼尼克、金美·塔图亚、埃里克·温克和桑杰·瓦德瓦
Authors' Addresses
作者地址
John Jason Brzozowski Comcast Cable 1701 John F. Kennedy Blvd. Philadelphia, PA United States of America
约翰·杰森·布尔佐夫斯基康卡斯特电缆1701约翰·F·肯尼迪大道。美利坚合众国宾夕法尼亚州费城
Email: john_brzozowski@cable.comcast.com
Email: john_brzozowski@cable.comcast.com
Gunter Van de Velde Nokia Antwerp Belgium
比利时安特卫普Gunter Van de Velde诺基亚
Email: gunter.van_de_velde@nokia.com
Email: gunter.van_de_velde@nokia.com