Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 6853 Comcast Cable Communications
BCP: 180 J. Tremblay
Category: Best Current Practice Videotron G.P.
ISSN: 2070-1721 J. Chen
Time Warner Cable
T. Mrugalski
ISC
February 2013
Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 6853 Comcast Cable Communications
BCP: 180 J. Tremblay
Category: Best Current Practice Videotron G.P.
ISSN: 2070-1721 J. Chen
Time Warner Cable
T. Mrugalski
ISC
February 2013
DHCPv6 Redundancy Deployment Considerations
DHCPv6冗余部署注意事项
Abstract
摘要
This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.
本文档为希望使用DHCPv6支持IPv6部署的用户提供信息。特别是，它讨论了半冗余DHCPv6服务的提供。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6853.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6853.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 2
2.1. Applicability to Prefix Delegation . . . . . . . . . . . . 3
3. Service Provider Deployment . . . . . . . . . . . . . . . . . 3
4. Enterprise Deployment . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
5.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5
5.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5
5.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 5
6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8
6.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
7. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 2
2.1. Applicability to Prefix Delegation . . . . . . . . . . . . 3
3. Service Provider Deployment . . . . . . . . . . . . . . . . . 3
4. Enterprise Deployment . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
5.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5
5.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5
5.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 5
6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8
6.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10
7. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Redundancy and high availability for many components of IPv6 infrastructure are desirable and, in some deployments, mandatory. Unfortunately, for DHCPv6 there is currently no standards-based failover or redundancy protocol. An interim solution is to provide semi-redundant services: this document specifies an architecture by which this can be achieved.
IPv6基础架构的许多组件都需要冗余和高可用性，而且在某些部署中是强制性的。不幸的是，对于DHCPv6，目前没有基于标准的故障切换或冗余协议。一个临时解决方案是提供半冗余服务：本文档指定了一个体系结构，通过该体系结构可以实现这一点。
DHCPv6 redundancy may be useful in a wide range of scenarios. Although the architecture suggested in this document is able to be used in a wide range of networks, just two deployment environments are discussed here: service provider and enterprise network. All other scenarios may be generalized to one of these two cases.
DHCPv6冗余在很多情况下都很有用。尽管本文档中建议的体系结构能够在广泛的网络中使用，但这里只讨论两种部署环境：服务提供商和企业网络。所有其他情况可概括为这两种情况之一。
In the rest of the document, the following assumptions are made with regards to the existing DHCPv6 infrastructure, regardless of the environment being considered:
在本文档的其余部分中，对现有DHCPv6基础设施进行了以下假设，而不考虑所考虑的环境：
1. At least two DHCPv6 servers provide a service to the same clients. (The architecture does not limit the number of servers, and more may be provided if required.)
1. 至少有两台DHCPv6服务器向相同的客户端提供服务。（该体系结构不限制服务器的数量，如果需要，可以提供更多服务器。）
2. The existing DHCPv6 servers will not directly communicate or interact with one another in the assignment of IPv6 addresses and the provision of configuration information to requesting clients.
2. 现有的DHCPv6服务器在分配IPv6地址和向请求客户端提供配置信息时不会直接通信或交互。
3. DHCPv6 clients are instructed to run stateful DHCPv6 to request at least one IPv6 address. Configuration information and other options (such as a delegated IPv6 prefix) may also be requested as part of the stateful DHCPv6 operation.
3. DHCPv6客户端被指示运行有状态DHCPv6以请求至少一个IPv6地址。作为有状态DHCPv6操作的一部分，还可以请求配置信息和其他选项（例如委派的IPv6前缀）。
4. Clients participating in DHCPv6 configuration have to properly handle the preference option, including the processing of ADVERTISE messages as required by [RFC3315].
4. 参与DHCPv6配置的客户端必须正确处理首选项选项，包括按照[RFC3315]的要求处理播发消息。
5. A DHCPv6 server failure does not imply a failure of any other network service or protocol (e.g., TFTP servers). The redundancy of any additional services configured by means of DHCPv6 are outside the scope of this document. (For example, a single DHCPv6 server may configure multiple TFTP servers, with preference for each TFTP server, as specified in [RFC5970].)
5. DHCPv6服务器故障并不意味着任何其他网络服务或协议（如TFTP服务器）出现故障。通过DHCPv6配置的任何附加服务的冗余不在本文档的范围内。（例如，一台DHCPv6服务器可以配置多个TFTP服务器，每个TFTP服务器都有优先权，如[RFC5970]中所述。）
While the techniques described in this document provide some aspects of redundancy, it should be noted that complete redundancy will not be available until a DHCPv6 failover protocol is standardized. The requirements for such a protocol are described in [FAILREQ].
虽然本文档中描述的技术提供了冗余的一些方面，但应注意，在DHCPv6故障切换协议标准化之前，完全冗余将不可用。[FAILREQ]中描述了此类协议的要求。
The same approaches discussed in this document can potentially be applied to prefix delegation (PD) [RFC3633]. One obvious drawback of using a split prefix model for PD is that use of resources is doubled. It should be noted that such applicability remains theoretical and was not investigated thoroughly during work on this document. As such, the applicability of presented mechanisms to the prefix delegation is outside of the scope of this document.
本文档中讨论的相同方法可能适用于前缀委派（PD）[RFC3633]。对PD使用分割前缀模型的一个明显缺点是资源的使用增加了一倍。应注意的是，此类适用性仍然是理论性的，在编写本文件的过程中未进行彻底调查。因此，所提出的机制对前缀授权的适用性不在本文件的范围之内。
The service provider model represents cases where the network and end-user devices may be administered by separate entities.
服务提供商模型表示网络和最终用户设备可由单独实体管理的情况。
The DHCPv6 clients include cable modems, customer gateways or home routers, and end-user devices: these are collectively referred to as Customer Premises Equipment (CPE). In some cases hosts may be configured directly using the service provider DHCPv6 infrastructure; in others, configuration may be via an intermediate router that is being configured by the provider DHCPv6 infrastructure. Either way, the service provider DHCPv6 infrastructure may be semi-redundant.
DHCPv6客户端包括有线调制解调器、客户网关或家庭路由器以及最终用户设备：这些统称为客户场所设备（CPE）。在某些情况下，可以使用服务提供商DHCPv6基础设施直接配置主机；在其他情况下，可以通过提供者DHCPv6基础设施正在配置的中间路由器进行配置。无论哪种方式，服务提供商DHCPv6基础设施都可能是半冗余的。
In discussing this environment, additional assumptions to those listed in Section 2 have been made:
在讨论这种环境时，对第2节中列出的假设进行了补充：
1. The service provider edge routers and access routers are IPv6 enabled when required. These routers are, for example, CMTS (Cable Modem Termination System) for cable or DSLAM/BRAS (Digital Subscriber Link Access Multiplexer / Broadband Remote Access Server) for DSL.
1. 服务提供商边缘路由器和访问路由器在需要时启用IPv6。例如，这些路由器是用于电缆的CMT（电缆调制解调器终端系统）或用于DSL的DSLAM/BRAS（数字用户链路接入多路复用器/宽带远程接入服务器）。
2. CPE devices are instructed to perform stateful DHCPv6 to request at least one IPv6 address, delegated prefix, and/or configuration information. CPE devices may also be instructed to use stateless DHCPv6 [RFC3736] to acquire configuration information only, a situation that assumes the IPv6 address and prefix information has been acquired using other means.
2. 指示CPE设备执行有状态DHCPv6以请求至少一个IPv6地址、委派前缀和/或配置信息。还可以指示CPE设备使用无状态DHCPv6[RFC3736]仅获取配置信息，这种情况假定已经使用其他手段获取了IPv6地址和前缀信息。
3. The primary application of this architecture is for native IPv6 services. (Use and applicability to transition mechanisms are out of scope for this document.)
3. 此体系结构的主要应用程序用于本机IPv6服务。（过渡机制的使用和适用性超出本文件的范围。）
4. The CPE devices must implement a stateful DHCPv6 client [RFC3315]. Support for DHCPv6 prefix delegation [RFC3633] or stateless DHCPv6 [RFC3736] may also be implemented.
4. CPE设备必须实现有状态DHCPv6客户端[RFC3315]。还可以实现对DHCPv6前缀委托[RFC3633]或无状态DHCPv6[RFC3736]的支持。
The enterprise deployment environment covers cases where end-user devices are direct consumers of the configuration provided by the DHCP servers without any intermediate devices (as was the case with home routers used in the service provider environment). Although enterprise IPv6 environments quite often use or require DHCPv6 relay agents, the relays do not influence or process the configuration in any way and merely act as a transport mechanism.
enterprise deployment environment涵盖最终用户设备是DHCP服务器提供的配置的直接消费者，而没有任何中间设备的情况（服务提供商环境中使用的家庭路由器就是这种情况）。尽管企业IPv6环境经常使用或需要DHCPv6中继代理，但中继不会以任何方式影响或处理配置，而只是充当传输机制。
The additional assumptions made for this model beyond those listed in Section 2 are:
除第2节所列假设外，本模型的其他假设如下：
1. DHCPv6 clients are hosts and are considered end nodes, i.e., they consume provided configuration and do not use it to provision other devices. Examples of such clients include desktop computers, laptops, printers, other typical office equipment, and some mobile devices.
1. DHCPv6客户端是主机，被视为终端节点，即，它们使用提供的配置，而不使用它来配置其他设备。此类客户机的示例包括台式计算机、笔记本电脑、打印机、其他典型办公设备和一些移动设备。
2. The DHCPv6 clients generally do not require the assignment of an IPv6 prefix delegation, and as such they typically do not support DHCPv6 prefix delegation [RFC3633].
2. DHCPv6客户端通常不需要分配IPv6前缀委派，因此它们通常不支持DHCPv6前缀委派[RFC3633]。
Implementation of the architecture for semi-redundant DHCPv6 services using existing protocols requires the component DHCPv6 clients, relays, and servers to have certain capabilities. The following sections describe the requirements of such devices.
使用现有协议实现半冗余DHCPv6服务的体系结构需要组件DHCPv6客户端、中继和服务器具有某些功能。以下章节描述了此类装置的要求。
This interim architecture requires the DHCPv6 servers that are [RFC3315] compliant and support the necessary options. Support for stateful DHCPv6 and the DHCPv6 preference option [RFC3315] is essential to the architecture. For deployment scenarios where IPv6 prefix delegation is needed, DHCPv6 servers must support DHCPv6 prefix delegation as defined by [RFC3633]. Furthermore, the DHCPv6 servers must support [RFC3736] if stateless DHCPv6 is used.
这种临时架构需要符合[RFC3315]标准并支持必要选项的DHCPv6服务器。对有状态DHCPv6和DHCPv6首选项[RFC3315]的支持对体系结构至关重要。对于需要IPv6前缀委派的部署场景，DHCPv6服务器必须支持[RFC3633]定义的DHCPv6前缀委派。此外，如果使用无状态DHCPv6，DHCPv6服务器必须支持[RFC3736]。
DHCPv6 relay agents must be [RFC3315] compliant and must support the ability to relay DHCPv6 messages to more than one destination.
DHCPv6中继代理必须符合[RFC3315]，并且必须支持将DHCPv6消息中继到多个目标的能力。
DHCPv6 clients are required to be compliant with [RFC3315] and support the necessary options required to support the solution depending on the mode of operations and desired behavior:
DHCPv6客户端需要符合[RFC3315]，并支持支持支持解决方案所需的必要选项，具体取决于操作模式和所需行为：
o If prefix delegation is required, DHCPv6 clients must support DHCPv6 prefix delegation as defined in [RFC3633].
o 如果需要前缀委派，DHCPv6客户端必须支持[RFC3633]中定义的DHCPv6前缀委派。
o Clients must support the acquisition of at least one IPv6 address and configuration information using stateful DHCPv6 as specified by [RFC3315].
o 客户端必须支持使用[RFC3315]指定的有状态DHCPv6获取至少一个IPv6地址和配置信息。
o Stateless DHCPv6 [RFC3736] may also be supported.
o 也可能支持无状态DHCPv6[RFC3736]。
o DHCPv6 clients must recognize and adhere to the processing of the advertised DHCPv6 preference option sent by the DHCPv6 servers.
o DHCPv6客户端必须识别并遵守DHCPv6服务器发送的播发DHCPv6首选项选项的处理。
At the time of writing, a standards-based DHCPv6 redundancy protocol is not available. In the interim solution presented here, existing DHCPv6 server implementations are used as-is to provide best effort, semi-redundant DHCPv6 services. The behavior of these services will, in part, be governed by the configuration of each of the servers. Various aspects of the DHCPv6 protocol [RFC3315] are used to yield the desired behavior, although there is no inter-server or inter-process communication to coordinate DHCPv6 events and/or activities.
在撰写本文时，基于标准的DHCPv6冗余协议不可用。在这里介绍的临时解决方案中，现有的DHCPv6服务器实现按原样使用，以提供尽力而为的半冗余DHCPv6服务。这些服务的行为将在一定程度上由每个服务器的配置控制。尽管没有服务器间或进程间通信来协调DHCPv6事件和/或活动，但DHCPv6协议[RFC3315]的各个方面用于产生所需的行为。
The solution does not impact DHCPv4, so DHCP services for both IPv4 and IPv6 may operate simultaneously on the same physical server(s) or may operate on different ones.
该解决方案不会影响DHCPv4，因此IPv4和IPv6的DHCP服务可以在同一个物理服务器上同时运行，也可以在不同的物理服务器上运行。
This section defines three semi-redundant models. Although /64 prefixes are used throughout the following sections as examples, other prefix lengths may be used as well.
本节定义了三个半冗余模型。尽管在以下各节中使用/64前缀作为示例，但也可以使用其他前缀长度。
In the split prefixes model, each DHCPv6 server is configured with a unique, non-overlapping pool derived from the /64 prefix deployed for use within an IPv6 network. For example, distributing an allocated /64 such as 2001:db8:1:1::/64 between two servers would require that it be split into two /65 pools, 2001:db8:1:1:0000::/65 and 2001:db8: 1:1:8000::/65.
在拆分前缀模型中，每个DHCPv6服务器都配置了一个唯一的、不重叠的池，该池派生自部署用于IPv6网络的/64前缀。例如，在两台服务器之间分发已分配的/64（如2001:db8:1:1:：/64）需要将其拆分为两个/65池，即2001:db8:1:1:0000:：/65和2001:db8:1:8000:：/65。
Both DHCPv6 servers are simultaneously active and operational, and each allocates IPv6 addresses from the corresponding pools per device class. The address allocation is governed largely through the use of the DHCPv6 preference option, so the server with the higher preference value is always preferred. Additional proprietary mechanisms can be used to further enforce the favoring of one DHCP server over another. An example of such a scenario is presented in Figure 1.
两台DHCPv6服务器同时处于活动和运行状态，并且每台服务器都从每个设备类的相应池中分配IPv6地址。地址分配主要通过使用DHCPv6首选项选项进行管理，因此首选首选项值较高的服务器。可以使用其他专有机制来进一步强制一个DHCP服务器优于另一个。图1给出了这样一个场景的示例。
It is important to note that, over time, it is possible that bindings will be unevenly distributed amongst the DHCPv6 servers, and no one server will be authoritative for all of them.
需要注意的是，随着时间的推移，绑定可能会在DHCPv6服务器之间分布不均，并且没有一台服务器对所有这些服务器都具有权威性。
As defined in [RFC3315], a DHCPv6 ADVERTISE message with a preference option of 255 is an indicator to a DHCPv6 client to immediately begin a client-initiated message exchange by transmitting a REQUEST message to the server that sent the ADVERTISE. Alternatively, a DHCPv6 ADVERTISE message with no preference option (or one with a value less
如[RFC3315]中所定义，首选项为255的DHCPv6播发消息是DHCPv6客户端的一个指示器，通过向发送播发消息的服务器发送请求消息来立即开始客户端启动的消息交换。或者，不带首选项选项的DHCPv6播发消息（或值小于
than 255) is an indicator to the client that it must wait for subsequent ADVERTISE messages before choosing the server to which is responds, as described in Section 17.1.2 of [RFC3315].
如[RFC3315]第17.1.2节所述，在选择is响应的服务器之前，客户端必须等待后续播发消息。
In the event of a DHCPv6 server failure, it is desirable (but not essential) for a server other than the server that originally responded to be able to rebind the client's lease. Given the proposed architecture, the remaining active DHCPv6 server will have a different address pool configured, making it technically incorrect to rebind the client in its current state. Ultimately, the rebinding will fail and the client will acquire a new binding from the pool configured in the active server.
在DHCPv6服务器发生故障的情况下，除了最初响应的服务器之外，服务器最好（但不是必需的）能够重新绑定客户端的租约。根据建议的体系结构，剩余的活动DHCPv6服务器将配置不同的地址池，这使得在当前状态下重新绑定客户端在技术上是不正确的。最终，重新绑定将失败，客户端将从活动服务器中配置的池中获取新绑定。
To reduce the possibility that a client or some other element on the network will experience a disruption in service or access to relevant binding data, shorter values for T1, T2, valid, and preferred lifetimes can be used. The values for the last three can be adjusted or configured to minimize service disruption. Ideally, setting them equal (or nearly equal) can be used to trigger a DHCPv6 client to reacquire the IPv6 address, prefix, and/or configuration information almost immediately after the rebinding fails. It is important to note, however, that shorter values will create an additional load on the DHCPv6 servers.
为了减少客户端或网络上的某些其他元素在服务或访问相关绑定数据时遇到中断的可能性，可以使用T1、T2、valid和preferred Lifetime的较短值。可以调整或配置最后三个的值，以最小化服务中断。理想情况下，将它们设置为相等（或几乎相等）可用于触发DHCPv6客户端在重新绑定失败后几乎立即重新获取IPv6地址、前缀和/或配置信息。但是，需要注意的是，较短的值将在DHCPv6服务器上产生额外的负载。
While using a split prefix configuration model, the dynamic updates to DNS [RFC2136] can be coordinated to ensure that the DNS is properly updated with the current binding information. Challenges arise with regards to the update of the PTR resource record for IPv6 addresses since the DNS information may need to be overwritten in a failure condition. The use of split prefixes enables the differentiation of bindings and binding timing to determine which represents the current state. This becomes particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to determine lease or binding state.
在使用拆分前缀配置模型时，可以协调对DNS[RFC2136]的动态更新，以确保使用当前绑定信息正确更新DNS。在更新IPv6地址的PTR资源记录方面出现了挑战，因为在故障情况下可能需要覆盖DNS信息。使用拆分前缀可以区分绑定和绑定时间，以确定哪个表示当前状态。当使用DHCPv6租赁[RFC5007]和/或DHCPv6批量租赁[RFC5460]确定租赁或绑定状态时，这一点尤为重要。
Finally, a benefit of this scheme is that the use of separate pools per DHCPv6 server makes failure conditions more obvious and detectable.
最后，此方案的一个好处是，每个DHCPv6服务器使用单独的池使故障条件更加明显和可检测。
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:0000::/65
Preference = 255
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:0000::/65
Preference = 255
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:8000::/65
Preference = 0
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1:8000::/65
Preference = 0
Server n+1
==========
Prefix, pool, and preference would
vary based on prefix definition
Server n+1
==========
Prefix, pool, and preference would
vary based on prefix definition
Figure 1: Split prefixes approach
图1：拆分前缀方法
In the multiple prefix model, each DHCPv6 server is configured with a unique, non-overlapping prefix. A /64 pool equal to the prefix is configured on each server. For example, the 2001:db8:1:1::/64 pool would be assigned to a single DHCPv6 server for allocation to clients equal to its parent prefix 2001:db8:1:1::/64. The second DHCPv6 server could use 2001:db8:1:5::/64 as both pool and prefix. This would be repeated for each active DHCP server. An example of this scenario is presented in Figure 2.
在多前缀模型中，每个DHCPv6服务器都配置了一个唯一的、不重叠的前缀。在每台服务器上配置一个等于前缀的/64池。例如，2001:db8:1:1:：/64池将分配给单个DHCPv6服务器，以便分配给等于其父前缀2001:db8:1:1:：/64的客户端。第二台DHCPv6服务器可以使用2001:db8:1:5:：/64作为池和前缀。这将对每个活动DHCP服务器重复。图2中给出了该场景的一个示例。
The major difference between the split prefixes approach and the multiple unique prefixes approach is that the latter does not require prefixes to be adjacent. In fact, the split prefixes approach can be considered a special case of the multiple unique prefixes approach.
拆分前缀方法和多个唯一前缀方法之间的主要区别在于后者不要求前缀相邻。实际上，拆分前缀方法可以被视为多个唯一前缀方法的一个特例。
This approach uses a unique prefix and ultimately a single pool per DHCPv6 server with the corresponding prefixes configured for use in the network. The corresponding network infrastructure must in turn be configured to use multiple prefixes on the interface(s) facing the DHCPv6 clients. The configuration is similar on all the servers, but a different prefix and a different preference are used for each DHCPv6 server.
这种方法使用唯一的前缀，最终每个DHCPv6服务器使用一个池，并配置相应的前缀以在网络中使用。相应的网络基础设施必须依次配置为在面向DHCPv6客户端的接口上使用多个前缀。所有服务器上的配置都类似，但每个DHCPv6服务器使用不同的前缀和首选项。
This approach drastically increases the rate of consumption of IPv6 prefixes and also yields operational and management challenges related to the underlying network since a significantly higher number of prefixes need to be configured and routed. It also does not provide a clean migration path to the desired solution using a standards-based DHCPv6 redundancy or failover protocol (which, of course, has yet to be specified).
这种方法大大增加了IPv6前缀的使用率，同时也带来了与底层网络相关的操作和管理挑战，因为需要配置和路由的前缀数量要多得多。它还没有使用基于标准的DHCPv6冗余或故障切换协议（当然，尚未指定）提供到所需解决方案的干净迁移路径。
The use of multiple unique prefixes provides benefits related to dynamic updates to DNS similar to those referred to in Section 6.1. The use of multiple unique prefixes enables the differentiation of bindings and binding timing to determine which represents the current state. This becomes particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to determine lease or binding state. The use of separate prefixes and pools per DHCPv6 server makes failure conditions more obvious and detectable.
The use of multiple unique prefixes provides benefits related to dynamic updates to DNS similar to those referred to in Section 6.1. The use of multiple unique prefixes enables the differentiation of bindings and binding timing to determine which represents the current state. This becomes particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are used to determine lease or binding state. The use of separate prefixes and pools per DHCPv6 server makes failure conditions more obvious and detectable.translate error, please retry
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 2
========
Prefix = 2001:db8:1:5::/64
Pool = 2001:db8:1:5::/64
Preference = 0
Server 2
========
Prefix = 2001:db8:1:5::/64
Pool = 2001:db8:1:5::/64
Preference = 0
Server 3
========
Prefix = 2001:db8:1:f::/64
Pool = 2001:db8:1:f::/64
Preference = [1..254]
Server 3
========
Prefix = 2001:db8:1:f::/64
Pool = 2001:db8:1:f::/64
Preference = [1..254]
Figure 2: Multiple unique prefix approach
图2：多唯一前缀方法
In the identical prefix model, each DHCPv6 server is configured with the same overlapping prefix and pool deployed for use within an IPv6 network. Distribution between two or more servers, for example, would require that the same /64 prefix and pool be configured on all DHCP servers. For instance, the 2001:db8:1:1::/64 pool would be assigned to all the DHCPv6 servers for allocation to clients derived from the 2001:db8:1:1::/64 prefix. This would be repeated for each active DHCP server. An example of such a scenario is presented in Figure 3.
在相同的前缀模型中，每个DHCPv6服务器都配置了相同的重叠前缀和部署用于IPv6网络的池。例如，两台或多台服务器之间的分发要求在所有DHCP服务器上配置相同的/64前缀和池。例如，2001:db8:1:1:：/64池将分配给所有DHCPv6服务器，以便分配给从2001:db8:1:1:：/64前缀派生的客户端。这将对每个活动DHCP服务器重复。图3给出了这样一个场景的示例。
This approach uses the same prefix, length, and pool definition across multiple DHCPv6 servers. All other configuration parameters remain the same, with the exception of the DHCPv6 preference. Such an approach conceivably eases the migration of DHCPv6 services to fully support a standards-based redundancy or failover protocol once such solution becomes available. Similar to the split prefix architecture described above, this approach does not place any additional addressing requirements on the network infrastructure.
这种方法在多个DHCPv6服务器上使用相同的前缀、长度和池定义。除DHCPv6首选项外，所有其他配置参数保持不变。可以想象，这种方法简化了DHCPv6服务的迁移，以便在这种解决方案可用时完全支持基于标准的冗余或故障切换协议。与上述拆分前缀体系结构类似，这种方法不会对网络基础设施提出任何额外的寻址要求。
The use of identical prefixes provides no benefit or advantage related to dynamic DNS updates, support of DHCPv6 Leasequery [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460]. In this case, all DHCP servers will use the same prefix and pool configurations making it less obvious that a failure condition or event has occurred.
在动态DNS更新、支持DHCPv6租赁服务[RFC5007]或DHCPv6批量租赁服务[RFC5460]方面，使用相同前缀没有任何好处或优势。在这种情况下，所有DHCP服务器都将使用相同的前缀和池配置，从而减少发生故障情况或事件的可能性。
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
+----------+ +-----------+
| Client 1 +-\ +--+ Server 1 |
+----------+ \ | +-----------+
\ |
\ |
\ |
+----------+ \ | +-----------+
| Client 2 +--------------+--| Server 2 |
+----------+ / | +-----------+
. / .
. / .
. / .
+----------+ / . +-----------+
| Client N +-/ .--| n+1 Server|
+----------+ +-----------+
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 1
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 255
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 0
Server 2
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = 0
Server 3
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = [1..254]
Server 3
========
Prefix = 2001:db8:1:1::/64
Pool = 2001:db8:1:1::/64
Preference = [1..254]
Figure 3: Identical prefix approach
图3：相同前缀方法
The lack of interaction between DHCPv6 servers introduces a number of challenges related to the operations of the same service instances in a production environment. The following areas are of particular concern:
DHCPv6服务器之间缺乏交互会带来许多与生产环境中相同服务实例的操作相关的挑战。以下领域特别令人关注：
o In the identical prefixes scenario, both servers must follow the same address allocation procedure, i.e., they both must use the same algorithm and the same policy to determine which address is going to be assigned to a specific client. Otherwise, there is a distinct chance that each server will assign the same address to
o 在相同的前缀方案中，两台服务器必须遵循相同的地址分配过程，即，它们必须使用相同的算法和相同的策略来确定将要分配给特定客户端的地址。否则，每个服务器都有可能将相同的地址分配给服务器
two different clients. It is expected that both servers will receive each incoming REQUEST message. Usually, no special action is required to achieve this as REQUEST messages are sent to a multicast address by clients. Relays are expected to forward incoming client messages to all servers. The client indicates the chosen server by including its DHCP Unique Identifier (DUID) in the Server-ID option. The chosen server assigns the address and other configuration options, while the other server discards the incoming request. In case of a failure of one server, the other server will assign the same address by following the same algorithm and the same policy.
两个不同的客户。预期两台服务器都将接收每个传入的请求消息。通常，由于请求消息是由客户端发送到多播地址的，因此不需要特殊操作来实现这一点。中继预期将传入的客户端消息转发到所有服务器。客户端通过在服务器ID选项中包含其DHCP唯一标识符（DUID）来指示所选服务器。所选服务器分配地址和其他配置选项，而另一台服务器丢弃传入的请求。如果一台服务器出现故障，另一台服务器将按照相同的算法和策略分配相同的地址。
o Interactions with DNS server(s) using dynamic update for the same address when one or more DHCPv6 servers have become unavailable. This specifically becomes a challenge when (or if) nodes that were initially granted a lease:
o 当一个或多个DHCPv6服务器不可用时，使用同一地址的动态更新与DNS服务器进行交互。当（或如果）最初被授予租约的节点：
1. Attempt to renew or rebind the lease originally granted, or
1. 试图续签或重新绑定最初授予的租约，或
2. Attempt to obtain a new lease
2. 试图获得新租约
The DHCID resource record [RFC4701] allows identification of the current owner of the specific DNS data that is the target of an update [RFC2136]. [RFC4704] specifies how DHCPv6 servers and/or clients may perform updates. [RFC4703] provides a way to solve conflicts between clients. Although [RFC4703] deals with most cases, it is still possible to leave abandoned resource records. Consider the following scenario: there are two independent servers, A and B. Server A assigns a lease to a client and updates the DNS with an AAAA record for the assigned address. When the client renews, server A is not available and server B assigns a different lease. The DNS is again updated, so now two AAAA resource records are present for the client: there is no indication as to which of the two leases is active. If server A never recovers, its information may never be removed (although it should be noted that this case is somewhat similar to that of a single server crashing and leaving abandoned resource records).
DHCID资源记录[RFC4701]允许识别作为更新[RFC2136]目标的特定DNS数据的当前所有者。[RFC4704]指定DHCPv6服务器和/或客户端如何执行更新。[RFC4703]提供了解决客户端之间冲突的方法。尽管[RFC4703]处理大多数情况，但仍然可以保留废弃的资源记录。考虑下面的场景：有两个独立的服务器，A和B服务器A向客户端分配租约，并用指定地址的AAAA记录更新DNS。当客户端续订时，服务器A不可用，服务器B分配不同的租约。DNS再次更新，因此现在客户端有两个AAAA资源记录：没有迹象表明两个租约中的哪一个处于活动状态。如果服务器A从未恢复，则其信息可能永远不会被删除（尽管应该注意，这种情况与单个服务器崩溃并留下废弃的资源记录的情况有些类似）。
o Interactions with DHCPv6 servers to facilitate the acquisition of IPv6 lease data by way of the DHCPv6 Leasequery [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460] protocols when one or more DHCPv6 servers have granted leases to DHCPv6 clients and later became unavailable. If the lease data is required and the granting server is unavailable, it will not be possible to obtain any information about leases granted until one of the following has taken place:
o 当一个或多个DHCPv6服务器已向DHCPv6客户端授予租约且随后变得不可用时，与DHCPv6服务器交互，以便于通过DHCPv6租约[RFC5007]或DHCPv6批量租约[RFC5460]协议获取IPv6租约数据。如果需要租约数据且授权服务器不可用，则在发生以下情况之一之前，将无法获取有关已授予租约的任何信息：
1. The granting DHCPv6 server becomes available with all lease information restored.
1. 授予DHCPv6服务器将在所有租约信息恢复后可用。
2. The client has renewed or rebound its lease against a different DHCPv6 server.
2. 客户端已针对不同的DHCPv6服务器续订或恢复其租约。
It is important to note that any exchange of available leases and synchronization between DHCPv6 servers is not possible until a redundancy or failover protocol is standardized or proprietary solutions become available.
需要注意的是，在冗余或故障切换协议标准化或专有解决方案可用之前，DHCPv6服务器之间的可用租约和同步的任何交换都是不可能的。
Additional security considerations are created through the use of this interim architecture beyond what has been cited in Section 23 of [RFC3315]. In particular, the dynamic DNS update using the models defined in this document allows for the possibility of not removing abandoned DNS records even when using the conflict resolution mechanism defined in [RFC4703]. However, this is no worse than a case where a single deployed server crashes and its lease database cannot be recovered.
除了[RFC3315]第23节中引用的内容外，还通过使用该临时架构创建了其他安全注意事项。特别是，使用本文档中定义的模型进行的动态DNS更新允许即使在使用[RFC4703]中定义的冲突解决机制时也不删除废弃的DNS记录。但是，这并不比单个部署的服务器崩溃且其租约数据库无法恢复的情况更糟糕。
When using the identical prefixes model, care must be taken to ensure that all servers use the same lease allocation procedure and are configured with the same policy. If this guidance is not followed, there is a risk of assignment of the same lease to two separate clients. In some cases, that situation can be recovered by using Duplicate Address Detection (Neighbor Discovery) and the DECLINE mechanism (DHCPv6).
在使用相同的前缀模型时，必须注意确保所有服务器使用相同的租约分配过程，并使用相同的策略进行配置。如果不遵守本指南，则存在将同一租约转让给两个独立客户的风险。在某些情况下，可以通过使用重复地址检测（邻居发现）和拒绝机制（DHCPv6）来恢复这种情况。
The authors would like to thank Bernie Volz, Kim Kinnear, Ralph Droms, David Hankins, Chuck Anderson, Ted Lemon, Stephen Farrel, Pete McCann, Robert Sparks, Martin Stiemerling, Brian Haberman, and Barry Leiba for their input and review.
The authors would like to thank Bernie Volz, Kim Kinnear, Ralph Droms, David Hankins, Chuck Anderson, Ted Lemon, Stephen Farrel, Pete McCann, Robert Sparks, Martin Stiemerling, Brian Haberman, and Barry Leiba for their input and review.translate error, please retry
Special thanks to Stephen Morris for his numerous spelling, grammar corrections, and proofreading.
特别感谢斯蒂芬·莫里斯（Stephen Morris）无数次的拼写、语法更正和校对。
This work has been partially supported by Department of Computer Communications (a division of Gdansk University of Technology) and the National Centre for Research and Development (Poland) under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045/ 09-00 (Future Internet Engineering Project).
这项工作得到了部分计算机通信（格但斯克技术大学的一个部门）和国家研究开发中心（波兰）在欧洲区域发展基金，批准号Poig.01.01.02-0-04/0900（未来互联网工程项目）下的支持。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)", RFC 4701, October 2006.
[RFC4701]Stapp，M.，Lemon，T.，和A.Gustafsson，“用于编码动态主机配置协议（DHCP）信息（DHCID RR）的DNS资源记录（RR）”，RFC 47012006年10月。
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients", RFC 4703, October 2006.
[RFC4703]Stapp，M.和B.Volz，“解决动态主机配置协议（DHCP）客户端之间的完全限定域名（FQDN）冲突”，RFC 4703，2006年10月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，2006年10月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，2007年9月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 54602009年2月。
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010.
[RFC5970]Huth，T.，Freimann，J.，Zimmer，V.，和D.Thaler，“网络引导的DHCPv6选项”，RFC 59702010年9月。
[FAILREQ] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", Work in Progress, September 2012.
[FAILREQ]Mrugalski，T.和K.Kinnear，“DHCPv6故障切换要求”，正在进行的工作，2012年9月。
Authors' Addresses
作者地址
John Jason Brzozowski Comcast Cable Communications 1306 Goshen Parkway West Chester, PA 19380 USA
约翰·杰森·布佐夫斯基康卡斯特有线通信公司美国宾夕法尼亚州西切斯特戈森公园路1306号，邮编：19380
Phone: +1-609-377-6594
EMail: john_brzozowski@cable.comcast.com
Phone: +1-609-377-6594
EMail: john_brzozowski@cable.comcast.com
Jean-Francois Tremblay Videotron G.P. 612 Saint-Jacques Montreal, Quebec H3C 4M8 Canada
Jean-Francois Tremblay Videotron G.P.612圣雅克蒙特利尔，魁北克H3C 4M8加拿大
EMail: jf@jftremblay.com
EMail: jf@jftremblay.com
Jack Chen Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA
Jack Chen时代华纳有线电视13820美国弗吉尼亚州赫恩登日出谷大道20171
EMail: jack.chen@twcable.com
EMail: jack.chen@twcable.com
Tomasz Mrugalski Internet Systems Consortium, Inc. 950 Charter St. Redwood City, CA 94063 USA
Tomasz Mrugalski Internet Systems Consortium，Inc.美国加利福尼亚州红木市查特街950号，邮编94063
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com