RFC 6221
Lightweight DHCPv6 Relay Agent
RFC 6221: Lightweight DHCPv6 Relay Agent 🦋 (part 1 of 3)
okay so this one is from May 2011, it's a Standards Track doc (so it's official, not just vibes 💅), and the editor is D. Miles, with S. Ooghe, W. Dec, S. Krishnan, and A. Kavanagh 🫶. They're from Alcatel-Lucent, Cisco Systems, and Ericsson. It's published in the IETF stream with ISSN 2070-1721, and it updates RFC 3315 (that's the main DHCPv6 spec, so this one is building on it). The official status info lives at http://www.rfc-editor.org/info/rfc6221 🔗
Abstract 🦋
okay bestie, the big idea is a Lightweight DHCPv6 Relay Agent (LDRA) ✨. Its whole job is sticking relay agent options onto DHCPv6 messages so they can say which client-facing interface things came from 💖. The really iconic part is that it can live in existing access nodes like DSLAMs and Ethernet switches, even when those boxes can't do any IPv6 control or routing stuff 🙈.
Status of This Memo
this is an Internet Standards Track document 💅. It came out of the IETF, it represents what the IETF community agreed on, it got public review, and the IESG approved it for publication 🔥. If you want the deeper info on Internet Standards, check Section 2 of RFC 5741. For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6221 ✨.
Copyright Notice
© vibes: Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🌈. This doc 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 publication date. Read those carefully, because they're your rights and restrictions 👑. Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🧚.
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Background ......................................................3
3. Terminology .....................................................3
4. Server Considerations ...........................................5
5. Message Format ..................................................5
5.1. Relay-Forward Message ......................................5
5.2. Relay-Reply Message ........................................6
5.3. Mandatory DHCP Options .....................................6
5.3.1. Relay-Message Option ................................6
5.3.2. Interface-ID Option .................................6
6. Agent Behaviour .................................................7
6.1. Relaying a Client Message ..................................7
6.1.1. Client Message Validation ...........................8
6.1.2. Trusted and Untrusted Interfaces ....................8
6.2. Relaying a Relay-Reply Message from the Network ............8
7. Network Topology ................................................9
7.1. Client and Server on Same Link .............................9
7.2. Client and Server behind Relay Agent ......................11
7.3. Relay Agent in Front of LDRA ..............................12
8. Contributors ...................................................15
9. Security Considerations ........................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................161. Introduction ✨
okay so DHCPv6 Relay Agents [RFC3315] get deployed to forward DHCPv6 messages between clients and servers when they're not on the same IPv6 link 🦋. They often live right alongside a routing function in the same node. The LDRA is the lowkey version: it lets an access node that just does link-layer bridging (no routing, no vibes) insert Relay Agent Information 💅. An LDRA sits on the same IPv6 link as the client and a DHCPv6 Relay Agent or server, and it's basically the same thing as the Layer 2 Relay Agent proposed for DHCPv4 in [L2RA] 🫶.
Unlike a DHCPv6 Relay Agent from [RFC3315], an LDRA doesn't implement any IPv6 control functions (ICMPv6, for example) and doesn't have any routing capability in the node 🙈.
1.1. 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 read as described in RFC 2119 [RFC2119] 🎀.
2. Background 🌸
so there are lots of different link-layer topologies for aggregating IPv6 nodes into one or more routers 🌈. In Layer 2 aggregation networks (IEEE 802.1D bridging or something similar) with tons of nodes on one link, a DHCPv6 server or DHCP Relay Agent would normally have no clue how a DHCP client is plugged into the network 💀. The LDRA fixes that by letting the access node insert Relay Agent Information, including the Interface-ID option [RFC3315], so the DHCPv6 server can actually identify the client 🔥. A typical use case for a broadband service provider is basically the same as a Layer 2 DHCP Relay Agent, as described in the Broadband Forum TR-101 report [TR-101] and in [L2RA] 🦋.
3. Terminology 🧚
the terms are laid out in this table, which stays exactly as it is 💖:
Access Node A device that combines many interfaces onto
one link. An access node is not IP-aware
in the data path.
Address An IP layer identifier for an interface or
set of interfaces.
Client-facing An interface on the access node that
carries traffic towards the DHCPv6 client.
Host A non-routing IPv6 node that is
participating in a DHCPv6 message exchange.
IP Internet Protocol Version 6 (IPv6).
LDRA Lightweight DHCPv6 Relay Agent.
Lightweight Relay Agent A function on the access node that
intercepts DHCP messages between clients
and servers. The function exists as a bump
in the wire on the IP link.
Link A communication facility or medium over
which nodes can communicate at the link
layer.
Link-local address An IP address having only local scope,
indicated by having the address prefix
fe80::/10, that can be used to reach
neighbouring nodes attached to the same
link. Every interface has a link-local
address.
Network-facing An interface on the access node that
carries traffic towards the DHCPv6
server(s).
Node A device that implements IPv6.
Router A node that forwards packets not directly
addressed to itself.
Relay Agent A node that acts as an intermediary to
deliver DHCP messages between clients and
servers and being on the same link as the
client.
Unspecified address An IPv6 address that is comprised entirely
of zeros.4. Server Considerations 💅
this doc updates the behaviour specified in Section 11 of DHCP for IPv6 [RFC3315] 🫶. RFC 3315 says, in part:
If the server receives the message from a forwarding relay agent,
then the client is on the same link as the one to which the
interface, identified by the link-address field in the message
from the relay agent, is attached.so DHCP server implementations that conform to this spec MUST, for address selection, ignore any link-address field whose value is zero 🙈. And in the text from RFC 3315 above, "link-address" means both the link-address field of the Relay-Forward message and the link-address fields in any Relay-Forward messages nested inside it 🧚.
5. Message Format 🎀
the Lightweight DHCPv6 Relay Agent (LDRA) swaps DHCP messages between clients and servers using the message formats from [RFC3315] ✨. For interoperability with existing DHCP relays and servers, the message format is unchanged from [RFC3315] 💖. The LDRA implements the same message types as a normal DHCPv6 Relay Agent, which are:
- Relay-Forward Messages
- Relay-Reply Messages
5.1. Relay-Forward Message 🦋
the Relay-Forward message gets created by any DHCPv6 Relay Agent (LDRAs included) to forward messages between clients and servers or other relay agents 🌸. These messages are built as specified in [RFC3315] 💅.
the Relay-Forward message carries relay agent parameters that identify the client-facing interface where any reply messages should be forwarded 🔥. Those parameters are link-address, peer-address, and Interface-ID 👑. The link-address parameter MUST be set to the unspecified address. The peer-address parameter MUST be set as specified in Section 6.1. The Interface-ID Relay Agent option MUST be included in the Relay-Forward message. The LDRA MAY insert additional relay agent options 🫶.
5.2. Relay-Reply Message 🧚
the Relay-Reply message is built by a DHCPv6 server to send parameters to a DHCP client when a relay agent sits between the server and the client 🌈. It can be sent after an initial Relay-Forward message, because the parameters link-address, peer-address, and Interface-ID, plus the relay agent's IP address, are learnt from the Relay-Forward message ✨.
The server MUST include the Interface-ID option in the Relay-Reply Message so the LDRA knows which interface the decapsulated message should go out on 💖.
5.3. Mandatory DHCP Options 💅
parameters get swapped between the DHCP client, Relay Agent, and server through DHCP options 🦋. There's a set of mandatory DHCP options that MUST be included by the LDRA in all Relay-Forward messages. They are:
- Relay-Message Option
- Interface-ID Option
5.3.1. Relay-Message Option 🎀
a DHCPv6 Relay Agent relays messages between clients and servers (or other relay agents) through Relay-Forward and Relay-Reply message types 🌸. The original client DHCP message (the packet payload, excluding the UDP and IP headers) gets encapsulated in a Relay Message option [RFC3315] ✨.
⚠️ if a Relay-Message would be bigger than the MTU of the outgoing interface, it MUST be discarded, and an error condition SHOULD be logged. no cap, don't let it slide 💀
5.3.2. Interface-ID Option
okay so the Interface-ID option is giving main character energy 🦋 The LDRA MUST include the Interface-ID option [RFC3315] in every single Relay-Forward message 🫶 no exceptions. And when an LDRA gets a Relay-Reply with an Interface-ID option present and the link-address unspecified, the LDRA MUST relay the decapsulated message to the client on the interface named in that Interface-ID option 🎀
Servers MAY use the Interface-ID for parameter assignment policies ✨ The format of the Interface-ID is outside the scope of this contribution, so we're not going there 💅 The Interface-ID SHOULD be considered an opaque value; i.e., the server SHOULD NOT try to parse the contents of the Interface-ID option 🙈 The LDRA SHOULD use the same Interface-ID value for a given interface, and this value SHOULD be retained across restarts. This is because if the Interface-ID changes, a server will not be able to use it reliably in parameter assignment policies 🥺
6. Agent Behaviour 🌸
The LDRA MUST have each of its interfaces configured as either client-facing or network-facing 🧚 The LDRA uses the notion of client-facing and network-facing interfaces to process DHCPv6 messages, so this split is literally the whole game 👑
6.1. Relaying a Client Message 💖
The LDRA MUST intercept and process all IP traffic received on any client-facing interface that has:
- destination IP address set to All_DHCP_Relay_Agents_and_Servers (ff02::1:2);
- protocol type UDP; and
- destination port 547.
The LDRA MUST also prevent the original message from being forwarded on the network-facing interface 🚫
The lightweight relay agent adds any other options it is configured or required to include in the Relay-Forward message ✨ The LDRA MUST set the link-address field of the Relay-Forward message to the Unspecified Address (::) and MUST include the Interface-ID option in all DHCP Relay-Forward messages. Iconic 🦋
If the message received on the client-facing interface is a Relay-Forward message, the LDRA MUST set the hop-count field in the newly created Relay-Forward message to the value of the hop-count field in the received message, incremented by 1 as specified in [RFC3315] 🔢
The LDRA MUST copy the IP destination and link-layer destination addresses from the client-originated message into the IP destination address and link-layer destination address of the Relay-Forward message 📬
The LDRA MUST copy the IP source address from the client-originated message into the peer-address field of the Relay-Forward message. The LDRA MUST copy the link-layer source address from the client-originated message into the link-layer source address of the Relay-Forward message 💜
6.1.1. Client Message Validation 🧐
On receipt of a DHCP message on a client-facing interface, the LDRA MUST discard a message if it is of one of the following message types:
- ADVERTISE (2)
- REPLY (7)
- RECONFIGURE (10)
- RELAY-REPL (13)
Options contained in the DHCPv6 message MUST NOT be validated by the LDRA 🙅♀️ That's the DHCP server's job, which means it can check message option validity and let new options roll out without anyone touching the LDRA. Low-key genius 🍓
6.1.2. Trusted and Untrusted Interfaces 🔒
Okay, flashback time. In [RFC3046], DHCPv4 Relay Agents had their client-facing interfaces set to "trusted" and "untrusted" 🕰️ An LDRA MUST implement a configuration setting for all client-facing interfaces, marking them either as trusted or as untrusted. This setting SHOULD be configurable per interface. When a client-facing interface is deemed untrusted, the LDRA MUST discard any message of type RELAY-FORW (12) received from the client-facing interface 🚨
6.2. Relaying a Relay-Reply Message from the Network 📡
The LDRA MUST intercept and process all IP traffic received on the network-facing interface that has:
- a link-local scoped source address;
- a link-local scoped destination address;
- protocol type UDP; and
- destination port 547
An LDRA MUST inspect the DHCP message type and only forward Relay-Reply messages. Other DHCP message types MUST be silently discarded 🗑️
The Relay-Reply message is considered valid by the LDRA if it passes the validity checks to be performed by a relay agent per [RFC3315] and:
- the Interface-ID option is present, and the value corresponds to a valid interface in the access node;
- the Relay-Reply peer-address and the destination IP address are identical, and it is a link-local scoped address when no IP address is configured on the LDRA; and
- the link-address is the Unspecified Address when no IP address is configured on the LDRA.
If the Relay-Reply message is valid, the LDRA copies the peer-address into the destination IP address field ✅ The LDRA SHOULD forward the packet to the correct client-facing interface using the destination link-layer (Media Access Control (MAC)) address or the Interface-ID in the Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other interface, because nobody needs that drama 🙅♀️ The contents of the Relay Message option are put into an IP/UDP packet and then forwarded to the client 📦
The LDRA MUST copy the link-layer and IP source address from the Relay-Reply message into the IP/UDP packet that is forwarded to the client 💌
7. Network Topology 🗺️
The LDRA intercepts any DHCPv6 message received on client-facing interfaces with the traffic pattern specified in Section 6.1. The LDRA MUST NOT forward the original client message to a network-facing interface; it MUST process the message and add the appropriate Relay-Forward options as described in previous sections 🙌
7.1. Client and Server on Same Link 🫧
The access node acts as a bridge; it has no information about any IP prefixes that are valid on the link 🌉 Thus, a server should consider address and parameter assignment as if the client DHCP message were not relayed.
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+
|------| Server |
| +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<--------- IPv6 Link -------->For example, if a client sent a DHCP Solicit message that was relayed by the LDRA to the server, the server would receive the following Relay-Forward message from the LDRA 👀
src-ip: client link-local address
dst-ip: All_DHCP_Relay_Agents_and_Servers
msg-type: RELAY-FORW
hop-count: 0
link-address: Unspecified_Address
peer-address: client link-local address
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: SOLICIT
Solicit Message Options: <from client>7.2. Client and Server behind Relay Agent 🚀
The client and server are on different IPv6 links, separated by one or more relay agents that will typically act as a router. The LDRA will send Relay-Forward messages upstream towards the second relay agent, which in turn will process the messages 💫
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->For example, if a client sent a DHCP Solicit message that was relayed by the LDRA to another relay agent and then to the server, the server would receive the following Relay-Forward message from the LDRA 📨
src-ip: relayB
dst-ip: server
msg-type: RELAY-FORW
hop-count: 1
link-address: relayB address from link A
peer-address: client link-local address
Relay-Message Option, which contains:
msg-type: RELAY-FORW
hop-count: 0
link-address: Unspecified_Address
peer-address: client link-local address
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: SOLICIT
Solicit Message Options: <from client>7.3. Relay Agent in Front of LDRA 🍭
The client and server are on different IPv6 links, separated by one or more relay agents that will typically act as a router, and there is an [RFC3315] Relay Agent on the client-facing interface of the LDRA. The LDRA will send Relay-Forward messages upstream towards the second relay agent, which in turn will process the messages 🧃
+--------+
RelayC -------| |
| Access |
RelayC -------| Node |-----+
| (LDRA) | |
RelayC -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
RelayC -------| | |
| Access | |
RelayC -------| Node |-----+
| (LDRA) |
RelayC -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->For example, if a client sent a DHCP Solicit message that was relayed by RelayC and the LDRA to another relay agent, RelayB, and then to the server, the server would receive the following Relay-Forward message 🧠
src-ip: relayB
dst-ip: server
msg-type: RELAY-FORW
hop-count: 2
link-address: relayB address from link A
peer-address: relayC
Relay-Message Option, which contains:
msg-type: RELAY-FORW
hop-count: 1
link-address: Unspecified_Address
peer-address: relayC
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: RELAY-FORW
hop-count: 0
link-address: global or Unspecified_Address
peer-address: end client address
Interface-ID Option: (if required)
interface-id: relayC-inserted Interface-ID
Relay-Message Option, which contains:
msg-type: SOLICIT
Solicit Message Options: <from end client>8. Contributors 💜
The authors would like to thank the following for their support: Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij, Alfred Hoenes, Ted Lemon, Tatuya Jinmei, David Hankins, and Ralph Droms 🫶🌈
Comments are solicited and should be addressed to the DHC WG mailing list (dhcwg@ietf.org) and/or the authors 📬
9. Security Considerations 🔒✨
okay bestie, this section is serious but also lowkey iconic 💅. Everything from [RFC3315] about DHCPv6 Relay Agents' security issues still applies to LDRAs, no cap 🫶. Your LDRA SHOULD implement some form of rate-limiting on client-originated traffic so it doesn't eat up all the processing power 💀. The good news is it's super easy to spot what to limit: an LDRA only listens to client-originated IPv6 traffic sent to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, and it doesn't process any other client-originated traffic at all 🧚. Since DHCP is session-oriented, any messages over the rate-limit may be silently discarded 🌸.
⚠️ The hop-count-based way of deciding whether an LDRA is trustworthy can be easily defeated by a rogue relay agent on the network-facing interface of the LDRA. Not me being dramatic, this is a real vulnerability 😭.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.10.2. Informative References
[L2RA] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
Information", Work in Progress, April 2011.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
Aggregation", Technical Report TR-101, April 2006.Authors' Addresses 🎀
the squad behind this spec, with all their contact details, iykyk 🦋
David Miles (editor)
Alcatel-Lucent
L3 / 215 Spring St.
Melbourne, Victoria 3000
Australia
Phone: +61 3 9664 3308
EMail: david.miles@alcatel-lucent.com
Sven Ooghe
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp,
Belgium
EMail: sven.ooghe@alcatel-lucent.com
Wojciech Dec
Cisco Systems
Haarlerberdweg 13-19
1101 CH Amsterdam,
The Netherlands
EMail: wdec@cisco.com
Suresh Krishnan
Ericsson
8400 Blvd. Decarie
Town of Mount Royal, Quebec
Canada
EMail: suresh.krishnan@ericsson.com
Alan Kavanagh
Ericsson
8400 Blvd. Decarie
Town of Mount Royal, Quebec
Canada
EMail: alan.kavanagh@ericsson.comthat's the whole RFC, bestie 🌈👑 we did it!!
📦 where this page comes from
- ietf: rfc6221 2011-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms