RFC 3046
DHCP Relay Agent Information Option
RFC 3046: DHCP Relay Agent Information Option 🎀
okay bestie, this is part 1 of 3 ✨
Network Working Group 🌸 this one is from the IETF gang
Author: M. Patrick, from Motorola BCS 💖
Category: Standards Track, which means it's an official protocol spec 👑
Date: January 2001 🦋
Obsoletes / Updates: none listed in the title block, so this doc doesn't replace or change any older RFC 🧚
Status of this Memo
okay so this doc is an Internet standards track protocol for the whole Internet community 🌈 it's also asking everyone for discussion and suggestions for improvements 💅 if you want to know where this protocol stands officially, check the current "Internet Official Protocol Standards" (STD 1) list. distribution of this memo is unlimited, so share it as much as you want 🫶
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. ©️✨
Abstract
okay this is the big-picture tea ☕ fast public Internet access is getting faster, and the high-speed modem now has a LAN connection that feeds one or more customer premise hosts 🔥 it would be super convenient to use DHCP (RFC 2131) to hand out IP addresses to those customer hosts 💖 the problem is that doing this in a public setting causes a bunch of security and scaling headaches 😭 this document introduces a brand new DHCP option to fix that, and it extends the DHCP options set from RFC 2132 🦋
the new option is called the Relay Agent Information option. the DHCP relay agent slips it into client-originated DHCP packets when it forwards them to a DHCP server 🧚 servers that recognize it can use the info to make IP address or other parameter assignment decisions 🎀 the DHCP Server echoes the option back to the relay agent verbatim in server-to-client replies, and then the relay agent strips it out before the reply reaches the client 💅
the "Relay Agent Information" option is one single DHCP option that holds one or more "sub-options," and those sub-options carry info the relay agent knows 🌸 the first sub-options are meant for a relay agent sitting in a public circuit access unit. they include a "circuit ID" for the incoming circuit and a "remote ID," which is a trusted identifier for the remote high-speed modem 🫶 main character energy, honestly ✨
Table of Contents
1 Introduction........................................... 2
1.1 High-Speed Circuit Switched Data Networks.............. 2
1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4
2.0 Relay Agent Information Option......................... 5
2.1 Agent Operation........................................ 6
2.1.1 Reforwarded DHCP requests............................ 7
2.2 Server Operation....................................... 7
3.0 Relay Agent Information Suboptions..................... 8
3.1 Agent Circuit ID....................................... 8
3.2 Agent Remote ID........................................ 9
4.0 Issues Resolved........................................ 9
5.0 Security Considerations................................ 10
6.0 IANA Considerations.................................... 11
7.0 Intellectual Property Notice........................... 12
8.0 References............................................. 12
9.0 Glossary............................................... 13
10.0 Author's Address...................................... 13
11.0 Full Copyright Statement ............................. 141 Introduction
1.1 High-Speed Circuit Switched Data Networks
so the setup 💜 public Internet access usually runs over a circuit switched data network. today that's mostly dial-up modems hooked up to a Remote Access Server 📞 but the faster circuit access networks include ISDN, ATM, Frame Relay, and Cable Data Networks too 🌈 they're all basically a "star" shape, where lots of users connect to a "circuit access unit" through switched or permanent circuits ⭐
with dial-up modems, only one host PC ever connects to the central point 🧚 PPP is the go-to protocol for handing out IP addresses to that one PC 💖
the newer high-speed circuits often come with a LAN interface (Ethernet, especially) that can serve one or more host PCs 🔥 it's really desirable to hand out IP addresses to those hosts from one central place using DHCP 👑 the DHCP server can be co-implemented with the central circuit concentration access device, but usually it isn't 🙈 it's more often a separate server on the "Central LAN" that the central access device (or devices) plug into 🫶
here's the common physical model for high-speed Internet circuit access, shown in Figure 1 🦋
+---------------+ |
Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A
LAN | | Access | Lan |- Host B
| | Unit 1 | |- Host C
|-----| |-- |
| |(relay agent) |...
+---------+ | +---------------+
| DHCP |--|
| Server | |
+---------+ |
|
| +---------------+
+---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D
| Other | | | Access | Lan
| Servers |--|-----| Unit 2 |
| (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E
| DNS) | | |(relay agent) |... Lan
| | +---------------+
+---------+Figure 1: DHCP High Speed Circuit Access Model
ngl this part is so clever 🙈 in this model, the "modem" hooks up to a LAN at the user's site instead of a single host, so there are multiple hosts at that site 💅 you could put a full IP router at the user site, but that's a pretty pricey piece of gear compared to a normal modem 💸 a router also needs its own IP address on top of one for every host 🌸 and a user-side router needs its own dedicated Logical IP Subnet (LIS) for each user 😭 this setup works fine for smaller corporate networks, but it's not the move for big public access networks 🚫 the better play is an IP networking model that doesn't give the modem (or any other networking gear at the user site) an IP address, and definitely doesn't give the user-side LAN a whole LIS 🧚✨
one thing to keep in mind: getting IP addresses this way only works while you can actually talk to the central site 📡 some host LAN setups might use a local DHCP server or other methods to get in-house IP addresses instead 🏠
1.2 DHCP Relay Agent in the Circuit Access Unit
okay so it's really desirable to use DHCP to assign IP addresses for public high-speed circuit access 🌈 a bunch of circuit access units (things like RAS's, cable modem termination systems, ADSL access units, and so on) connect to a LAN (or local internet) that has a DHCP server attached 🫶
for scaling and security reasons, it's advantageous to build a "router hop" into the circuit access unit, kind of like high-capacity RAS's already do 💜 the circuit access equipment acts as a router toward the circuits and as the DHCP relay agent 👑
putting the DHCP relay agent in the same box as the circuit access equipment has some big perks 🎀
- DHCP broadcast replies can be routed to only the correct circuit 🦋 that stops them from getting copied onto thousands of access circuits, which would be chaos 😭
- the same mechanism that identifies the remote connection of the circuit (like a user ID that a Remote Access Server requests as the circuit access equipment) can also be used as a host identifier by DHCP, and for parameter assignment 🧚 that includes centralized assignment of IP addresses to hosts 🔥 it gives you a secure remote ID from a trusted source, the relay agent 🫶
forwarding DHCP requests from hosts on public high-speed circuits with LAN connections at the host brings up a bunch of issues 🙈 most of them are security problems that come from DHCP client requests from untrusted sources 💀 here are the big questions:
- how does the relay agent know which circuit to send replies back to? 🌸
- how does the system prevent DHCP IP exhaustion attacks? that's when an attacker grabs every available IP address from a DHCP server by sending requests with fabricated client MAC addresses 😱
- how can an IP address or LIS be permanently assigned to a particular user or modem? 🦋
- how does one prevent "spoofing" of the client identifier fields that are used to assign IP addresses? 🙅♀️
- how does one prevent denial of service by "spoofing" other clients' MAC addresses? 💀
the good news is all of these can be handled by having the circuit access equipment (a trusted component) add info to the DHCP client requests it forwards to the DHCP server 💖 it's literally the whole plan 👑
2.0 Relay Agent Information Option
okay this is the main event 🎀 this document defines a new DHCP Option called the Relay Agent Information Option 🧚 it's a "container" option for agent-supplied sub-options 📦 the format of the Relay Agent Information option looks like this 💅
Code Len Agent Information Field
+------+------+------+------+------+------+--...-+------+
| 82 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+the length N is the total number of octets in the Agent Information Field 🌸 the Agent Information field is a sequence of SubOpt/Length/Value tuples, one for each sub-option, encoded like this 🫶
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+heads up, these rules are strict 🚨 no "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option 🙅♀️ the length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples 🧮 since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2) ✌️ the length N of the sub-options shall be the number of octets in only that sub-option's value field 💜 a sub-option length may be zero 🌈 and the sub-options don't need to show up in sub-option code order 🦋
the initial assignment of DHCP Relay Agent Sub-options goes like this 👑
DHCP Agent Sub-Option Description
Sub-option Code
--------------- ----------------------
1 Agent Circuit ID Sub-option
2 Agent Remote ID Sub-optionpart 1 done, bestie 🌈💖✨
2.1 Agent Operation 🎀
okay so adding the DHCP relay agent option SHOULD be configurable, and it SHOULD be disabled by default 💅 Relay agents SHOULD also have separate configurables for each sub-option, so they can control whether each one gets added to client-to-server packets ✨
A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last option (but before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server. 🦋
Relay agents receiving a DHCP packet from an untrusted circuit with giaddr set to zero (meaning they're the first-hop router) but already holding a Relay Agent Information option in the packet SHALL discard the packet and increment an error count. 🙈 Now, a trusted circuit may contain a trusted downstream (closer to client) network element (bridge) between the relay agent and the client, and that element MAY add a relay agent option but not set the giaddr field. In this case the relay agent does NOT add a "second" relay agent option. It just forwards the DHCP packet per normal DHCP relay agent operations, setting the giaddr field as it deems appropriate 💖
The way "trusted" and "untrusted" circuits get sorted out is specific to the type of circuit termination equipment, and it may involve local administration. For example, a Cable Modem Termination System may consider upstream packets from most cable modems as "untrusted," but an ATM switch terminating VCs switched through a DSLAM may consider such VCs as "trusted" and accept a relay agent option added by the DSLAM 🌸
Relay agents MAY have a configurable for the maximum size of the DHCP packet to be created after appending the Agent Information option. Packets that would go over this configured maximum size after the Relay Agent Information option is appended shall be forwarded without adding the Agent Information option, and an error counter SHOULD be incremented in this case 🍓 If there's no such configurable, the agent SHALL NOT increase a forwarded DHCP packet's size past the MTU of the interface it's forwarded on ✨
The Relay Agent Information option echoed by a server MUST be removed, either by the relay agent or by the trusted downstream network element that added it, when forwarding a server-to-client response back to the client 🧚
The agent SHALL NOT add an "Option Overload" option to the packet, and it SHALL NOT use the "file" or "sname" fields for adding the Relay Agent Information option. It also SHALL NOT parse or remove Relay Agent Information options that may show up in the sname or file fields of a server-to-client packet forwarded through the agent 🫶
The operation of relay agents for specific sub-options is defined with each sub-option itself 💅
Relay agents are NOT required to monitor or modify client-originated DHCP packets addressed to a server unicast address. This includes the DHCP-REQUEST sent when entering the RENEWING state 🌈
Relay agents MUST NOT modify DHCP packets that use the IPSEC Authentication Header or IPSEC Encapsulating Security Payload [6]. Hard rule, no exceptions, bestie 💀
2.1.1 Reforwarded DHCP requests 🦋
A DHCP relay agent may receive a client DHCP packet forwarded from a BOOTP/DHCP relay agent closer to the client. That kind of packet has a non-zero giaddr, and it may or may not already include a DHCP Relay Agent option 👑
Relay agents configured to add a Relay Agent option that receive a client DHCP packet with a nonzero giaddr SHALL discard the packet if the giaddr spoofs a giaddr address implemented by the local agent itself 🔥
Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr without adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value 💜
2.2 Server Operation 🧚
DHCP servers that are unaware of the Relay Agent Information option will ignore it on receive and won't echo it back in responses. That's the specified server behavior for unknown options, so it's all good 🌸
DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields 🎀 If a server can't copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and it SHOULD increment an error counter for the situation 😭
The operation of DHCP servers for specific sub-options is defined with each sub-option 🍓
Note that DHCP relay agents are not required to monitor unicast DHCP messages sent directly between the client and server (the ones that aren't sent via a relay agent). However, some relay agents MAY choose to do that monitoring and add relay agent options. Because of that, servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be there 🦋
3.0 Relay Agent Information Sub-options 💖
3.1 Agent Circuit ID Sub-option 🌈
This sub-option MAY be added by DHCP relay agents that terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit that a DHCP client-to-server packet was received from. It's meant for agents to use when relaying DHCP responses back to the proper circuit. Possible uses of this field include:
- Router interface number
- Switching Hub port number
- Remote Access Server port number
- Frame Relay DLCI
- ATM virtual circuit number
- Cable Data virtual circuit number
Servers MAY use the Circuit ID for IP and other parameter assignment policies. The Circuit ID SHOULD be treated as an opaque value, with policies based on exact string match only. In other words, the Circuit ID SHOULD NOT be internally parsed by the server 🔥
The DHCP server SHOULD report the Agent Circuit ID value of current leases in statistical reports (including its MIB) and in logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent 👑
SubOpt Len Circuit ID
+------+------+------+------+------+------+------+------+--
| 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ...
+------+------+------+------+------+------+------+------+--3.2 Agent Remote ID Sub-option 🧚
This sub-option MAY be added by DHCP relay agents that terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance:
- a "caller ID" telephone number for dial-up connection
- a "user name" prompted for by a Remote Access Server
- a remote caller ATM address
- a "modem ID" of a cable data modem
- the remote IP address of a point-to-point link
- a remote X.25 address for X.25 connections
The remote ID MUST be globally unique. ✨
DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be treated as an opaque value, with policies based on exact string match only, so the option SHOULD NOT be internally parsed by the server 🫶
The relay agent MAY use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (for example, Offer, Ack, or Nak). DHCP servers SHOULD report this value in any reports or MIBs associated with a particular client 💅
SubOpt Len Agent Remote ID
+------+------+------+------+------+------+------+------+--
| 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ...
+------+------+------+------+------+------+------+------+--4.0 Issues Resolved 🌸
The DHCP relay agent option resolves several issues in an environment where untrusted hosts access the internet through a circuit-based public network. This resolution assumes that all DHCP protocol traffic from the public hosts traverses the DHCP relay agent, and that the IP network between the DHCP relay agent and the DHCP server is uncompromised 🔒
Broadcast Forwarding 📡
The circuit access equipment forwards the normally broadcasted DHCP response only on the circuit indicated in the Agent Circuit ID.
DHCP Address Exhaustion 🍓
In general, the DHCP server may be extended to maintain a database with the "triplet" of:
(client IP address, client MAC address, client remote ID)The DHCP server SHOULD implement policies that restrict the number of IP addresses assigned to a single remote ID 💜
Static Assignment 🎀
The DHCP server may use the remote ID to select the IP address to be assigned. It may permit static assignment of IP addresses to particular remote IDs, and disallow an address request from an unauthorized remote ID 🦋
IP Spoofing 👑
The circuit access device may associate the IP address assigned by a DHCP server in a forwarded DHCP Ack packet with the circuit it was forwarded to. The circuit access device MAY prevent forwarding of IP packets with source IP addresses other than those it has associated with the receiving circuit. This prevents simple IP spoofing attacks on the Central LAN, and IP spoofing of other hosts 🔥
Client Identifier Spoofing 🌈
By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field doesn't need to be used by the DHCP server 💖
MAC Address Spoofing 🧚
By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. 🙈
5.0 Security Considerations ✨
Okay bestie, so DHCP as it's defined right now has literally zero authentication or security mechanisms 😭. If you want the juicy attack details, go check section 7 of the DHCP protocol spec in RFC 2131 [1] 💅
This doc adds mechanisms to deal with a bunch of attacks on IP address assignment: IP spoofing, Client ID spoofing, MAC address spoofing, and DHCP server address exhaustion 🚨. It leans on an implied trusted relationship between the DHCP Relay Agent and the DHCP server, and it assumes the DHCP client is untrusted 🙅♀️. It also introduces a new identifier, the "Remote ID", which is also assumed to be trusted 🦋. The Remote ID comes from the access network or modem, not from client premise equipment 📡. Cryptographic or other techniques to authenticate the remote ID are certainly possible and encouraged, but they're beyond the scope of this document 🔐.
This option is aimed at environments where the network infrastructure (the relay agent, the DHCP server, and the entire network those two devices live in) is trusted and secure 🏰. When this doc says "trusted," it means unauthorized DHCP traffic can't get into the trusted network except through secured and trusted relay agents, and all devices inside the network are secure and trusted 🫶. Potential deployers should give careful consideration to the security vulnerabilities that are present in this model before deploying this option in actual networks ⚠️.
Note that any future mechanisms for authenticating DHCP client to server communications must take care to omit the DHCP Relay Agent option from server authentication calculations 🧐. That's the main reason the DHCP Relay Agent Option is organized as a single option with sub-options, and why the relay agent is required to remove the option before forwarding to the client 🎀.
While it's beyond the scope of this document to specify the general forwarding algorithm of public data circuit access units, automatic reforwarding of IP or ARP broadcast packets back downstream is a serious IP security risk 💀. For example, if an upstream broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back downstream, any public host could easily spoof the desired DHCP server 😱.
6.0 IANA Considerations 🧾
IANA is required to maintain a new number space of "DHCP Relay Agent Sub-options," located in the BOOTP-DHCP Parameters Registry 🗂️. The initial sub-options are described in section 2.0 of this document 🌸.
IANA assigns future DHCP Relay Agent Sub-options with an "IETF Consensus" policy, as described in RFC 2434 [3] 🤝. Future proposed sub-options are referenced symbolically in the Internet-Drafts that describe them, and they shall be assigned numeric codes by IANA when approved for publication as an RFC 🔢.
7.0 Intellectual Property Notices 🎀
This section contains two notices as required by [5] for standards track documents 📜.
The IETF takes no position regarding the validity or scope of any intellectual property 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. It also doesn't represent that it has made any effort to identify any such rights 🤷♀️. Information on the IETF's procedures for rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the IETF Secretariat 💌.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification in this document. For more information, consult the online list of claimed rights 🔍.
8.0 References 📚
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extension", RFC 2132, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
9.0 Glossary 🧚
DSLAM Digital Subscriber Link Access Multiplexer
IANA Internet Assigned Numbers Authority
LIS Logical IP Subnet
MAC Message Authentication Code
RAS Remote Access Server10.0 Author's Address 💌
Michael Patrick
Motorola Broadband Communications Sector
20 Cabot Blvd., MS M4-30
Mansfield, MA 02048
Phone: (508) 261-5707
EMail: michael.patrick@motorola.com11.0 Full Copyright Statement 🌈
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English 🌍.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 🫧.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 💖.
📦 where this page comes from
- ietf: rfc3046 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms