ENTERPRISE IPV6 SECURITY · 28 OCTOBER 2026

IPv6 first-hop security: a commissioning worksheet

An enterprise can operate mainly on IPv4 and still have active IPv6 on laptops, phones, access points, cameras and building controllers. A rogue Router Advertisement or DHCPv6 server can then redirect traffic or disrupt address configuration outside the controls designed for IPv4. This worksheet adds IPv6 protection as a separate, testable access-layer service.

Visual reference photographs

Start with an IPv6 exposure audit

Do not assume IPv6 is absent because the organization has not intentionally deployed a global IPv6 prefix. Endpoints automatically use link-local IPv6, and some networks carry Router Advertisements, DHCPv6 or tunneled traffic without a formal design. Capture the active VLANs, legitimate IPv6 routers, DHCPv6 servers and relays, wireless controllers, firewalls, virtualization hosts and downstream switches.

For each access VLAN, decide whether the approved address method is SLAAC, stateless DHCPv6, stateful DHCPv6, a controlled combination or no routed IPv6 service. Record the intended prefixes, router link-local addresses, RA flags, DNS method, DHCPv6 relay path and high-availability behavior. A security policy cannot validate traffic until the intended control plane is known.

Why IPv4 controls do not cover IPv6

DHCP snooping and Dynamic ARP Inspection protect IPv4 mechanisms. IPv6 uses Router Advertisements, Neighbor Discovery and DHCPv6. Cisco's IPv6 first-hop security guidance separates RA Guard, DHCPv6 Guard, ND inspection, device tracking and IPv6 Source Guard because each protects a different part of the first-hop process.

RA Guard filters unauthorized ICMPv6 Router Advertisements and redirects. DHCPv6 Guard or DHCPv6 Shield blocks server messages arriving on ports that are not allowed to face a server or relay. ND inspection validates Neighbor Discovery messages against trusted bindings. IPv6 Source Guard then uses the binding table to filter data traffic from unknown or unauthorized sources.

Build the trust boundary port by port

Mark authorized network-facing ports explicitly. Router Advertisements should normally enter from router or firewall ports, not ordinary endpoint ports. DHCPv6 server messages should enter only from approved server, relay or upstream paths. Account for trunks, port channels, stacks, redundant firewalls, access-point tunnels and downstream switches. A trunk is not automatically trustworthy for every IPv6 control message.

RFC 7610 requires DHCPv6 Shield to be configured with the Layer 2 ports allowed to receive server messages toward clients. It also explains that effective protection across cascaded switches depends on deployment throughout the Layer 2 domain. A protected access switch cannot determine whether a server reply arriving from an unprotected upstream switch is legitimate.

Commission RA Guard with content validation

Basic RA Guard blocks Router Advertisements on host-facing ports. More capable policies can validate source addresses, prefixes, hop limits, RA flags and router preference on authorized router ports. Cisco documents host and router device roles plus prefix, source and flag checks. Juniper documents policies that can match source MAC, source IPv6 address, prefix, hop limit, flags and router preference.

Use the most specific policy supported by the installed platform without making failover impossible. If a firewall pair can legitimately use two link-local source addresses or advertise a backup router preference, include both approved states. Validate the high-availability transition before handover.

RFC 7113 warns that some early RA Guard implementations could be bypassed with IPv6 extension headers. It requires parsing the complete IPv6 header chain and specifies handling for first fragments and unrecognized next-header values. Confirm the exact switch model and software implementation, not only that a command named RA Guard exists.

Add DHCPv6 Guard separately

DHCPv6 Guard blocks reply and advertisement messages from unauthorized servers or relays while allowing client-originated requests. This is separate from RA Guard because SLAAC and DHCPv6 can coexist, and a network can be attacked through either control plane.

RFC 7610 also requires complete IPv6 header-chain parsing so extension headers cannot hide DHCPv6 server messages. Capture per-port drop counters and security logs during commissioning. If the switch supports allowed server addresses or delegated prefixes, use values from the approved address plan rather than broad any-server policies.

Plan the binding table before Source Guard

ND inspection and device tracking learn IPv6-to-MAC, VLAN and port relationships. Cisco states that IPv6 Source Guard depends on this binding table and can block all data traffic from a port when a valid source is absent. Activate it only after legitimate bindings are visible and recovery behavior is understood.

IPv6 endpoints can hold several addresses at once, including link-local, stable global, temporary privacy and service-specific addresses. Size the binding table and hardware resources using observed endpoint behavior, not one address per device:

Example: 800 endpoints averaging four active IPv6 addresses require about 3,200 entries before infrastructure and reserve. This is an illustrative planning calculation. Use the exact switch limit and account for IPv4 tracking if the platform shares resources.

