IPv6 RA Guard

As a network engineer, it is your job to protect your network against the weaknesses inherent in IPv6.
Let's look at an example of an IPv6 weakness to help you understand the purpose of IPv6 RA Guard.

Router Solicitation

In this example, PC1 has just joined the network and sends a Router Solicitation (RS) to the all-routers multicast address FF02::2.

Figure 1 – A host sends a Router Solicitation to find a router

PC1 already has a link-local address, FE80::1A1:FEA1:A1A1, you can see it as the source of the RS.

But a link-local address never leaves the segment: to reach the outside, PC1 needs a global address and a default gateway.
The RS is its way of asking the routers for both.

Router Advertisement

R1 replies with a Router Advertisement (RA) sent to FF02::1, the all-nodes multicast.

Figure 2 – The router replies with a Router Advertisement

It carries everything the host needs:

• the network prefix 2001:db8:10::/64, so PC1 can build its own global IPv6 address

• the MTU to use on this segment

• R1's link-layer address, so PC1 knows where to send its traffic

With this prefix, PC1 builds its global address by itself, this mechanism is called SLAAC.
Both PC1 and PC2 receive the RA, this is how every device on the segment learns its gateway automatically.

The problem is that this IPv6 mechanism has a vulnerability.
Nobody checks that it is indeed the default gateway announcing the RA!

Rogue RA

In this example, the Hacker sends the same Router Advertisement (RA) using its own address as the source.

Figure 3 – A rogue RA from the Hacker

Your device believes it, exactly like it believed R1.
The RA is flooded to the whole segment, so every host now sees the Hacker as its gateway.

One packet, no authentication, and everyone now routes through the attacker!

You cannot stop the Hacker from sending rogue RAs.
But you can configure your ports to only accept RAs where a router should be, and with this principle you can protect your segment.

RA Guard, defined in RFC 6105 is built on that idea.

RA Guard Roles

With RA Guard, you tag each port on your switch with a role: router or host.

Figure 4 – Router role on G0/0, host role on G0/1 and G0/2

In this example, G0/0 faces R1 so it gets the router role.
G0/1 and G0/2 face PC1 and the Hacker so they get the host role.

Each role decides only one thing: is a Router Advertisement allowed through this port?

Router Port

This is the role for the port facing your real router:

• Incoming RAs are allowed through, so R1 can keep announcing the prefix

• It is the only port where a router should ever sit

Host Port

This is the role for every port facing an end device:

• Incoming RAs are dropped immediately, an end device has no reason to announce itself as a router

With these roles in place, the rogue RA from earlier would never leave G0/2: SW1 drops it before PC1 and PC2 even see it.
Let's move on to the next part, where we'll see how to configure everything.

Time to practice, you start with the policy for the router port.