Close IPv6 RA-Guard evasion paths before calling the access edge protected

Router Advertisement Guard is useful only when the enforcement point can reliably recognize a Router Advertisement. A rule that blocks the obvious packet shape but permits evasive extension-header or fragment arrangements leaves an access segment exposed to unauthorized IPv6 default-router information.

Source fact:

IETF RFC 7113 documents implementation advice for IPv6 RA-Guard. It explains that some implementations can be circumvented when an attacker places the ICMPv6 Router Advertisement behind IPv6 extension headers. The RFC recommends that an enforcement device inspect the entire IPv6 header chain rather than assume that the upper-layer protocol immediately follows the base header.

The RFC also addresses fragments. Its guidance includes dropping and logging a first fragment when that fragment does not contain the complete IPv6 header chain, because the device cannot then determine whether a prohibited Router Advertisement follows. It also recommends a default-drop posture when an RA-Guard device encounters an unrecognized next-header value and cannot positively determine that the packet is permitted.

Boundary

RFC 7113 is implementation advice, not a certification of any switch or configuration. Hardware forwarding paths, software releases, policy syntax, logging, and treatment of extension headers vary by platform. A lab result from one model or release does not establish behavior for another. RA-Guard also addresses forged Router Advertisements; it is not a complete IPv6 first-hop security program and does not replace appropriate port authorization, DHCPv6 controls, address monitoring, or endpoint protections.

Applicability questions

• Which user, wireless, voice, guest, and building-system VLANs carry IPv6 today, including link-local traffic?
• On which ports should legitimate Router Advertisements enter, and is that role documented?
• Can the installed forwarding hardware parse the relevant extension-header chain at line rate?
• How does the release handle first fragments, unknown next headers, and packets that exceed its inspection depth?
• Are drops observable in counters or logs without creating an operational flood?

DSE recommendation:

Inventory every IPv6-capable access segment and define permitted router-facing ports explicitly. Obtain the vendor’s current feature and limitation documentation for the exact hardware and software combination. In an isolated test VLAN, send an allowed legitimate RA and prohibited RAs in ordinary, extension-header, and fragmented forms. Include benign IPv6 traffic that uses extension headers so the team can identify unacceptable false positives.

Promote the policy through change control only after the failure behavior is understood. Record exceptions narrowly, assign an owner, and retest after switch upgrades or replacement. If a platform cannot implement the RFC’s inspection guidance, document the gap and use compensating segmentation or upstream enforcement instead of reporting the segment as protected.

Verification and evidence

Retain the switch model, software version, running policy, port roles, packet captures from both sides of the enforcement point, test-packet definitions, drop counters, and the approved change record. A passing result should show that the legitimate router remains reachable, ordinary endpoint traffic continues, and each prohibited test packet is blocked by the intended control. Re-run a small regression set after relevant firmware, ASIC-profile, or template changes.

Official references

• IETF RFC 7113
• IETF RFC 6105, IPv6 Router Advertisement Guard