IPv6 HSRP and ND RA SUPPRESS

[markhamilton]

I have two 7206 routers and 2 3560G switches in a mesh.  I use HSRP to move the gateways around if there are failures etc...  I have been using this with ipv4 for some time and it works well.  We can have any 2 of the devices fail and the network will automatically heal.

In comes ipv6.

I set up ipv6 hsrp and assigned a link local gateway as detailed in any number of documents.  When I brought up ipv6 on a host in the vlan I was testing, it it got the hsrp virtual ip for the gateway just fine and everything was peachy.  The server did set itself up with another global unicast address besides the one I set statically.  *shrug*  Didn't think it was a big deal since I still have 18 quintillion more to play with.

Here is where the issue comes in.

I decided that there were several ways I could think of to abuse the router announcements or use them as a security hole.  I know, some people just say to secure your network.  I actually have some security on the network.  There are no open ports on any switch that are on any sensitive vlan.  Also if anything is removed from a switch or added to a switch we are instantly notified.  Still I wanted to explore removing the posibility of using the auto configuration as an easy way onto a network to exploit it or the router announcements as a way to mess up the network.

To remove some of this I turned off router announcements on both routers.

ipv6 nd ra suppress

Now, when I restarted the network on the server I expected to see no gateways.  It did change but not the way I expected.  Now instead of having one gateway to the hsrp virtual address like I had previously I now had two gateways to the actual link local ip address on the interface of each router.  I could still define the correct gateway in the server and things still worked but I don't know why the other gateways show up.  Shouldn't the suppress stop all router announcements?

BTW, this is on a 12.4 ios so there is no "ipv6 nd ra suppress all" command but the "ipv6 nd ra suppress" is supposed to supress both auto announcements and solicited announcements.

I decided to see if it was something strange with hsrp so I took it all out for ipv6.  The behavior didn't change.  It seems that even with the supress the routers are still answering to a solicitation.  Reading around on the internet I have seen other with a similar issue.  They recommend this:

ipv6 nd prefix default 3600 3600 no-autoconfig

Theoretically this will allow the announcements but tell the servers that they should not auto config a default gateway.  This also failed to stop the gateways from showing up with or withou the "ipv6 nd ra suppress."  It seems it is almost impossible to stop a cisco router from telling everyone it is the a router and gateway to me.

I suppose this could be the implementation of the IPv6 stack in the server.  I am using a Centos 6 box to test with.  It is possible that the server is ignoring the fact that the A bit is not set in the slaac packet.

At this point, to avoid the remote possibility of someone plugging into the network and advertising a default route I will just make sure auto config is off on all of the servers.  If they never solicit a router or listen to router announcements they will not care if a rogue router appears.

Any other thoughts on this?  Am I worrying about something that is a non issue?

Thanks

Mark

[Andrew Yourtchenko]

'but the "ipv6 nd ra suppress" is supposed to supress both auto announcements and solicited announcements.'  <-- no. "nd ra suppress", since its inception was suppressing only the periodic announcements.

But, the problem is really not in the routers -  the fact that the servers are configured to listen to the RAs is the problem.

You prevent 7200s from sending RAs, someone comes into the network and accidentally plugs another router, now what ?

So you need to make the servers disregard the RAs.

On linux you'll need to do "sysctl -w net.ipv6.conf.all.accept_ra=0" somewhere during the startup.

On MacOS X it's "sysctl -w net.inet6.ip6.accept_rtadv=0"

(maybe someone will chime in for Windows)

[markhamilton]

Thank you for your quick reply.  I had kind of come to the same conclusion by the end of my rambling above.  I thought about digging into ra guard in the switches but I think that would just add more complexity to the network and apparently there are still ways of getting around it.

On a Centos box you need to do something like this:

In the ifcfg-eth0 file:

IPV6INIT=yes

IPV6_AUTOCONF=no

IPV6_DEFAULTGW=fe80::1

IPV6_DEFAULTDEV=eth0

IPV6ADDR=2001:DB8::21/64

One gotya I ran into early on was the need for this in the /etc/sysconfig/network file:

NETWORKING_IPV6=yes

IPV6FORWARDING=no

IPV6_AUTOTUNNEL=no

IPV6_AUTOCONF=no

The important and non intuitive one is the last one.  Without the "IPV6_AUTOCONF=no" at the network level the server will not set "sysctl -w net.ipv6.conf.all.accept_ra=0" as you stated ubove.  This will cause all of the interfaces to autoconfig even when autoconfig is turned off at the interface.

I don't have any mac servers at the moment.  I try very hard to keep windows off the network although we have some customers that use it so I suppose I will have to experiment with it.

I guess I will have to look into ipv6 rogue router detection tools when I start to roll ipv6 out to the wireless and public networks.

[Andrew Yourtchenko]

Yep, I did not know the distro, so I just gave the setting responsible for the behavior... They all treat this differently.

For the first hop security stuff, we made a write-up at

http://docwiki.cisco.com/wiki/FHS - see if it is useful for you.

[James Leinweber]

Currently I wimp out on the snooping and guarding, and just block a few of the major rogue packets (DHCP service, redirect, router advertisement) on my Cisco 3750* switch ports, e.g.

interface GigabitEthernet1/0/1

ip access-group v4client in

ipv6 traffic-filter v6client in

ip access-list extended v4client

deny   udp any eq bootps any eq bootpc

deny   icmp any any redirect

permit ip any any

ipv6 access-list v6client

deny udp any eq 547 any eq 546

deny icmp any any router-advertisement

deny icmp any any redirect

permit ipv6 any any

-- Jim Leinweber, WI State Lab of Hygiene

[Peter Koltl]

Mark, what is your solution after all? Did you manage to force the HSRP routers to suppress RAs totally? Did you add static default routes to all servers pointing to the link-local address which might not be constant in case of a router replacement or reload?

You may also want to consider the options described in my blog post:

IPv6 host’s default router selection

[markhamilton]

As discussed above, I decided that supressing the RAs wasn't the full solution.  That doesn't stop a rogue router/device from sending RAs of their own.  I did some supression at the router but I feel the important part is to keep the servers talking to the routers I want not to what whatever device that sends a RA wants.

Anyway, in the end, I used static routes in the servers and disabling the servers autoconfig.  I did change things up a little by assigning a link local ip address for ipv6 HSRP instead of letting cisco create one.  That way I don't run into the problem you mentioned of the link-local address changing if a router is replaced.  When I assigned the address I just used the same numbering scheme that I used for the actual routable ipv6 address.  It just uses the link local prefix.  Not sure if that is the"accepted" method but it seems to work well for me.

Now the cisco router is happy that it has a link local address for HSRP and I have an address I can recognize to gateway to that will be unique on our network.  The address also will not change with the hardware since I assigned it.