RFC 6939

Client Link-Layer Address Option in DHCPv6

📅 published May 2013, from ietf

RFC 6939 💖 Client Link-Layer Address Option in DHCPv6 🎀

Okay bestie, here's the deal with this one. It's from the IETF (Internet Engineering Task Force) 🌸 and it's a Standards Track doc, so it's an actual official spec, not just vibes. Written by G. Halwasia, S. Bhandari, and W. Dec (all from Cisco Systems) 👑. It's published with ISSN 2070-1721 and dated May 2013 🦋. It doesn't obsolete or update any other RFC, since there's no Obsoletes or Updates line in the header 🫶.

Abstract ✨

So this doc defines the format and mechanism for putting the client's link-layer address into DHCPv6 Relay-Forward messages 🧚. It does that by introducing a brand-new DHCPv6 Client Link-Layer Address option 💅.

Status of This Memo 📋

This is an Internet Standards Track document 🌈.

It's a product of the IETF, which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💜. If you want more on Internet Standards, check Section 2 of RFC 5741 🍓.

For info about the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6939 🔥.

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) as they stand on the date this document was published 📜. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💀.

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 🌸

Okay so this spec is an optional mechanism plus a related DHCPv6 option 🎀. Its whole purpose is to let first-hop DHCPv6 relay agents (the ones on the same link as the client) pass along the client's link-layer address in the DHCPv6 messages they send toward 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 🔥

Let's set the scene. DHCPv4 already has a way to specify the client link-layer address in the DHCPv4 message header 🦋. That header has htype and chaddr fields, which carry the client link-layer address type and the link-layer address, respectively [RFC2131]. The DHCPv4 server and the relay agent can then use that address in different ways 💜. In some deployments, DHCPv4 servers treat chaddr as a customer identifier and as a lookup key in the client lease database 👑.

Now, IPv6 is rolling out gradually on top of existing IPv4 networks, which gives us dual-stack networks 🌈. That means you'll get devices acting as both DHCPv4 and DHCPv6 clients 🧚. In service provider deployments, a typical DHCPv4 implementation uses the client link-layer address as one of the keys to build its DHCP client lease database 🍓. In dual-stack setups, operators need to associate DHCPv4 and DHCPv6 messages with the same client interface, based on an identifier that's common to that interface 🔥. The client link-layer address is exactly that kind of identifier 💖.

Here's the problem. The DHCPv6 specification [RFC3315] doesn't define a way to tell the DHCP server about the client link-layer address when the server isn't on the same network link as the client 💀. DHCPv6 says every client has to prepare and send a DHCP Unique Identifier (DUID) as its client identifier option in all DHCPv6 message exchanges 🎀. But none of those methods give you a simple way to pull out a client's link-layer address 🙈. So an operator who's running an existing DHCPv4 system with the client link-layer address as the customer identifier, and who wants to correlate DHCPv6 assignments using that same identifier, is stuck 😭.

[RFC4361] does describe a way to use the same DUID in both DHCPv4 and DHCPv6 🦋. Unfortunately, it requires changes to existing DHCPv4 clients, and it hasn't really caught on in the industry. The authors aren't aware of any commercial implementations at all 💅.

So putting the client link-layer address explicitly into an option in DHCPv6 Relay-Forward messages will help with all the scenarios above 🫶. For example, it can be used with other identifiers to associate DHCPv4 and DHCPv6 messages from a dual-stack client 👑. It also gives extra information for event debugging and logging about the client at the relay agent and the server 🌸. The proposed option can be used across a wide range of networks, and the two notable deployment models are service provider and enterprise network environments ✨.

Here's what the DHCPv6 Client Link-Layer Address option looks like 🧚:

      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

The link-layer type MUST be a valid hardware type assigned by IANA, as described in [RFC0826] 🔥. That's the rule, no skipping it 🙈.

5. DHCPv6 Relay Agent Behavior 🍓