Handle static and embedded devices explicitly

Cameras, access controllers, printers, building controllers and older appliances may use static IPv6, incomplete DHCPv6 behavior or unusual Neighbor Discovery timing. Lab-test representative models. If a legitimate device cannot populate the binding table, use a documented static binding or a narrowly scoped exception supported by the platform. Do not trust an entire CCTV or building-services VLAN simply to accommodate one endpoint.

Wireless clients may appear behind controller, tunnel or access-point interfaces rather than the physical edge port. Apply policies at the enforcement point supported by the WLAN architecture and validate roaming, sleep recovery and address renewal.

Stage activation to avoid a self-inflicted outage

1. Inventory legitimate routers, DHCPv6 servers, relays and prefixes.
2. Enable monitoring or device tracking and observe normal bindings and control traffic.
3. Apply RA Guard to a pilot host-facing port while keeping authorized router paths explicit.
4. Verify SLAAC, default-router installation, DNS information and application reachability.
5. Apply DHCPv6 Guard to the pilot and verify the approved DHCPv6 workflow.
6. Enable ND inspection and confirm duplicate-address detection, neighbor resolution and gateway reachability.
7. Confirm valid bindings survive normal renewals, roaming and endpoint sleep.
8. Enable IPv6 Source Guard only after the binding population and recovery path are proven.
9. Expand one switch or VLAN at a time with rollback commands prepared.

Keep IPv4 and IPv6 tests separate. A dual-stack application can appear healthy because it silently falls back to IPv4 while IPv6 is broken. Force IPv6 test traffic and inspect the selected address family.

Run controlled positive and negative tests

Positive tests prove that authorized Router Advertisements, DHCPv6 replies, Neighbor Discovery and data traffic still work. Negative tests should use an isolated test endpoint during an approved window. Attempt a Router Advertisement from a host-facing port and confirm a drop counter and log without changing client default routes. Attempt a DHCPv6 server reply from an unauthorized port and confirm it is blocked.

Test a spoofed or unknown IPv6 source only where the method cannot affect production addresses. Confirm the intended Source Guard action and recovery. Do not run uncontrolled rogue-router or denial-of-service tools on an occupied building network.

Test restart and failure recovery

Record what happens to bindings after an access-switch reload, stack failover, uplink change or controller restart. Cisco documents binding-table recovery mechanisms because unknown-source filtering can interrupt valid endpoints after a reboot. Verify whether bindings persist, relearn through ND or DHCPv6, or require static entries.

Test firewall or router failover and confirm the new authorized RA source, router lifetime and preference are accepted. Check logging and monitoring for policy drops, table exhaustion, unexpected new routers and repeated binding recovery.

Commissioning worksheet

1. Every access VLAN has an explicit intended IPv6 service state.
2. Authorized routers, prefixes, RA flags and router preferences are recorded.
3. Authorized DHCPv6 servers, relays and ingress ports are recorded.
4. Access, trunk, port-channel and wireless enforcement points are mapped.
5. The switch model and software support complete header-chain inspection.
6. RA Guard blocks host-port advertisements and permits approved routers.
7. DHCPv6 Guard blocks unauthorized server messages and permits approved replies.
8. Drop counters and security logs identify the test port and policy.
9. ND inspection preserves DAD and legitimate neighbor resolution.
10. The binding table contains correct IPv6, MAC, VLAN and port records.
11. Binding capacity includes multiple addresses per endpoint and reserve.
12. Static and embedded-device exceptions are narrow and documented.
13. IPv6 Source Guard is enabled only after bindings and recovery are proven.
14. Positive tests force IPv6 rather than relying on IPv4 fallback.
15. Controlled negative tests verify each intended block.
16. Switch reload and binding recovery do not strand valid endpoints.
17. Router, firewall or uplink failover preserves approved IPv6 service.
18. Configurations, tables, counters, logs, exceptions and rollback enter the handover pack.

Minimum handover pack

Provide the IPv6 VLAN and address plan, router and DHCPv6 inventory, port-role matrix, RA Guard and DHCPv6 Guard policies, ND inspection and Source Guard dependencies, binding-capacity calculation, static exceptions, positive and negative test evidence, reload and failover results, counters, logs and rollback procedure. Link this record to the IPv4 first-hop security worksheet, VLAN handover worksheet and wired NAC worksheet.

Primary technical references

• IETF RFC 7113: Implementation Advice for IPv6 RA Guard
• IETF RFC 7610: DHCPv6 Shield
• IETF RFC 9099: Operational Security Considerations for IPv6 Networks
• Cisco: IPv6 First-Hop Security
• Cisco: IPv6 RA Guard
• Juniper: Understanding IPv6 Router Advertisement Guard