From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6939.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6939.txt (limited to 'doc/rfc/rfc6939.txt') diff --git a/doc/rfc/rfc6939.txt b/doc/rfc/rfc6939.txt new file mode 100644 index 0000000..9921a00 --- /dev/null +++ b/doc/rfc/rfc6939.txt @@ -0,0 +1,395 @@ + + + + + + +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 + +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. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + + + + + +Halwasia, et al. Standards Track [Page 1] + +RFC 6939 DHCPv6 Client Link-Layer Address Option May 2013 + + +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 + + 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. + +2. Requirements Language + + 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]. + +3. Problem Background and Scenario + + 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. + + 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 + + + + +Halwasia, et al. Standards Track [Page 2] + +RFC 6939 DHCPv6 Client Link-Layer Address Option May 2013 + + + 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. + + 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). + + 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. + + + + + + + + + + + + + + + + + + + + + +Halwasia, et al. Standards Track [Page 3] + +RFC 6939 DHCPv6 Client Link-Layer Address Option May 2013 + + +4. DHCPv6 Client Link-Layer Address Option + + The format of the DHCPv6 Client Link-Layer Address option is shown + below. + + 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 + +5. DHCPv6 Relay Agent Behavior + + 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. + +6. DHCPv6 Server Behavior + + 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. + + + + + +Halwasia, et al. Standards Track [Page 4] + +RFC 6939 DHCPv6 Client Link-Layer Address Option May 2013 + + + There is no requirement that a server return this option and its data + in a downstream DHCP message. + +7. DHCPv6 Client Behavior + + 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. + +8. IANA Considerations + + 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/). + +9. Security Considerations + + 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. + + 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. + + 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]. + + 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 + + + +Halwasia, et al. Standards Track [Page 5] + +RFC 6939 DHCPv6 Client Link-Layer Address Option May 2013 + + + 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. + +10. Acknowledgements + + 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. + +11. References + +11.1. Normative References + + [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. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client + Identifiers for Dynamic Host Configuration Protocol + Version Four (DHCPv4)", RFC 4361, February 2006. + +11.2. Informative References + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [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. + + [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for + IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) + Option", RFC 4704, October 2006. + + + + + + +Halwasia, et al. Standards Track [Page 6] + +RFC 6939 DHCPv6 Client Link-Layer Address Option May 2013 + + +Authors' Addresses + + Gaurav Halwasia + Cisco Systems + Cessna Business Park, Sarjapura Marathalli Outer Ring Road + Bangalore, KARNATAKA 560 087 + India + + 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 + + Phone: +91 80 4429 2627 + EMail: shwethab@cisco.com + + + Wojciech Dec + Cisco Systems + Haarlerbergweg 13-19 + 1101 CH Amsterdam, Amsterdam 560 087 + The Netherlands + + EMail: wdec@cisco.com + + + + + + + + + + + + + + + + + + + + + + +Halwasia, et al. Standards Track [Page 7] + -- cgit v1.2.3