IPv6 RA Guard

Router advertisements can be used by hosts to automatically configure their own IPv6 address and set a default route using the information they see in the RA. In the IPv6 router advertisement preference lesson, I explained how IPv6 hosts behave when they receive multiple router advertisements.

Hosts automatically select a router advertisement and they don’t care where it came from. This is how it was meant to be but it does introduce a security risk since any device can send router advertisements and your hosts will happily accept it. An attacker can send rogue router advertisements to redirect the traffic, or you can send so many RAs that it causes a DOS since your hosts will be too busy configuring their IPv6 prefixes.

The IPv6 RA guard feature can filter router advertisements and runs on switches. This can be as simple as “don’t allow RAs on this interface” or complex with policies where router advertisements are only permitted when it matches certain criteria.

In this lesson, I’ll show you how to use the IPV6 RA guard feature to block a malicious host and how to use a policy to permit router advertisements from a legitimate router, but only when it matches certain criteria.

Configuration

Here is the topology we’ll use:

Ipv6 Ra Guard Topology

R1 is our legitimate router that will send RAs. H1 is some IPv6 host that autoconfigures itself with SLAAC, H2 is our attacker who is going to send rogue router advertisements.

Let’s configure R1 so that it sends router advertisements. To do that, we need to enable unicast routing:

R1(config)#ipv6 unicast-routing

And we’ll configure an IPv6 address so that it includes a prefix in the RAs:

R1(config)#interface GigabitEthernet0/1
R1(config-if)#ipv6 address 2001:DB8:0:1::1/64

Our host is going to use SLAAC and sets a default route to the router:

H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ipv6 address autoconfig default

Host Policy

Let’s see how our host reacts to the router advertisement from R1:

H1#show ipv6 routers 
Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
  Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
  HomeAgentFlag=0, Preference=Medium
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:DB8:0:1::/64 onlink autoconfig
    Valid lifetime 2592000, preferred lifetime 604800

H1 receives the RA. Let’s see if it uses this router as its default gateway:

H1#show ipv6 route static

S   ::/0 [2/0]
     via FE80::211:21FF:FE4E:D1C1, GigabitEthernet0/1

Above, we see the default route that points to R1. Let’s see what happens when we try to mess around with this.

Let’s configure H2 so that it also sends RAs and to make it interesting, I’ll set the router preference to high:

H2(config)#ipv6 unicast-routing
H2(config)#interface GigabitEthernet 0/1
H2(config-if)#ipv6 address 2001:DB8:BAD:BAD::2/64
H2(config-if)#ipv6 nd router-preference high

Here’s what we see on R1:

H1#show ipv6 routers 
Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
  Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
  HomeAgentFlag=0, Preference=Medium
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:DB8:0:1::/64 onlink autoconfig
    Valid lifetime 2592000, preferred lifetime 604800
Router FE80::211:BBFF:FE0B:3641 on GigabitEthernet0/1, last update 2 min
  Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
  HomeAgentFlag=0, Preference=High
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:DB8:BAD:BAD::/64 onlink autoconfig
    Valid lifetime 2592000, preferred lifetime 604800

H1 sees the RA, autoconfigures an IPv6 address with the 2001:DB8:BAD:BAD::/64 prefix and also uses H2 as a default route:

H1#show ipv6 route static 

S   ::/0 [2/0]
     via FE80::211:BBFF:FE0B:3641, GigabitEthernet0/1

That’s pretty bad…H2 just hijacked all outgoing traffic from H1.

Let’s prevent this from happening. On my switch, I’ll create a new RA guard policy called hosts where the device role is “host”:

SW1(config)#ipv6 nd raguard policy HOSTS
SW1(config-nd-raguard)#device-role host

With the host device role, all RAs and router redirect messages will be blocked. We need to enable this policy on the interface:

SW1(config)#interface GigabitEthernet 0/2
SW1(config-if)#ipv6 nd raguard attach-policy HOSTS
The policy that I just created doesn’t have any criteria, except for the device-role but “host” is the default. I also could have used the ipv6 nd raguard command on the interface without any parameters and the end result would be the same. When we look at the router policy, you’ll see how you can add criteria.

Here’s how you can verify which policies you have activated on what interfaces:

SW1#show ipv6 nd raguard policy HOSTS
Policy HOSTS configuration: 
  device-role host
Policy HOSTS is applied on the following targets: 
Target               Type  Policy               Feature        Target range
Gi0/2                PORT  HOSTS                RA guard       vlan all

Let’s see it in action though. We’ll enable a debug on H2 so we can see when it sends a router advertisement:

H2#debug ipv6 nd 
  ICMP Neighbor Discovery events debugging is on

