Internet Engineering Task Force (IETF) G. Halwasia
Request for Comments: 6939 S. Bhandari
Category: Standards Track W. Dec
ISSN: 2070-1721 Cisco Systems
May 2013
Internet Engineering Task Force (IETF) G. Halwasia
Request for Comments: 6939 S. Bhandari
Category: Standards Track W. Dec
ISSN: 2070-1721 Cisco Systems
May 2013
Client Link-Layer Address Option in DHCPv6
DHCPv6中的客户端链接层地址选项
Abstract
摘要
This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.
本文档通过定义新的DHCPv6客户机链路层地址选项，指定用于编码DHCPv6中继转发消息中的客户机链路层地址的格式和机制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6939.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6939.
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. Requirements Language ...........................................2
3. Problem Background and Scenario .................................2
4. DHCPv6 Client Link-Layer Address Option .........................4
5. DHCPv6 Relay Agent Behavior .....................................4
6. DHCPv6 Server Behavior ..........................................4
7. DHCPv6 Client Behavior ..........................................5
8. IANA Considerations .............................................5
9. Security Considerations .........................................5
10. Acknowledgements ...............................................6
11. References .....................................................6
11.1. Normative References ......................................6
11.2. Informative References ....................................6
1. Introduction ....................................................2
2. Requirements Language ...........................................2
3. Problem Background and Scenario .................................2
4. DHCPv6 Client Link-Layer Address Option .........................4
5. DHCPv6 Relay Agent Behavior .....................................4
6. DHCPv6 Server Behavior ..........................................4
7. DHCPv6 Client Behavior ..........................................5
8. IANA Considerations .............................................5
9. Security Considerations .........................................5
10. Acknowledgements ...............................................6
11. References .....................................................6
11.1. Normative References ......................................6
11.2. Informative References ....................................6
This specification defines an optional mechanism and the related DHCPv6 option to allow first-hop DHCPv6 relay agents (relay agents that are connected to the same link as the client) to provide the client's link-layer address in the DHCPv6 messages being sent towards the server.
本规范定义了一种可选机制和相关的DHCPv6选项，以允许第一跳DHCPv6中继代理（与客户端连接到同一链路的中继代理）在发送到服务器的DHCPv6消息中提供客户端的链路层地址。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The DHCPv4 specification [RFC2131] provides a way to specify the client link-layer address in the DHCPv4 message header. A DHCPv4 message header has 'htype' and 'chaddr' fields to specify the client link-layer address type and the link-layer address, respectively. The client link-layer address thus learned can be used by the DHCPv4 server and the relay agent in different ways. In some of the deployments, DHCPv4 servers use 'chaddr' as a customer identifier and a key for lookup in the client lease database.
DHCPv4规范[RFC2131]提供了在DHCPv4消息头中指定客户端链路层地址的方法。DHCPv4消息头具有“htype”和“chaddr”字段，分别指定客户端链路层地址类型和链路层地址。由此学习的客户端链路层地址可由DHCPv4服务器和中继代理以不同的方式使用。在某些部署中，DHCPv4服务器使用“chaddr”作为客户标识符和在客户端租约数据库中查找的密钥。
With the incremental deployment of IPv6 to existing IPv4 networks, which results in a dual-stack network environment, there will be devices that act as both DHCPv4 and DHCPv6 clients. In service provider deployments, a typical DHCPv4 implementation will use the client link-layer address as one of the keys to build the DHCP client lease database. In dual-stack scenarios, operators need to be able
随着IPv6在现有IPv4网络中的增量部署，将形成双栈网络环境，将有一些设备同时充当DHCPv4和DHCPv6客户端。在服务提供商部署中，典型的DHCPv4实现将使用客户端链接层地址作为构建DHCP客户端租用数据库的密钥之一。在双堆栈场景中，操作员需要能够
to associate DHCPv4 and DHCPv6 messages with the same client interface, based on an identifier that is common to the interface. The client link-layer address is such an identifier.
根据接口通用的标识符，将DHCPv4和DHCPv6消息与同一客户机接口相关联。客户端链路层地址就是这样一个标识符。
Currently, the DHCPv6 specification [RFC3315] does not define a way to communicate the client link-layer address to the DHCP server in cases where the DHCP server is not connected to the same network link as the DHCP client. The DHCPv6 specification mandates that all clients prepare and send a DHCP Unique Identifier (DUID) as the client identifier option in all the DHCPv6 message exchanges. However, none of these methods provide a simple way to extract a client's link-layer address. This presents a problem to an operator who is using an existing DHCPv4 system with the client link-layer address as the customer identifier and who desires to correlate DHCPv6 assignments using the same identifier. [RFC4361] describes a mechanism for using the same DUID in both DHCPv4 and DHCPv6. Unfortunately, this specification requires modification of existing DHCPv4 clients, and has not seen broad adoption in the industry (indeed, we are not aware of any commercial implementations).
目前，DHCPv6规范[RFC3315]未定义在DHCP服务器未连接到与DHCP客户端相同的网络链路的情况下将客户端链路层地址传送到DHCP服务器的方法。DHCPv6规范要求所有客户端准备并发送一个DHCP唯一标识符（DUID），作为所有DHCPv6消息交换中的客户端标识符选项。但是，这些方法都不能提供提取客户端链接层地址的简单方法。这给正在使用现有DHCPv4系统且客户链路层地址作为客户标识符的操作员以及希望使用相同标识符关联DHCPv6分配的操作员带来了问题。[RFC4361]描述了在DHCPv4和DHCPv6中使用相同DUID的机制。不幸的是，该规范需要修改现有的DHCPv4客户机，并且尚未在业界得到广泛采用（事实上，我们不知道有任何商业实现）。
Providing an option in DHCPv6 Relay-Forward messages to carry the client link-layer address explicitly will help the above mentioned scenarios. For example, it can be used along with other identifiers to associate DHCPv4 and DHCPv6 messages from a dual-stack client. Further, having the client link-layer address in DHCPv6 will help by providing additional information for event debugging and logging related to the client at the relay agent and the server. The proposed option may be used in a wide range of networks; two notable deployment models are service provider and enterprise network environments.
在DHCPv6中继转发消息中提供一个选项来显式地携带客户端链路层地址，这将有助于上述场景。例如，它可以与其他标识符一起用于关联来自双堆栈客户端的DHCPv4和DHCPv6消息。此外，在DHCPv6中拥有客户机链接层地址将有助于在中继代理和服务器上提供与客户机相关的事件调试和日志记录的附加信息。建议的方案可用于广泛的网络；两种著名的部署模型是服务提供商和企业网络环境。
The format of the DHCPv6 Client Link-Layer Address option is shown below.
DHCPv6客户端链接层地址选项的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_LINKLAYER_ADDR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer type (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| link-layer address (variable length) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_LINKLAYER_ADDR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer type (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| link-layer address (variable length) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_CLIENT_LINKLAYER_ADDR (79) option-length: 2 + length of link-layer address link-layer type: Client link-layer address type. The link-layer type MUST be a valid hardware type assigned by the IANA, as described in [RFC0826] link-layer address: Client link-layer address
选项代码：选项\客户端\链接层\地址（79）选项长度：2+链接层地址长度链接层类型：客户端链接层地址类型。链路层类型必须是IANA分配的有效硬件类型，如[RFC0826]链路层地址：客户端链路层地址中所述
DHCPv6 relay agents that receive messages originating from clients (for example, Solicit and Request, but not, for example, Relay-Forward or Advertise) MAY include the link-layer source address of the received DHCPv6 message in the Client Link-Layer Address option, in relayed DHCPv6 Relay-Forward messages. The DHCPv6 relay agent behavior can depend on configuration that decides whether the Client Link-Layer Address option needs to be included.
接收来自客户端的消息（例如，请求和请求，但不包括，例如，转发或播发）的DHCPv6中继代理可以在中继DHCPv6中继转发消息的客户端链路层地址选项中包括接收到的DHCPv6消息的链路层源地址。DHCPv6中继代理行为可能取决于决定是否需要包括客户端链路层地址选项的配置。
If the DHCPv6 server is configured to store or use a client link-layer address, it SHOULD look for the Client Link-Layer Address option in the Relay-Forward DHCP message of the DHCPv6 relay agent closest to the client. The mechanism described in this document is not necessary in the case where the DHCPv6 server is connected to the same network link as the client, because the server can obtain the link-layer address from the link-layer header of the DHCPv6 message. If the DHCP server receives a Client Link-Layer Address option anywhere in any encapsulated message that is not a Relay-Forward DHCP message, the server MUST silently ignore that option.
如果将DHCPv6服务器配置为存储或使用客户端链路层地址，则应在距离客户端最近的DHCPv6中继代理的中继转发DHCP消息中查找客户端链路层地址选项。如果DHCPv6服务器连接到与客户端相同的网络链路，则不需要本文档中描述的机制，因为服务器可以从DHCPv6消息的链路层头获取链路层地址。如果DHCP服务器在非中继转发DHCP消息的任何封装消息中的任何位置接收到客户端链路层地址选项，则服务器必须以静默方式忽略该选项。
There is no requirement that a server return this option and its data in a downstream DHCP message.
不要求服务器在下游DHCP消息中返回此选项及其数据。
The Client Link-Layer Address option is only exchanged between the relay agents and the servers. DHCPv6 clients are not aware of the usage of the Client Link-Layer Address option. The DHCPv6 client MUST NOT send the Client Link-Layer Address option, and MUST ignore the Client Link-Layer Address option if received.
客户端链路层地址选项仅在中继代理和服务器之间交换。DHCPv6客户端不知道客户端链接层地址选项的用法。DHCPv6客户端不得发送客户端链接层地址选项，如果收到，则必须忽略客户端链接层地址选项。
IANA has assigned an option code (79) to OPTION_CLIENT_LINKLAYER_ADDR from the "DHCP Option Codes" registry (http://www.iana.org/assignments/dhcpv6-parameters/).
IANA已从“DHCP选项代码”注册表为选项\客户端\链接层\地址分配了选项代码（79）(http://www.iana.org/assignments/dhcpv6-parameters/).
It is possible for a rogue DHCPv6 relay agent to insert an incorrect Client Link-Layer Address option for malicious purposes. A DHCPv6 client can also pose as a rogue DHCP relay agent by sending a Relay-Forward message containing an incorrect Client Link-Layer Address option. In either case, it would be possible for a DHCPv6 client to masquerade as the same device as a DHCPv4 client, when in fact the two are distinct.
恶意DHCPv6中继代理可能出于恶意目的插入错误的客户端链路层地址选项。DHCPv6客户端还可以通过发送包含不正确的客户端链路层地址选项的中继转发消息来冒充恶意DHCP中继代理。在任何一种情况下，DHCPv6客户机都可能伪装成与DHCPv4客户机相同的设备，而实际上两者是不同的。
One possible attack that could be accomplished using this masquerade would be in the case where a DHCPv4 client is using DHCPv4 to do a Dynamic DNS update to install an A record so that it can be reached by other nodes [RFC4702]. A masquerading DHCPv6 client could use DHCPv6 to install a AAAA record with the same name [RFC4704]. Dual-stack nodes attempting to connect to the DHCPv4 client might then be tricked into connecting to the masquerading DHCPv6 client instead.
使用此伪装可以实现的一种可能的攻击是，DHCPv4客户端使用DHCPv4执行动态DNS更新以安装a记录，以便其他节点可以访问该记录[RFC4702]。伪装的DHCPv6客户端可以使用DHCPv6安装具有相同名称[RFC4704]的AAAA记录。尝试连接到DHCPv4客户机的双堆栈节点可能会被欺骗，转而连接到伪装的DHCPv6客户机。
It is possible that there are other attacks that could be accomplished using this masquerading technique, although the authors are not aware of any. To prevent masquerades of this sort, DHCP server administrators are strongly advised to configure DHCP servers that use this option to communicate with their relay agents using IPsec, as described in Section 21.1 of [RFC3315].
使用这种伪装技术可能还可以实现其他攻击，尽管作者不知道有任何攻击。为防止此类伪装，强烈建议DHCP服务器管理员配置使用此选项的DHCP服务器，以使用IPsec与其中继代理进行通信，如[RFC3315]第21.1节所述。
In some networks, it may be the case that the operator of the physical network and the provider of connectivity over that network are administratively separate, such that the Client Link-Layer Address option would reveal information to one or the other party that they do not need and could not otherwise obtain. It is also possible, in some cases, that a relay agent might communicate with a
在一些网络中，可能存在这样的情况，即物理网络的运营商和该网络上的连接提供商在管理上是分离的，使得客户机链路层地址选项将向一方或另一方揭示他们不需要并且不能以其他方式获得的信息。在某些情况下，中继代理也可能与服务器进行通信
DHCP server over an open network where eavesdropping would be possible. In these cases, it is strongly recommended, in order to protect end-user privacy, that network operators use IPsec to provide confidentiality for messages between the relay agent and the DHCP server.
DHCP服务器通过一个开放的网络进行窃听。在这些情况下，强烈建议网络运营商使用IPsec为中继代理和DHCP服务器之间的消息提供机密性，以保护最终用户隐私。
Many thanks to Ted Lemon, Bernie Volz, Hemant Singh, Simon Hobson, Tina TSOU, Andre Kostur, Chuck Anderson, Steinar Haug, Niall O'Reilly, Jarrod Johnson, Tomek Mrugalski, and Vincent Zimmer for their input and review.
非常感谢Ted Lemon、Bernie Volz、Hemant Singh、Simon Hobson、Tina TSOU、Andre Kostur、Chuck Anderson、Steinar Haug、Niall O'Reilly、Jarrod Johnson、Tomek Mrugalski和Vincent Zimmer的投入和评论。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361]Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，2006年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, October 2006.
[RFC4702]Stapp，M.，Volz，B.，和Y.Rekhter，“动态主机配置协议（DHCP）客户端完全限定域名（FQDN）选项”，RFC 4702，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月。
Authors' Addresses
作者地址
Gaurav Halwasia Cisco Systems Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India
印度卡纳塔克邦班加罗尔Sarjapura Maratalli外环路Gaurav Halwasia Cisco Systems Cessna商业园560087
Phone: +91 80 4429 2703
EMail: ghalwasi@cisco.com
Phone: +91 80 4429 2703
EMail: ghalwasi@cisco.com
Shwetha Bhandari Cisco Systems Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India
印度卡纳塔克邦班加罗尔Sarjapura Maratalli外环路Shwetha Bhandari Cisco Systems Cessna商业园560087
Phone: +91 80 4429 2627
EMail: shwethab@cisco.com
Phone: +91 80 4429 2627
EMail: shwethab@cisco.com
Wojciech Dec Cisco Systems Haarlerbergweg 13-19 1101 CH Amsterdam, Amsterdam 560 087 The Netherlands
Wojciech Dec思科系统哈勒贝格韦格13-19 1101中国阿姆斯特丹，荷兰阿姆斯特丹560087
EMail: wdec@cisco.com
EMail: wdec@cisco.com