rfc-3046

DHCP Relay Agent Information Option

M. Patrick
date2001-01 streamIETF areaint wgdhc statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc3046 doi10.17487/RFC3046
Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]

updated by

Extracted elements (26)

design-rationale §1.2

Co-locating the DHCP relay agent with the circuit access equipment allows unicast forwarding of DHCP replies to only the correct circuit, avoids replicating broadcast replies to thousands of access circuits, and enables use of circuit-layer identity (e.g., ATM VC, cable modem ID) as a trusted DHCP client identifier.

design-rationale §1.1

The circuit access model deliberately avoids allocating an IP address to the modem or a dedicated Logical IP Subnet (LIS) per user-side LAN, since doing so would require a full IP router at the user site and is inappropriate for large public-access networks.

design-rationale §5.0

The Relay Agent Information option is organized as a single DHCP option with sub-options (rather than multiple independent options) specifically so that future DHCP authentication mechanisms can unambiguously omit the entire block from integrity calculations, and so the relay agent can cleanly strip it before forwarding to the client.

security

interoperability-note §2.2

DHCP servers unaware of the Relay Agent Information option will ignore it on receipt and will not echo it back in responses, which is the specified RFC 2132 behavior for unknown options. Deployments must account for servers that silently drop the option.

normative-requirement §2.1 SHALL

A relay agent adding a Relay Agent Information field SHALL add it as the last option (before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from client to server.

normative-requirement §2.2 SHALL

DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the option in all replies, SHOULD copy it as the last DHCP option in the response, and SHALL NOT place the echoed option in the overloaded sname or file fields.

normative-requirement §2.2 SHALL

If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Agent Information field and SHOULD increment an error counter.

normative-requirement §2.1 SHALL

In the absence of a configurable maximum packet size, the relay agent SHALL NOT increase a forwarded DHCP packet size to exceed the MTU of the forwarding interface. If a size limit is configured and would be exceeded by adding the option, the packet SHALL be forwarded without the option and an error counter SHOULD be incremented.

normative-requirement §2.1 SHOULD

Overall adding of the Relay Agent Information option SHOULD be configurable and SHOULD be disabled by default. Relay agents SHOULD have separate configurables for each sub-option.

normative-requirement §2.1.1 SHALL

Relay agents configured to add a Relay Agent option which 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 the packet WITHOUT adding relay agent options and SHALL NOT modify the giaddr value.

security

normative-requirement §2.1 MUST NOT

Relay agents MUST NOT modify DHCP packets that use the IPsec Authentication Header or IPsec Encapsulating Security Payload.

ipsec, security

normative-requirement §2.1 SHALL

Relay agents receiving a DHCP packet from an untrusted circuit with giaddr set to zero but with a Relay Agent Information option already present SHALL discard the packet and increment an error count.

security

normative-requirement §2.2 MUST NOT

Servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be present, since relay agents are not required to monitor unicast DHCP messages sent directly between client and server.

normative-requirement §3.2 MUST

The Agent Remote ID sub-option value MUST be globally unique. Servers and relay agents SHOULD treat it as opaque, with policies based on exact string match only.

security

normative-requirement §2.1 MUST

The Relay Agent Information option echoed by a server MUST be removed by either the relay agent or the trusted downstream network element which added it when forwarding a server-to-client response back to the client.

security

normative-requirement §2.1 SHALL

The relay agent SHALL NOT add an 'Option Overload' option to the packet, nor use the 'file' or 'sname' fields for the Relay Agent Information option. It SHALL NOT parse or remove Relay Agent Information options that may appear in those fields in server-to-client packets.

protocol-element §2.0

The Relay Agent Information option is a container option inserted by the relay agent when forwarding client-to-server DHCP packets. The server echoes it verbatim in replies, and the relay agent strips it before forwarding the reply to the client.

security

registry §6.0

IANA maintains a 'DHCP Relay Agent Sub-options' number space in the BOOTP-DHCP Parameters Registry. Initial assignments are sub-option 1 (Agent Circuit ID) and sub-option 2 (Agent Remote ID). Future sub-options require IETF Consensus per RFC 2434.

registry

security-consideration §5.0

Any future mechanisms for authenticating DHCP client-to-server communications must omit the DHCP Relay Agent option from server authentication calculations to avoid the relay agent being unable to strip the option. This concern drove the single-option-with-sub-options design.

security

security-consideration §5.0

Automatic reforwarding of IP or ARP broadcast packets back downstream by the circuit access unit exposes serious IP security risks; for example, a rebroadcast DHCP-DISCOVER or DHCP-REQUEST could allow any public host to spoof the desired DHCP server.

security

security-consideration §5.0

The option relies on an implied trusted relationship between the relay agent and the DHCP server, with the DHCP client assumed untrusted. The trusted network must prevent unauthorized DHCP traffic from entering except through secured relay agents. Deployers must carefully evaluate security vulnerabilities before deployment.

security

security-consideration §5.0

The Remote ID is provided by the access network or modem, not by client premise equipment, making it a trusted identifier. Cryptographic or other authentication techniques for the Remote ID are encouraged but beyond the scope of this document.

security, crypto

wire-format §3.1

Agent Circuit ID is sub-option code 1 with a variable-length value (c1..cN) encoding an agent-local identifier of the ingress circuit. The field is opaque; servers SHOULD treat it as an exact-match string qualified by the giaddr.

wire-format §3.2

Agent Remote ID is sub-option code 2 with a variable-length value (r1..rN) encoding a globally unique identifier for the remote host end of the circuit, such as a modem ID, caller ID, or remote IP address.

wire-format §2.0

Sub-options within the Relay Agent Information option are encoded as SubOpt/Len/Value tuples. No pad sub-option is defined, and the field SHALL NOT be terminated with sub-option 255. Sub-option length N counts only that sub-option's value octets; a zero-length sub-option value is permitted.

wire-format §2.0

The Relay Agent Information option is DHCP option 82. It consists of a 1-octet code (82), a 1-octet length N giving total octets in the Agent Information Field, followed by N octets of sub-option tuples. The minimum length is 2, requiring at least one sub-option.

registry, security