skip to content

What do DHCPv6-Shield (RFC 7610) and SAVI-DHCP (RFC 7513) each standardise, and why must DHCPv6-Shield parse the whole IPv6 header chain?

level: seniorimportance: nice to knowfreq 8%

answer

  1. the IETF's answer to vendor snooping
  2. server messages on allowed ports only
  3. extension headers hide UDP
  4. fragments and unknown Next Header
  5. a binding table for both versions

basics

~20 s

DHCPv6-Shield (RFC 7610, BCP 199) drops DHCPv6 server messages on ports not allowed for a server or relay; SAVI-DHCP (RFC 7513) binds DHCP-assigned addresses to ports to filter forged sources. Shield parses the full chain because extension headers can hide UDP.

solid answer

~50 s

DHCPv6-Shield is the IETF's specification of what switch vendors call DHCPv6 Guard: an administrator lists the layer 2 ports allowed to receive DHCPv6-server messages — those meant for clients — and the device drops them everywhere else and SHOULD log the drop. Because IPv6 allows extension headers between the IPv6 header and UDP, a filter that inspects a fixed number of bytes can miss a hidden server message, so RFC 7610 requires parsing the entire header chain, dropping a first fragment that lacks the whole chain, and dropping unrecognised Next Header values by default. SAVI-DHCP (Standards Track) is the binding half, for DHCPv4 and DHCPv6: it snoops assignments into a Binding State Table, discards server messages from attachments without the DHCP-Trust attribute, and filters forged source addresses. RFC 9915 points to both for rogue-server attacks. Neither filters Router Advertisements.

go deeper

for a junior

Recall that DHCPv6-Shield is the IETF's version of rogue-server filtering for IPv6, and that SAVI-DHCP standardises the binding table idea for both DHCP versions.

for a middle

Explain the five RFC 7610 rules and why extension headers, fragments and unknown Next Header values force parsing the whole header chain.

for a senior

Lay out the coverage gaps — Router Advertisements, server-side floods, SLAAC and link-local addresses — and what else must run beside the filter on each access port.

for a principal

Decide whether to require the RFC behaviour from switch vendors, how to test for header-chain evasion before buying, and how to cover IPv6 where it is not yet planned.