And on the switch we’ll enable RA guard debugging:

SW1#debug ipv6 snooping raguard
  IPv6 snooping - RA guard debugging is on

After a few seconds, we’ll see that H2 sends a router advertisement:

H2#
ICMPv6-ND: Sending RA from FE80::211:BBFF:FE0B:3641 to FF02::1 on GigabitEthernet0/1
ICMPv6-ND:     MTU = 1504
ICMPv6-ND:     prefix = 2001:DB8:BAD:BAD::/64 onlink autoconfig
ICMPv6-ND:            2592000/604800 (valid/preferred)

Our switch will block this RA:

SW1#
SISF[RAG]: Gi0/2 vlan 123 RA Guard setting sec level to GUARD
SISF[RAG]: Gi0/2 vlan 123 RA received by RA guard on Gi0/2 from FE80::211:BBFF:FE0B:3641
SISF[RAG]: Gi0/2 vlan 123     option 1 : ND_OPT_SOURCE_LINKADDR
SISF[RAG]: Gi0/2 vlan 123     option 3 : ND_OPT_PREFIX_INFORMATION
SISF[RAG]: Gi0/2 vlan 123     option 5 : ND_OPT_MTU
SISF[RAG]: Gi0/2 vlan 123 !Not a router port: all router messages disallowed
SISF[RAG]: Gi0/2 vlan 123 ! DROP ROUTER-ADVERT  src FE80::211:BBFF:FE0B:3641 dst FF02::1 reason = 3

The debug output is nice and clean. Since this is not a router port, all router advertisements are dropped. Besides the debug command, there is also a show command that tells you the number of drops:

SW1#show ipv6 snooping counters interface GigabitEthernet 0/2
Received messages on Gi0/2:
Protocol        Protocol message
NDP             RA[3] 
DHCPv6          

Bridged messages from Gi0/2:
Protocol        Protocol message
NDP             
DHCPv6          

Dropped messages on Gi0/2:
Feature         Protocol Msg [Total dropped]
RA guard        NDP      RA  [3]
                reason:  Message unauthorized on port [3]

This is a good feature to block rogue RAs. I should have implemented this before H1 received the first RA though:

H1#show ipv6 routers 
Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
  Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
  HomeAgentFlag=0, Preference=Medium
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:DB8:0:1::/64 onlink autoconfig
    Valid lifetime 2592000, preferred lifetime 604800
Router FE80::211:BBFF:FE0B:3641 on GigabitEthernet0/1, last update 8 min
  Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
  HomeAgentFlag=0, Preference=High
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:DB8:BAD:BAD::/64 onlink autoconfig
    Valid lifetime 2592000, preferred lifetime 604800

We can still see the RA from H2 because it has a lifetime of 1800 seconds. Eventually, it will timeout and disappear but until then, it will be used by H1.

Router Policy

What about the router policy? We didn’t have to configure anything to permit RAs from R1. What we can do, is create a policy called ROUTERS with some restrictions that define what R1 can or cannot put in its RAs:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

503 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hello Ray,

    In the RS, the source MAC address is the host’s MAC address, the destination is the “all routers multicast” destination FF02::2.

    About the “shutdown procedure”, I just labbed this up to see how it works. Take a look at this wireshark capture:

    https://www.cloudshark.org/captures/69fd7a31fe57

    The first packet (length 118) is a regular router advertisement. The second packet (length 102) is sent when the interface is shut but also when you reload the router.

    The difference between the two is that in the “goodbye” router advertisement, all ICMPv6 options

    ... Continue reading in our forum

  2. Hello Carlo

    Yes, RAs are sent out periodically every few seconds. However, they are also sent as responses to Router Solicitations (RS) when an IPv6 device requests information during the SLAAC process. More on SLAAC can be found at this lesson:

    ... Continue reading in our forum

  3. So I see this Lifetime 1800 sec in show ipv6 routers output, I guess that´s like a hold time in OSPF, how often is hello/keepalive timer sent? in IPv6 RA

  4. Hello Carlo

    The lifetime is the amount of time that a device will consider the specific router as its default router, unless informed otherwise. By default, this value is set to 1800 seconds, or 30 minutes. The RA advertisement interval, which is how often an RA is sent, is set to 30 seconds by default. Both the lifetime and the advertisement intervals can be modified on a per interface basis using the following commands respectively:

    R1(config-if)# ipv6 nd ra interval ?
        RA Interval (sec)
      msec      Interval in milliseconds
    

    and

    R1(config-if)# ipv6 nd 
    ... Continue reading in our forum

4 more replies! Ask a question or join the discussion by visiting our Community Forum