Understanding IPv6 Router Advertisement Guard

In an IPv6 deployment, routers periodically multicast Router Advertisement (RA) messages to announce their availability and convey information to neighboring nodes that enable them to be automatically configured on the network. RA messages are used by Neighbor Discovery Protocol (NDP) to detect neighbors, advertise IPv6 prefixes, assist in address provisioning, and share link parameters such as maximum transmission unit (MTU), hop limit, advertisement intervals, and lifetime. Hosts listen for RA messages for IPv6 address autoconfiguration and discovery of link-local addresses of the neighboring routers, and can also send a Router Solicitation (RS) message to request immediate advertisements.

RA messages are unsecured, which makes them susceptible to attacks on the network that involve the spoofing (or forging) of link-layer addresses. Also, unintended misconfiguration by users or administrators might lead to the presence of unwanted, or rogue, RA messages, which can cause operational problems for neighboring hosts. You can configure IPv6 Router Advertisement (RA) guard to protect your network against rogue RA messages generated by unauthorized or improperly configured routers connecting to the network segment.

RA guard works by validating RA messages on the basis of whether they meet certain criteria, configured on the switch using policies. RA guard inspects RA messages and compares the information contained in the message attributes to the configured policy. Depending on the policy, RA guard either drops or forwards the RA messages that match the conditions.

The following information contained in RA message attributes can be used by RA guard to validate the source of the RA message:

• Source MAC address

• Source IPv6 address

• Source IPv6 address prefix

• Hop-count limit

• Router preference priority

• Managed configuration flag

• Other configuration flag

You can configure RA guard to operate in either stateless or stateful mode. In stateless mode, in the default state, an RA message that is received on an interface is examined and filtered on the basis of whether it matches the conditions configured in the policy attached to that interface. If the content of the RA message is validated, it forwards the RA message to its destination; otherwise, the RA message is dropped. The state of an interface operating in stateless mode can be changed by configuration. If the interface is configured as trusted, all RA messages are forwarded without being validated against the policy. If the interface is configured as blocked, all RA messages are dropped without being validated against the policy.

In stateful mode, an interface can dynamically transition from one state to another based on information gathered during a learning period. During this period, known as the learning state, ingress RA messages are validated against a policy to determine which interfaces are attached to links with valid IPv6 routers. At the end of the learning period, interfaces attached to legitimate senders of RA messages transition dynamically to the forwarding state, in which RA messages are forwarded if they can be validated against a policy. Interfaces that do not receive valid RA messages during the learning period transition dynamically to the blocked state, in which all ingress RA messages are dropped.

Table 1 summarizes the states of IPv6 RA guard for both stateless and stateful mode.

Figure 1 illustrates the transition of states when stateful RA guard is enabled. The numbers shown on the illustrations are described in the text that follows; these are not sequential steps.

Figure 1: Stateful RA Guard State Transitions

1. When RA guard is enabled on an interface it moves to the untrusted state from the off state. The untrusted state is the default state of an interface that is enabled for RA guard.

2. When the command requesting the learning state is issued, the interface is moved from the off state to the learning state.

3. RA messages received during the learning state are compared to the configured policy.

4. If RA messages are validated against the configured policy, the interface moves to forwarding state.

5. If RA messages are not validated against the configured policy, the interface moves to blocked state.

6. If mark-interface trust is configured on the validated interface, then it moves from forwarding state to trusted state.

7. If mark-interface trust is configured on the blocked interface, then it moves from blocked state to trusted state.

8. If learning is requested on a blocked interface, then the interface moves from the blocked state to the learning state.

9. If an interface in the default untrusted state is configured as mark-interface trust, it moves directly to the trusted state. In this case a policy can not be applied on that interface.

10. If the mark-interface trust configuration is deleted, and no valid RAs are received on the interface, then the interface moves to the blocked state.

11. If the command requesting the forwarding state is issued, then the interface moves directly from blocked to forwarding state.

12. If the command requesting the blocking state is issued, then the interface moves directly from forwarding to blocked.

13. If an interface in the default untrusted state is configured as mark-interface block, it moves directly to the blocked state. In this case a policy can not be applied on that interface.