## Why DHCPv6 needs its own filter DHCPv6, specified in RFC 9915 (which obsoletes RFC 8415), shares DHCPv4's weakness: a client cannot tell a legitimate server from a rogue one. RFC 9915's security considerations describe a malicious server giving "incorrect configuration information" to steer the client to a malicious DNS or NTP server, or to cut it off, and add: "Many of the attacks by rogue servers can be mitigated by making use of the mechanisms described in [RFC7610] and [RFC7513]." A DHCPv4 snooping filter does not help: DHCPv6 runs over IPv6, clients send to UDP port 547 at the multicast address `ff02::1:2`, and servers and relays send client messages to UDP port 546. Switch vendors sell the IPv6 filter under the name **DHCPv6 Guard** (a vendor feature name); the IETF specified it as **DHCPv6-Shield**. ## DHCPv6-Shield: RFC 7610 RFC 7610 is a Best Current Practice, BCP 199. Before deployment an administrator lists the layer 2 ports allowed to receive **DHCPv6-server messages** — DHCPv6 messages meant for clients — which should be only ports where a DHCPv6 server or relay connects. On every other port the device applies five rules: 1. It MUST parse the entire IPv6 header chain to decide whether a packet is a DHCPv6-server message, and MUST NOT limit how many bytes it inspects. 2. A first fragment that does not contain the whole header chain MUST be dropped. 3. A configuration knob decides whether packets with an unrecognised Next Header value are dropped, and it MUST default to "drop". 4. A packet identified as a DHCPv6-server message MUST be dropped, and the drop SHOULD be logged as a security alert. 5. Everything else MUST pass. ## Why the whole header chain IPv6 lets extension headers sit between the IPv6 header and the UDP header. A filter that looks only at a fixed number of bytes, or gives up at a header it does not know, sees no UDP and lets the packet through — while the client's stack, which parses every header, still receives the DHCPv6 message. RFC 7610's rationale for rule 1 says a byte limit "could introduce false negatives". The same logic drives the other rules: - **Rule 2** stops a server message whose UDP header is pushed into a later fragment; RFC 7112 already requires the first fragment to carry the whole chain, so honest traffic is not affected in practice. - **Rule 3** stops a header the device cannot parse past from hiding what follows it. - **ESP ends the chain.** RFC 7610 treats ESP as an upper-layer header, so ESP-protected packets pass; the receiving host drops them unless it has a security association with the sender. - **Fast-path limits.** RFC 7610's security considerations accept that hardware may cap inspection depth, and recommend dropping packets whose header search hits that cap. ## SAVI-DHCP: RFC 7513, the binding half DHCPv6-Shield only filters server messages. **SAVI-DHCP** (RFC 7513, Standards Track) is the IETF's specification of the binding table that DHCP snooping builds, for DHCPv4 and DHCPv6. It snoops assignments into a **Binding State Table** and then filters forged source addresses. Each attachment carries attributes: | Attribute | Meaning | |---|---| | Trust | Packets need no source validation (another SAVI device, a router) | | DHCP-Trust | The attachment may send DHCP server-to-client messages | | DHCP-Snooping | Client messages here create bindings | | Data-Snooping | Unbound data packets may trigger the optional Data Snooping Process | | Validating | Source addresses are checked against the table | Server-to-client messages from an attachment with neither DHCP-Trust nor Trust "MUST be discarded" — the same trust rule as DHCPv6-Shield, now for both protocol versions. ## Where each one stops | Mechanism | Status | Covers | Does not cover | |---|---|---|---| | DHCPv6-Shield, RFC 7610 | BCP 199 | Rogue DHCPv6-server messages on ports not allowed for them | Router Advertisements; attacks against DHCPv6 servers; DHCPv4 | | SAVI-DHCP, RFC 7513 | Standards Track | Bindings for DHCP-assigned addresses; forged-source filtering | Stateless DHCPv6; SLAAC addresses (FCFS SAVI, RFC 6620); link-local addresses | | DHCP snooping | Vendor feature, no RFC | DHCPv4 server-message filtering and a binding table | DHCPv6, unless the implementation adds it | RFC 7610 adds two operating notes: deploy it on every switch in the layer 2 domain, because a switch cascaded below another must allow server messages from its uplink and relies on the upstream switch to filter them; and keep a per-port drop counter to find the rogue. Rogue Router Advertisements need a separate filter, RA-Guard (RFC 6105, Informational), on the same switch.

  • Can DHCPv6-Shield's rule on first fragments drop legitimate traffic?
    In theory, yes: a first fragment missing part of the header chain is dropped whether or not it hides a server message, and RFC 7610 admits possible false positives. In practice RFC 7112 requires hosts to put the whole header chain in the first fragment, and such packets are virtually impossible to police with stateless filters anyway, so they rarely survive in real networks.
  • Does DHCPv6-Shield stop a rogue router that tells hosts not to use DHCPv6 at all?
    No. RFC 7610 filters only DHCPv6-server messages and says attacks based on other configuration messages, such as ICMPv6 Router Advertisements, are out of its scope. A rogue router's advertisements need RA-Guard (RFC 6105). Defending first-hop IPv6 configuration means running both filters on the same access ports.

saying these in an interview costs you the question

  • DHCPv6-Shield is just RA Guard under another name.
  • Inspecting a fixed number of bytes is enough to spot DHCPv6 server messages.
  • DHCP snooping itself is defined in RFC 7513.
  • DHCPv6-Shield only needs to run on the switch nearest the DHCPv6 server.
  • SAVI-DHCP validates SLAAC addresses as well as DHCP-assigned ones.