skip to content

In DHCP Option 82, what do the circuit-ID and remote-ID sub-options carry, and how does a server use them though the client never sees them?

level: seniorimportance: nice to knowfreq 12%

answer

  1. added by the relay on the way in
  2. sub-option 1 port, sub-option 2 remote end
  3. opaque, exact-match policy keys
  4. the server echoes, the relay strips
  5. renewals bypass the relay

basics

~20 s

The relay agent adds DHCP Option 82: sub-option 1, Agent Circuit ID, names the arrival port or circuit; sub-option 2, Agent Remote ID, names the remote end. The server matches and logs them and echoes the option, which the relay strips.

solid answer

~50 s

Option 82, the **Relay Agent Information** option of RFC 3046, is a container that the relay agent appends as the last option of a client's request. Sub-option 1, the **Agent Circuit ID**, is an agent-local identifier of the circuit the request arrived on, such as an interface or port, so it means something only together with `giaddr`. Sub-option 2, the **Agent Remote ID**, identifies the remote end, such as a subscriber modem, and MUST be globally unique. The server treats both as opaque strings: it may match them exactly to choose addresses or parameters, and SHOULD record them in its logs. A server that supports the option echoes it verbatim in every reply; the relay uses it to pick the circuit, then removes it, so the client never sees it. Renewals are unicast straight to the server, so they normally arrive without it.

go deeper

for a junior

Recall that Option 82 is added by the relay, never the client, and tells the server where on the network a request came from.

for a middle

Name the two sub-options, 1 Agent Circuit ID and 2 Agent Remote ID, and the round trip: the relay adds, the server echoes, the relay strips.

for a senior

Explain the opaque exact-match rule, logging circuit IDs qualified by giaddr, and the renewal gap with Server Identifier Override as its fix.

for a principal

Judge the trust model: Option 82 carries no authentication, so any policy built on it is only as sound as the network between relay and server and the ports that could inject it.

## What problem Option 82 solves `giaddr` tells a DHCPv4 server which subnet a client is on. It says nothing about *where on that subnet*: which port of an access device, which subscriber line, which modem. RFC 3046 was written for public access networks, where many untrusted subscribers share a subnet behind one access device, and its answers apply equally to a campus that wants to know which wall port held `10.20.120.57` at 14:03. The relay agent knows the arrival circuit; the client does not and cannot be trusted to say. So the relay tells the server, in a new option. ## The format Option 82 is the **Relay Agent Information** option. Its value is a sequence of sub-options, each a sub-option code, a length and a value. There is no pad sub-option and no `255` terminator inside it, and since it must hold at least one sub-option its minimum length is 2. | Sub-option | Name | Defined in | Carries | |---|---|---|---| | 1 | Agent Circuit ID | RFC 3046 | an agent-local identifier of the arrival circuit: interface, port, virtual circuit | | 2 | Agent Remote ID | RFC 3046 | the remote end: a modem ID, a caller ID, a user name; MUST be globally unique | | 5 | Link selection | RFC 3527 | the client's subnet when `giaddr` cannot also select the pool | | 11 | Server Identifier Override | RFC 5107 | the address the server must put in option 54 | ## The relay agent's side - Adding the option SHOULD be configurable and **disabled by default**, with a separate setting for each sub-option. - The relay appends it as the **last** option, before the End option. It never uses the `sname` or `file` fields or adds an Option Overload. - If adding it would exceed the relay's configured maximum size, the relay forwards the request **without** it and counts an error; with no such setting it must not grow the packet beyond the outgoing interface's MTU. - A relay that receives a request with a non-zero `giaddr` has a relay closer to the client in front of it. It forwards without adding a second Option 82, and discards the request if that `giaddr` is one of its own addresses, since that would be spoofed. - A relay that receives, from a circuit it does not trust, a request with `giaddr` zero but Option 82 already present SHALL discard it: a client must not be able to supply the identifiers itself. - On the way back, the relay MAY use the circuit ID or remote ID to choose the circuit to deliver the reply on, and MUST remove the echoed option before the reply reaches the client. ## The server's side 1. A server that does not know Option 82 ignores it and does not echo it, the normal treatment of unknown options. 2. A server that supports it SHALL echo the **entire** option in all replies, SHOULD place it last, and never puts it in `sname` or `file`. If it cannot fit, it replies without it. 3. It treats circuit ID and remote ID as **opaque**, matching by exact string and never parsing them. 4. It MAY base address or parameter choices on them, for example a fixed address per remote ID, refusing an unauthorised remote ID, or capping the addresses one remote ID may hold, which RFC 3046 says a server SHOULD do against exhaustion. 5. It SHOULD report the circuit ID of current leases in logs and statistics, **qualified by `giaddr`**, because "port 7" exists on every relay. ## Why the client never sees it RFC 3046 requires the relay to remove the option before delivery, and gives the reason: any future client-to-server authentication must leave relay data out of its calculation, which is why the information was packed into a single option that is easy to strip. The trust model is explicit: RFC 3046 itself defines no way to authenticate the relay or the data it inserts. RFC 3046 assumes the relay, the server and the network between them are trusted, and that unauthorised DHCP traffic cannot enter that network except through trusted relay agents. ## The renewal gap A bound client renews at T1 by unicasting a `DHCPREQUEST` to its server identifier. RFC 3046 does not require relays to inspect or modify such unicasts, so the renewal usually reaches the server **without** Option 82, and the server MUST NOT expect the option to be present. A policy that checks circuit IDs at every message will therefore misfire at renewal. RFC 5107's **Server Identifier Override** sub-option closes the gap. The relay asks the server to put the relay's own address in option 54, so the client renews to the relay, which adds Option 82 and relays the renewal. The cost: renewals now depend on the relay being reachable, and the server must support the sub-option, or it inserts its own address and the renewals bypass the relay as before.

  • How does the DHCP server-identifier-override sub-option close Option 82's renewal gap, and what does it cost?
    RFC 5107 sub-option 11 carries an address the server MUST put in option 54. The relay supplies its own, so renewing clients unicast to the relay, which adds Option 82 and forwards. The server must support the sub-option or it inserts its own address and renewals bypass the relay as before; and if the relay becomes unreachable, RFC 5107 warns that renewals may go unprocessed and the lease may run out.
  • A second DHCPv4 relay receives a request that already carries Option 82 and a non-zero giaddr; what does it do?
    RFC 3046 says it forwards the request without adding another Relay Agent Information option and, per RFC 2131, without touching `giaddr`, so the first relay's data stands. The exception is a `giaddr` that is one of the second relay's own addresses: that request is spoofed and SHALL be discarded.
  • Why should a DHCP server log an Option 82 circuit ID together with giaddr?
    A circuit ID is local to one relay agent; the same port number exists on every relay. RFC 3046 says it should be qualified with the `giaddr` that identifies the relay. Logging the pair is what turns 'who had this address at 14:03' into one specific port on one specific device.

saying these in an interview costs you the question

  • The client includes Option 82 so the server knows its switch port.
  • Clients receive Option 82 in their DHCPACK and store it.
  • The server parses the circuit ID to extract the VLAN and port.
  • Option 82 authenticates the relay agent to the DHCP server.
  • Every renewal carries the same circuit ID the Discover had.