DHCPv6 relay agents that receive messages from clients (for example Solicit and Request, but not Relay-Forward or Advertise, for instance) MAY include the link-layer source address of the received DHCPv6 message in the Client Link-Layer Address option, inside the relayed DHCPv6 Relay-Forward messages 🦋. Whether the option gets included can depend on configuration, so the relay agent behavior can change based on that setting 🌈.

6. DHCPv6 Server Behavior 🧚

If the DHCPv6 server is set up 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 from the DHCPv6 relay agent closest to the client 💜. This mechanism isn't needed when the DHCPv6 server is on the same network link as the client, because the server can grab the link-layer address from the link-layer header of the DHCPv6 message 👑.

And here's the important bit 🚨: if the DHCP server gets a Client Link-Layer Address option anywhere in an encapsulated message that isn't a Relay-Forward DHCP message, the server MUST silently ignore that option 💅.

The server must silently ignore the option in any encapsulated message that isn't Relay-Forward, so don't let it sneak in 🙈.

There's no requirement that a server send this option and its data back 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 don't even know the option exists 🙈. The DHCPv6 client MUST NOT send the Client Link-Layer Address option, and it MUST ignore the option if it gets received 💀.

8. IANA Considerations 🌈

IANA has assigned option code (79) to OPTION_CLIENT_LINKLAYER_ADDR from the "DHCP Option Codes" registry (http://www.iana.org/assignments/dhcpv6-parameters/) ✨.

9. Security Considerations 💀

Okay, this section is serious, so buckle up 😭. It's 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 that contains an incorrect Client Link-Layer Address option 👑. Either way, a DHCPv6 client could masquerade as the same device as a DHCPv4 client, even though the two are actually distinct 💜.

One possible attack using this masquerade: a DHCPv4 client uses DHCPv4 to do a Dynamic DNS update that installs an A record, so other nodes can reach it [RFC4702] 🦋. A masquerading DHCPv6 client could then use DHCPv6 to install a AAAA record with the same name [RFC4704] 🙈. Dual-stack nodes trying to connect to the DHCPv4 client might end up getting tricked into connecting to the masquerading DHCPv6 client instead 😱.

The authors aren't aware of any other attacks using this masquerading technique, but it's possible there are some 🌸. To prevent masquerades like this, DHCP server administrators are strongly advised to configure DHCP servers that use this option to talk to their relay agents using IPsec, as described in Section 21.1 of [RFC3315] 🫶.

In some networks, the operator of the physical network and the provider of connectivity over it might be administratively separate 🍓. In that case, the Client Link-Layer Address option could reveal information to one party that they don't need and couldn't otherwise get 👀. It's also possible that a relay agent talks to a DHCP server over an open network where eavesdropping is possible 🔥. In these cases, it is strongly recommended that network operators use IPsec to provide confidentiality for messages between the relay agent and the DHCP server, in order to protect end-user privacy 💖.

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 📚

The reference entries pick up in the next part 🧚.

11.1. Normative References 💜

11.2. Informative References 🌈

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.

okay so the normative references are the ones you HAVE to read to get this spec, bestie 🫶 [RFC0826] is the classic ARP one (STD 37, RFC 826, November 1982) 🦋 [RFC2119] is where the BCP 14 key words come from (BCP 14, RFC 2119, March 1997) 🌸 [RFC3315] is the original DHCPv6 spec (RFC 3315, July 2003) ✨ and [RFC4361] is the node-specific client identifier one for 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.

these are the "good to know, not required" ones 🍓 [RFC2131] is the original DHCPv4 spec, and [RFC4702] and [RFC4704] are the FQDN option ones, one for DHCPv4 and one for DHCPv6 💅 ngl the naming is very on-brand for the whole DHCP family 😭

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

the authors are the Cisco crew who wrote this, bestie 🦋 Gaurav Halwasia, Shwetha Bhandari, and Wojciech Dec 🌸 all of them at Cisco Systems, with their contact details right there so you can reach out 💌 ✨ that's the whole RFC, slay 👑💖

📦 where this page comes from