Network Working Group T. Chown
Request for Comments: 4477 University of Southampton
Category: Informational S. Venaas
UNINETT
C. Strauf
Clausthal University of Technology
May 2006
Network Working Group T. Chown
Request for Comments: 4477 University of Southampton
Category: Informational S. Venaas
UNINETT
C. Strauf
Clausthal University of Technology
May 2006
Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues
动态主机配置协议（DHCP）：IPv4和IPv6双堆栈问题
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken.
节点可能支持使用IPv4和/或IPv6协议进行通信。这样的节点可能希望通过动态主机配置协议（DHCP）获得IPv4和/或IPv6配置设置。为IPv4设计的DHCP（RFC 2131）的原始版本现在已由用于IPv6的新DHCPv6（RFC 3315）补充。本文档描述了双IP版本DHCP交互中发现的问题，其中最重要的方面是如何处理客户端处理从DHCPv4和DHCPv6服务器接收的配置信息时的潜在问题。该文件就如何最好地处理这些问题的总体战略提出了建议，并确定了今后要开展的工作。
Table of Contents
目录
1. Introduction ....................................................3
2. Configuration Scenarios .........................................3
3. Dual-Stack Issues ...............................................4
3.1. Handling Multiple Responses ................................4
3.2. Different Administrative Management ........................5
3.3. Multiple Interfaces ........................................5
3.4. DNS Load Balancing .........................................5
3.5. DNS Search Path Issues .....................................5
3.6. Protocol Startup Sequence ..................................6
3.7. DHCP Option Variations .....................................6
3.8. Security Issues ............................................6
4. Potential Solutions .............................................7
4.1. Separate DHCP Servers ......................................7
4.2. Single DHCPv6 Server .......................................8
4.3. Optimising for Failure with Lists of Addresses .............9
4.4. Administrative and Other Areas ............................10
5. Summary ........................................................10
6. Security Considerations ........................................12
7. Acknowledgements ...............................................12
8. Informative References .........................................12
1. Introduction ....................................................3
2. Configuration Scenarios .........................................3
3. Dual-Stack Issues ...............................................4
3.1. Handling Multiple Responses ................................4
3.2. Different Administrative Management ........................5
3.3. Multiple Interfaces ........................................5
3.4. DNS Load Balancing .........................................5
3.5. DNS Search Path Issues .....................................5
3.6. Protocol Startup Sequence ..................................6
3.7. DHCP Option Variations .....................................6
3.8. Security Issues ............................................6
4. Potential Solutions .............................................7
4.1. Separate DHCP Servers ......................................7
4.2. Single DHCPv6 Server .......................................8
4.3. Optimising for Failure with Lists of Addresses .............9
4.4. Administrative and Other Areas ............................10
5. Summary ........................................................10
6. Security Considerations ........................................12
7. Acknowledgements ...............................................12
8. Informative References .........................................12
The original specification of the Dynamic Host Configuration Protocol (DHCP) was made with only IPv4 in mind. That specification has been subsequently revised, up to the latest version of DHCP [1]. With the arrival of IPv6, a new DHCP specification for IPv6 has been designed and published as DHCPv6 [4].
动态主机配置协议（DHCP）的原始规范仅考虑IPv4。该规范随后进行了修订，直到最新版本的DHCP[1]。随着IPv6的到来，一种新的IPv6 DHCP规范被设计并发布为DHCPv6[4]。
These protocols allow nodes to communicate via IPv4 or IPv6 (respectively) to retrieve configuration settings for operation in a managed environment. While an IPv6 node may acquire address-related configuration settings via IPv6 stateless address autoconfiguration [2], such a node may wish to use stateless DHCPv6 [5] for other administratively configured options, such as DNS or NTP.
这些协议允许节点分别通过IPv4或IPv6进行通信，以检索配置设置，以便在托管环境中进行操作。虽然IPv6节点可以通过IPv6无状态地址自动配置获取与地址相关的配置设置[2]，但这样的节点可能希望将无状态DHCPv6[5]用于其他管理配置选项，例如DNS或NTP。
In early IPv6 deployments, a dual-stack mode of operation is typically used. There will thus be nodes that require both IPv4 and IPv6 configuration settings. This document discusses issues with obtaining such settings in a dual-stack environment.
在早期的IPv6部署中，通常使用双堆栈操作模式。因此，将有需要IPv4和IPv6配置设置的节点。本文档讨论在双堆栈环境中获取此类设置的问题。
There is a general multihoming issue to be solved for DHCP. A host might simultaneously be connected to multiple networks managed by multiple parties. Also, IPv4 and IPv6 might be managed by separate parties. While these issues are touched on in this document, here we focus on the specific issues for operating DHCP in a mixed (typically dual-stack) IPv4 and IPv6 environment within a single administrative domain.
DHCP有一个普遍的多宿主问题需要解决。一台主机可能同时连接到由多方管理的多个网络。此外，IPv4和IPv6可能由不同的方管理。虽然本文档中讨论了这些问题，但这里我们将重点讨论在单个管理域内的混合（通常为双堆栈）IPv4和IPv6环境中操作DHCP的具体问题。
In this document, we refer to a "DHCP server" as a server implementing the original DHCP [1], and a "DHCPv6 server" as a server implementing DHCPv6 [4] or its stateless subset [5].
在本文档中，我们将“DHCP服务器”称为实现原始DHCP[1]的服务器，“DHCPv6服务器”称为实现DHCPv6[4]或其无状态子集[5]的服务器。
For a node in an IPv4-only or IPv6-only environment, the choice of DHCP server is a straightforward one; a DHCP server for IPv4, or a DHCPv6 server for IPv6.
对于仅IPv4或仅IPv6环境中的节点，DHCP服务器的选择非常简单；用于IPv4的DHCP服务器，或用于IPv6的DHCPv6服务器。
In a dual-stack environment a node in a managed environment will need to obtain both IPv4 and IPv6 configuration settings, such as the following:
在双堆栈环境中，托管环境中的节点将需要获得IPv4和IPv6配置设置，例如：
o IPv4 address
o IPv4地址
o IPv6 address
o IPv6地址
o NTP server
o 时间服务器
o DNS server
o DNS服务器
o NIS server
o NIS服务器
o DNS search path
o DNS搜索路径
While the format of address settings will be IP specific, the node may equally well acquire IPv4 or IPv6 addresses for some settings, such as for DNS or NTP, if those services are available via IPv4 or IPv6 transport. Currently, a DHCP server returns IPv4 data, while a DHCPv6 server returns IPv6 data.
虽然地址设置的格式将是特定于IP的，但如果这些服务通过IPv4或IPv6传输可用，则节点同样可以为某些设置（例如DNS或NTP）获取IPv4或IPv6地址。目前，DHCP服务器返回IPv4数据，而DHCPv6服务器返回IPv6数据。
It is worth noting that in an IPv4 environment, with a DHCP server, the choice of whether to use DHCP is made by the node. In an IPv6 environment, the use of the managed and other bits in the Router Advertisement can offer a hint to the node whether or not to use full DHCPv6 or its stateless variant. It is perhaps not clear whether a dual-stack node should do DHCP for IPv4 if Managed and OtherConfig flags in the Router Advertisement are both off; it seems most appropriate that the decision to use DHCP for IPv4 or not should be as if the host were IPv4-only.
值得注意的是，在IPv4环境中，使用DHCP服务器时，节点可以选择是否使用DHCP。在IPv6环境中，在路由器公告中使用托管位和其他位可以向节点提供是否使用完整DHCPv6或其无状态变体的提示。如果路由器公告中的Managed和OtherConfig标志都关闭，则可能不清楚双堆栈节点是否应该为IPv4执行DHCP；对于IPv4是否使用DHCP，最合适的决定似乎应该是主机仅为IPv4。
In this section, we list issues that have been raised to date, related to dual-stack DHCP operation.
在本节中，我们列出了迄今为止提出的与双堆栈DHCP操作相关的问题。
It has been noted from comments that the first four, and possibly five, subsections here may also be viewed as multihoming issues.
从评论中注意到，这里的前四小节，可能还有五小节，也可能被视为多宿主问题。
The general question is how to handle configuration information that may be gathered from multiple sources. Where those sources are DHCP and DHCPv6 servers (which may be two physical nodes or two servers running on the same node) the client node needs to know whether to use the most recent data, or whether to perform some merger or union of the responses by certain rules. A method for merging lists of addresses, for options that carry such information, may also be required. A node may choose to ask a DHCPv6 server and only use a DHCP server if no response is received.
一般问题是如何处理可能从多个来源收集的配置信息。如果这些源是DHCP和DHCPv6服务器（可能是两个物理节点或在同一节点上运行的两个服务器），则客户机节点需要知道是否使用最新数据，或者是否根据某些规则执行响应的合并或联合。可能还需要一种合并地址列表的方法，用于包含此类信息的选项。节点可以选择询问DHCPv6服务器，并且仅在未收到响应时使用DHCP服务器。
Merging is possible, but is likely to be complex. There could be some priority, so that if both DHCP and DHCPv6 servers offer a value, only one is used. Or the node could choose to store and use both, in some order of its choosing. Merging issues are further discussed later in this document.
合并是可能的，但可能很复杂。可能有一些优先级，因此如果DHCP和DHCPv6服务器都提供一个值，则只使用一个值。或者，节点可以选择按其选择的顺序存储和使用两者。本文后面将进一步讨论合并问题。
A node may also obtain information from other sources, such as a manual configuration file (for example, /etc/resolv.conf for DNS data on many UNIX systems). A node configured manually to use an IPv6 DNS server may lose that configuration if it is in a dual-stack environment and uses DHCP to obtain IPv4 settings; the new IPv4 settings from the DHCP response may then overwrite the manual IPv6 DNS setting.
节点还可以从其他来源获取信息，例如手动配置文件（例如，许多UNIX系统上DNS数据的/etc/resolv.conf）。如果手动配置为使用IPv6 DNS服务器的节点处于双堆栈环境中并使用DHCP获取IPv4设置，则该节点可能会丢失该配置；DHCP响应中的新IPv4设置可能会覆盖手动IPv6 DNS设置。
In some deployments, the IPv4 and IPv6 services may not be administered by the same organisation or people, such as in a community wireless environment. This poses problems for consistency of data offered by either DHCP version.
在某些部署中，IPv4和IPv6服务可能不由同一组织或人员管理，例如在社区无线环境中。这对DHCP版本提供的数据的一致性造成了问题。
There may also be different connectivity for the protocols, and the client may gain advantage from knowing which 'administrative domain' is supplying which information. A client may need to use different received information depending on which connectivity is being used. In the example of the community wireless environment, the question of which connectivity is 'better' is a separate issue.
协议也可能有不同的连接，客户机可以从知道哪个“管理域”提供哪些信息中获益。客户端可能需要使用不同的接收信息，具体取决于所使用的连接。在社区无线环境的示例中，哪个连接“更好”是一个单独的问题。
A node may have multiple interfaces and run IPv4 and IPv6 on different interfaces. A question then is whether the settings are per interface or per node.
一个节点可能有多个接口，并在不同的接口上运行IPv4和IPv6。接下来的一个问题是，这些设置是针对每个接口还是针对每个节点。
Per-interface settings can be complex because a client node needs to know which interface system settings, like NTP server, came from. And it may not be apparent which setting should be used if, for example, an NTP server option is received on multiple interfaces, potentially over different protocols.
每个接口设置可能很复杂，因为客户端节点需要知道NTP服务器等接口系统设置来自哪个接口。例如，如果在多个接口（可能通过不同协议）上接收NTP服务器选项，则可能不清楚应该使用哪种设置。
In some cases it is preferable to list DNS server information in an ordered way per node for load balancing, giving different responses to different clients. Responses from different DHCP and DHCPv6 servers may make such configuration problematic, if the knowledge of the load balancing is not available to both servers.
在某些情况下，最好按每个节点的顺序列出DNS服务器信息，以实现负载平衡，从而为不同的客户端提供不同的响应。来自不同DHCP和DHCPv6服务器的响应可能会使这种配置出现问题，如果两台服务器都不具备负载平衡的知识。
The DNS search path may vary for administrative reasons. For example, a site under the domain example.com may choose to place an early IPv6 deployment under the subdomain ipv6.example.com, until it is confident of offering a full dual-stack service under its main
DNS搜索路径可能因管理原因而有所不同。例如，域example.com下的站点可能会选择在子域IPv6.example.com下部署早期IPv6，直到它有信心在其主域下提供完整的双堆栈服务
domain. The subtlety here is that the DNS search path then affects the choice of protocol used, such as IPv6 for nodes in ipv6.example.com.
领域这里的微妙之处在于DNS搜索路径会影响所用协议的选择，例如IPv6.example.com中节点的IPv6。
In the dual-stack environment, one needs to consider what happens if, for example, the IPv6 interface (transport) is started after DHCPv4 was used to configure the client. Should the client then simply discard the current IPv4 information, or merge it with a subsequent IPv6 response? It may also be possible that one protocol is shut down or started while the system is running. There are similarities here to issues when DHCP renewals have information that may appear that previously was not available (or no longer carry information that has been removed).
在双栈环境中，需要考虑的是，如果在使用DHCPv4配置客户端之后启动IPv6接口（传输），将会发生什么。然后，客户端应该放弃当前IPv4信息，还是将其与后续IPv6响应合并？系统运行时，也可能关闭或启动一个协议。这里的问题与DHCP续订中可能包含以前不可用的信息（或不再包含已删除的信息）时的问题类似。
Some options in DHCP are not available in DHCPv6 and vice versa. Some IP-version limitations naturally apply; for example, only IPv6 addresses can be in an IPv6 NTP option. The DHCP and DHCPv6 option numbers may be different.
DHCP中的某些选项在DHCPv6中不可用，反之亦然。一些IP版本限制自然适用；例如，IPv6 NTP选项中只能包含IPv6地址。DHCP和DHCPv6选项编号可能不同。
Some sites may choose to use IPv4-mapped addresses in DHCPv6-based options. The merits and drawbacks of such an approach need discussion.
一些站点可能会选择在基于DHCPv6的选项中使用IPv4映射地址。这种方法的优点和缺点需要讨论。
A site administrator may wish to configure all their dual-stack nodes with (say) two NTP servers, one of which has an IPv4 address, the other an IPv6 address. In this case, it may be desirable for an NTP option to carry a list of addresses, where some may be IPv4 and some may be IPv6. In general one could consider having DHCPv6 options that can carry a mix of IPv4 and IPv6 addresses.
站点管理员可能希望使用（例如）两个NTP服务器配置其所有双堆栈节点，其中一个具有IPv4地址，另一个具有IPv6地址。在这种情况下，NTP选项可能需要携带地址列表，其中一些可能是IPv4，一些可能是IPv6。一般来说，可以考虑使用DHCPv6选项，可以携带IPv4和IPv6地址的混合。
This document does not introduce any new security issues per se. A detailed analysis of DHCP and DHCPv6 security is out of scope for this document.
本文档本身没有引入任何新的安全问题。对DHCP和DHCPv6安全性的详细分析超出了本文档的范围。
While there is a specification for authentication for DHCP messages [3], the standard seems to have very few, if any, implementations. Thus DHCP and DHCPv6 servers are still liable to be spoofed. Adding an additional protocol may give an extra avenue for attack, should an attacker perhaps spoof a DHCPv6 server but not a DHCP server.
虽然有DHCP消息的身份验证规范[3]，但该标准似乎只有很少的实现（如果有的话）。因此，DHCP和DHCPv6服务器仍然容易被欺骗。如果攻击者可能欺骗DHCPv6服务器而不是DHCP服务器，则添加附加协议可能会提供额外的攻击途径。
Here we discuss the two broad solution strategies proposed within the IETF dhc WG. The first is to run separate DHCP and DHCPv6 servers (with the client merging information received from both where necessary, or perhaps choosing to query a particular version first). The second is to run only a DHCPv6 server and relay IPv4 configuration information within (new) IPv4 configuration options.
这里我们讨论IETF dhc工作组中提出的两种广泛的解决方案策略。第一种方法是运行单独的DHCP和DHCPv6服务器（客户机在必要时合并从这两个服务器接收的信息，或者选择先查询特定版本）。第二种方法是仅运行DHCPv6服务器，并在（新的）IPv4配置选项中中继IPv4配置信息。
One solution is to run separate DHCP and DHCPv6 servers. These may or may not be run on the same physical node. The information served from the DHCP servers could be generated from a single database instance for consistency. One might have a single server instance supporting both DHCPv4 and DHCPv6 protocols.
一种解决方案是运行单独的DHCP和DHCPv6服务器。它们可以在同一物理节点上运行，也可以不在同一物理节点上运行。DHCP服务器提供的信息可以从单个数据库实例生成，以确保一致性。可能有一个服务器实例同时支持DHCPv4和DHCPv6协议。
In this approach, some best practice guidance is required for how multiple responses are handled or merged. Administrators have the onus to maintain consistency (for example, scripts may generate common DHCP and DHCPv6 configuration files).
在这种方法中，如何处理或合并多个响应需要一些最佳实践指南。管理员有责任保持一致性（例如，脚本可能会生成常见的DHCP和DHCPv6配置文件）。
In some cases, inconsistencies may not matter. In a simple case, an NTP server will give the same time whether accessed by IPv4 or IPv6. Even if different recursive DNS servers are offered via DHCP or DHCPv6, then those name servers should provide the same response to a given query. In cases where sites may be operating a 'two-faced DNS', this will still hold true if the node is on the same topological point on the network from an IPv4 or IPv6 perspective. The order of DNS servers in a node's configuration is not important, unless DNS load balancing is required.
在某些情况下，不一致可能并不重要。在一个简单的情况下，无论是通过IPv4还是IPv6访问，NTP服务器都会给出相同的时间。即使通过DHCP或DHCPv6提供不同的递归DNS服务器，这些名称服务器也应该对给定查询提供相同的响应。在站点可能正在运行“双面DNS”的情况下，如果从IPv4或IPv6的角度来看，节点位于网络上的同一拓扑点上，这一点仍然成立。节点配置中DNS服务器的顺序并不重要，除非需要DNS负载平衡。
In other cases, inconsistencies may be an issue; for example, where lists of values are returned, an algorithm is needed for list merger (e.g., "alternate, DHCPv6 first"). Or there may be incompatible configuration values where, for example, DHCPv6 supplies domain names (such the SMTP or POP servers) whereas DHCPv4 provides only IPv4 addresses.
在其他情况下，不一致可能是一个问题；例如，在返回值列表的情况下，列表合并需要一个算法（例如，“alternate，DHCPv6 first”）。或者可能存在不兼容的配置值，例如，DHCPv6提供域名（如SMTP或POP服务器），而DHCPv4仅提供IPv4地址。
In the case of separate servers, there are some options, like DNS search path, that aren't used in a specific IP protocol context.
对于单独的服务器，有一些选项（如DNS搜索路径）不在特定IP协议上下文中使用。
The multiple server approach will have some simplifications. The DHCPv4 and DHCPv6 servers may provide the same value for a particular parameter, in which case there is no conflict. In some cases, the value may be different, but the effect should be the same (such as an
多服务器方法将有一些简化。DHCPv4和DHCPv6服务器可以为特定参数提供相同的值，在这种情况下不存在冲突。在某些情况下，值可能不同，但效果应该相同（例如
NTP server). The crux of the issue is to identify where differences may occur and where these differences will have an impact on node behaviour.
NTP服务器）。问题的关键在于确定差异可能发生的位置以及这些差异对节点行为的影响。
One possible solution is to have per-host preferences, or an ordered list of preferences, for example, "use manually configured", "prefer DHCPv4", or "prefer DHCPv6", assuming the host can act based upon which protocol is used. It is then up to the site administrator to ensure that values returned from either DHCP are consistent (a principle that extends if other methods are used, such as NIS or Service Location Protocol (SLP)).
一种可能的解决方案是，假设主机可以根据所使用的协议进行操作，则具有每个主机的首选项，或一个有序的首选项列表，例如，“使用手动配置”、“首选DHCPv4”或“首选DHCPv6”。然后，由站点管理员确保从任一DHCP返回的值是一致的（如果使用其他方法，如NIS或服务位置协议（SLP）），这一原则将得到扩展。
There is an argument for not having to configure and operate both DHCP and DHCPv6 servers in a dual-stack site environment. The use of both servers may also lead to some redundancy in the information served. Thus, one solution may be to modify DHCPv6 to be able to return IPv4 information. This solution is hinted at in the DHCPv6 [4] specification: "If there is sufficient interest and demand, integration can be specified in a document that extends DHCPv6 to carry IPv4 addresses and configuration information." This solution may allow DHCP for IPv4 to be completely replaced by DHCPv6 with additional IPv4 information options, for dual-stack nodes.
在双堆栈站点环境中，不必同时配置和操作DHCP和DHCPv6服务器有一个理由。两台服务器的使用还可能导致所服务的信息中存在一些冗余。因此，一种解决方案可能是修改DHCPv6以能够返回IPv4信息。DHCPv6[4]规范中暗示了此解决方案：“如果有足够的兴趣和需求，可以在扩展DHCPv6以承载IPv4地址和配置信息的文档中指定集成。”此解决方案可能允许使用附加IPv4信息选项的DHCPv6完全取代IPv4的DHCP，对于双堆栈节点。
A general argument is that which DHCP protocol is used (whether it's over IPv4 or IPv6) shouldn't affect what kind of addresses you can get configured with it, and that simplicity and predictability come from using a single server over a single transport. IPv4-capable hosts will likely remain for at least 10 years, probably much longer; do we want dual-stack hosts (which will become the norm) to do both DHCPv4 and DHCPv6 forever while dual-stack? If you need both servers to configure interfaces with addresses, and get other configurations, then you rely on two separate protocols to work (servers and relays, etc.) in order for the host to behave correctly.
一个普遍的论点是，所使用的DHCP协议（无论是IPv4协议还是IPv6协议）不应影响您可以使用它配置的地址类型，并且简单性和可预测性来自于通过单个传输使用单个服务器。支持IPv4的主机可能会保留至少10年，甚至更长时间；我们是否希望双堆栈主机（将成为标准）在双堆栈的情况下永远同时运行DHCPv4和DHCPv6？如果您需要两台服务器来配置带有地址的接口，并获得其他配置，那么您需要依靠两个独立的协议（服务器和中继等）来工作，以便主机能够正常工作。
This approach may require the listing of a mix of IPv4 and IPv6 addresses for an option. This could then be considered when new IPv6 options are introduced. There could be just two options needed, one new option for the address delegation, and one for doing encapsulation.
此方法可能需要为一个选项列出IPv4和IPv6地址的混合列表。在引入新的IPv6选项时，可以考虑这一点。可能只需要两个选项，一个用于地址委派的新选项，一个用于封装。
Also, there are a number of paradigms in DHCPv6 that we miss in DHCPv4. An example is movement away from using MAC addresses for per-host address assignment and instead using DHCP Unique Identifier (DUIDs) or Identity Association Identifiers (IAIDs). As stated in Section 9 of RFC3315, DHCPv6 servers use DUIDs to identify clients for the selection of configuration parameters and in the association
此外，DHCPv6中有许多我们在DHCPv4中遗漏的范例。例如，不再使用MAC地址进行每主机地址分配，而是使用DHCP唯一标识符（DUID）或身份关联标识符（IAID）。如RFC3315第9节所述，DHCPv6服务器使用DUID来识别用于选择配置参数和关联的客户端
of IAs with clients. DHCPv6 clients use DUIDs to identify a server in messages where a server needs to be identified. However, in this particular example, the new DHCPv6 functionality has recently been retrofitted to IPv4 via a specification for DUIDs for DHCPv4 [6].
国际会计准则与客户的关系。DHCPv6客户端使用DUID在需要标识服务器的消息中标识服务器。然而，在这个特定的示例中，新的DHCPv6功能最近通过DHCPv4的DUIDs规范改装为IPv4[6]。
However, there are a number of potential problems with this approach:
然而，这种方法存在一些潜在问题：
o IPv4-only nodes would not have any DHCP service available to them; such an approach is only possible in a fully dual-stack environment.
o 仅IPv4节点将没有任何DHCP服务可供其使用；这种方法仅在完全双堆栈环境中可行。
o The client node may then be IPv6-only and receive IPv4 configuration settings that it does not want or be able to handle meaningfully.
o 然后，客户端节点可能仅为IPv6，并接收其不希望或无法有效处理的IPv4配置设置。
o The DHCPv4 servers need to be configured anyway to support IPv4- only hosts, so there is still duplication of information.
o DHCPv4服务器无论如何都需要配置为支持仅IPv4的主机，因此仍然存在信息重复。
o What happens if there are DHCPv6 servers that don't return IPv4 information? Does this mean the client can't run IPv4 (since it won't do DHCPv4)?
o 如果存在不返回IPv4信息的DHCPv6服务器，会发生什么情况？这是否意味着客户端不能运行IPv4（因为它不能运行DHCPv4）？
o If IPv4 information is served from a DHCPv6 server as well as an IPv4 DHCP server, IPv4 address space will need to be allocated to both servers, fragmenting the potentially precious IPv4 global address resource for the site.
o 如果从DHCPv6服务器和IPv4 DHCP服务器提供IPv4信息，则需要将IPv4地址空间分配给这两个服务器，从而分割站点的潜在宝贵IPv4全局地址资源。
There is a generic issue with any option that includes a list of addresses of servers (such as DNS server addresses). The list is offered to cater for resilience, such as whether the listed server itself fails or connectivity to the server fails. If the client does not know the cause of failure, its optimal strategy is to try a different server, via a different protocol. The problem today is that the IPv4 list is returned via DHCPv4, and the IPv6 list via DHCPv6; the client really has no way to "try a different server", since that information is lost by the protocol, even though it may be known by the server.
任何包含服务器地址列表（如DNS服务器地址）的选项都存在一个通用问题。提供该列表是为了满足弹性，例如列出的服务器本身是否出现故障或与服务器的连接是否出现故障。如果客户机不知道故障原因，其最佳策略是通过不同的协议尝试不同的服务器。现在的问题是IPv4列表通过DHCPv4返回，IPv6列表通过DHCPv6返回；客户机实际上无法“尝试其他服务器”，因为协议会丢失这些信息，即使服务器可能知道这些信息。
Just putting merging heuristics in the client cannot provide the best behaviour, since information is lost. By comparison, if IPv4-mapped addresses were included in the DHCPv6 option along with IPv6 addresses, the DHCP server can give an intelligent order that takes into account which addresses are of the same DNS/whatever server. IPv6-only clients have to know to discard the IPv4-mapped addresses in this solution, and it's much easier to solve this in the combined-DHCP-server case than in the two-server case.
仅仅在客户机中使用合并试探法无法提供最佳行为，因为信息会丢失。相比之下，如果IPv4映射地址与IPv6地址一起包含在DHCPv6选项中，则DHCP服务器可以给出一个智能顺序，其中考虑哪些地址属于相同的DNS/服务器。在这个解决方案中，只有IPv6的客户端必须知道放弃IPv4映射地址，并且在组合DHCP服务器的情况下要比在两个服务器的情况下更容易解决这个问题。
One can argue that this is only an optimisation, and in many cases the list has only two elements, so the "next" choice is forced. However, this particular issue highlights the subtleties of merging responses from separate servers.
有人可能会说，这只是一种优化，在许多情况下，列表只有两个元素，因此“下一个”选择是被迫的。然而，这个特别的问题突出了合并来自不同服务器的响应的微妙之处。
There are also administrative issues or best practice that could be promoted. For example, it may be recommended that sites do not split their DNS name space for IPv6-specific testbeds.
还有一些行政问题或最佳做法可以推广。例如，建议站点不要为特定于IPv6的测试平台拆分DNS名称空间。
It may be worth considering whether separate manual configuration files should be kept for IPv4 and IPv6 settings, such as separate /etc/resolv.conf files for DNS settings on UNIX systems. However, this seems a complex solution. The problem should be better solved by other, more generalised methods.
可能值得考虑的是，是否应为IPv4和IPv6设置保留单独的手动配置文件，例如，为UNIX系统上的DNS设置保留单独的/etc/resolv.conf文件。然而，这似乎是一个复杂的解决方案。这个问题应该用其他更普遍的方法更好地解决。
It may be important at times to be able to distinguish DHCP client and server identities. DHCPv6 introduces the idea of a DHCP Unique Identifier (DUID). The DUID concept has also been retrofitted to DHCPv4 [6], and thus it may form the basis of part of the solution space for the problem at hand.
有时，能够区分DHCP客户端和服务器身份可能很重要。DHCPv6引入了DHCP唯一标识符（DUID）的概念。DUID概念也被改装为DHCPv4[6]，因此它可能构成当前问题部分解决空间的基础。
Some differences in DHCP and DHCPv6 may not be reconciled, but may not need to be, such as different ways to assign addresses by DUID in DHCPv6, or the lack of a comparable option in both DHCP versions.
DHCP和DHCPv6中的一些差异可能无法协调，但可能不需要协调，例如DHCPv6中通过DUID分配地址的方式不同，或者两个DHCP版本中都缺少可比较的选项。
There are a number of issues in the operation of DHCP and DHCPv6 servers for nodes in dual-stack environments that should be clarified. While some differences in the protocols may not be reconciled, there may not be a need to do so. However, with DHCPv6 deployment growing, there is an operational requirement to determine best practice for DHCP server provision in dual-stack environments, which may or may not imply additional protocol requirements. The principal choice is whether separate DHCP and DHCPv6 services should be maintained by a site, or whether DHCPv6 should be extended to carry IPv4 configuration settings for dual-stack nodes.
双堆栈环境中节点的DHCP和DHCPv6服务器的操作中有许多问题需要澄清。虽然协议中的一些差异可能无法调和，但可能没有必要这样做。但是，随着DHCPv6部署的增长，需要确定双堆栈环境中提供DHCP服务器的最佳实践，这可能意味着也可能不意味着额外的协议要求。主要的选择是站点是否应该维护单独的DHCP和DHCPv6服务，还是应该扩展DHCPv6以携带双堆栈节点的IPv4配置设置。
It can certainly be argued that until a site is completely dual-stack, an IPv4 DHCP service will always be required (for example, while there are still legacy printers, IP webcams, or other devices that still configure via DHCPv4), and a single IPv6 transport DHCP server offering configuration information for both protocols will then not be sufficient. In that case, IPv4 DHCP is required, and thus there
可以肯定的是，在站点完全为双栈之前，将始终需要IPv4 DHCP服务（例如，尽管仍有旧式打印机、IP网络摄像头或其他设备仍通过DHCPv4进行配置），而一个单独的IPv6传输DHCP服务器为这两个协议提供配置信息将是不够的。在这种情况下，需要IPv4 DHCP，因此
is a good rationale for focusing effort on how to combine the information received from separate IPv4 DHCP and (stateless) DHCPv6 servers.
这是将精力集中在如何组合从单独的IPv4 DHCP和（无状态）DHCPv6服务器接收的信息上的一个很好的理由。
In theory, it should be relatively straightforward to write a configuration manager that would accept a single configuration specification from the service manager and distribute the correct (and consistent) configurations to the DHCPv4 and DHCPv6 servers (whether on the same host or not). In this case, maintaining coordinated configurations in two servers is an interface issue, not a protocol issue. The question then is whether the client has all the information it needs to make reasonable choices. We are aware of one implementation of separate DHCPv4 and DHCPv6 clients that is using a preference option for assisting client-side merging of the received information.
理论上，编写一个配置管理器应该相对简单，它将接受来自服务管理器的单个配置规范，并将正确（一致）的配置分发到DHCPv4和DHCPv6服务器（无论是否在同一主机上）。在这种情况下，在两台服务器中维护协调的配置是一个接口问题，而不是协议问题。接下来的问题是，客户是否拥有做出合理选择所需的所有信息。我们知道一个单独的DHCPv4和DHCPv6客户端的实现，它使用一个首选项来帮助客户端合并接收到的信息。
Another issue for discussion is whether a combined DHCP service only available over IPv6 transport is a desirable longer-term goal for networks containing only dual-stack or IPv6-only nodes (or IPv4-only nodes where DHCPv4 is not needed). The transition to the long-term position may easily take more than 10 years.
另一个需要讨论的问题是，对于仅包含双栈或仅包含IPv6节点（或不需要DHCPv4的仅包含IPv4节点）的网络，仅通过IPv6传输提供组合DHCP服务是否是一个理想的长期目标。过渡到长期职位可能需要10年以上的时间。
Upon reflection on the above observations, the dhc WG reached a strong consensus to adopt the two-server approach (separate DHCP and DHCPv6 servers), rather than have a combined single server returning IPv4 information over IPv6. The two servers may be co-located on a single node and may have consistent configuration information generated from a single asset database.
在对上述观察结果进行反思后，dhc工作组达成了强烈的共识，即采用两台服务器的方法（单独的DHCP和DHCPv6服务器），而不是使用一台通过IPv6返回IPv4信息的组合服务器。这两台服务器可能位于同一个节点上，并且可能具有从单个资产数据库生成的一致配置信息。
It should be noted that deployment experience of DHCPv6 is still in its infancy; thus, a full understanding of the issues may only develop over time, but we feel we have reached the best consensus given the current status. Future work is now required to determine best practice for merging information from multiple servers, including merger of lists of addresses where options carry such information.
应该注意的是，DHCPv6的部署经验仍处于初级阶段；因此，对这些问题的充分理解可能只会随着时间的推移而发展，但我们认为，鉴于目前的状况，我们已经达成了最佳共识。现在需要进一步的工作来确定合并来自多个服务器的信息的最佳实践，包括合并包含这些信息的选项的地址列表。
As a footnote, we note that this work has overlap with multihoming and multi-interface configuration issues. It is also interwoven with the Detecting Network Attachment area, for example, where a node may move from an IPv4-only network to a dual-stack network, or vice versa. Both aspects may be best abstracted for discussion and progression in the respective IETF multi6, shim6, and dna WGs, in parallel with the two-server progression in the dhc WG.
作为脚注，我们注意到这项工作与多主和多接口配置问题有重叠。它还与检测网络连接区域交织在一起，例如，节点可以从仅IPv4的网络移动到双栈网络，或者反之亦然。这两个方面最好在各自的IETF multi6、shim6和dna工作组中进行讨论和进展，与dhc工作组中的两个服务器进展并行。
There are no security considerations in this problem statement per se, as it does not propose a new protocol.
这个问题陈述本身没有安全考虑，因为它没有提出新的协议。
The authors thank the following people for input to this document: Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz, Changming Liu, Margaret Wasserman, Dave Thaler, Mark Hollinger, and Greg Daley. The document may not necessarily fully reflect the views of each of these individuals.
作者感谢以下人士对本文的贡献：Bernie Volz、AK Vijayabhaskar、Ted Lemon、Ralph Droms、Robert Elz、Liu Changming、Margaret Wasserman、Dave Thaler、Mark Hollinger和Greg Daley。该文件可能不一定完全反映这些个人的观点。
The authors would also like to thank colleagues on the 6NET project for contributions to this document.
作者还要感谢6NET项目的同事对本文件的贡献。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[3] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[4] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[5] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[5] Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[6] Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，2006年2月。
Authors' Addresses
作者地址
Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom
提姆南安普敦大学南安普顿电子与计算机科学学院，英国
EMail: tjc@ecs.soton.ac.uk
EMail: tjc@ecs.soton.ac.uk
Stig Venaas UNINETT Trondheim NO 7465 Norway
挪威第7465号特隆赫姆施蒂格·维纳斯酒店
EMail: venaas@uninett.no
EMail: venaas@uninett.no
Christian Strauf Clausthal University of Technology Erzstr. 51 Clausthal-Zellerfeld D-38678 Germany
克里斯蒂安.克劳塞尔理工大学51克劳塞尔·泽勒费尔德D-38678德国
EMail: strauf@rz.tu-clausthal.de
EMail: strauf@rz.tu-clausthal.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。