Infoblox Community

Why You Must Use ICMPv6 Router Advertisements (RAs)

When a dual-protocol host joins a network it sends an ICMPv6 (type 133) Router Solicitation (RS) message to inquire about the local IPv6-capable router on the network.  The local router is tuned into the ff02::2 (all-router’s multicast group address) and will receive the RS message.  In response to the RS, the router immediately sends an ICMPv6 (type 134) Routing Advertisement (RA) message to the all nodes on the network (ff02::1, the all nodes multicast group address).  The router also sends the RA messages periodically (typically every 200 seconds) to keep the nodes informed of any changes to the addressing information for the LAN.  The RA message contains important information for nodes as well as which method they should use to obtain their IPv6 address.  The RA contains several flags that are set that the nodes watch for and use.

  • A-bit – Autonomous Address Autoconfiguration Flag tells the node it should perform stateless address assignment (SLAAC RFC 4862)
  • L-bit – On-Link Flag tells the node that the prefix listed in the RA is the local IPv6 address
  • M-bit – Managed Address Config Flag tells the host if it should use stateful DHCPv6 (RFC 3315) to acquire its address and other DHCPv6 options
  • O-bit – Other Config Flag tells the host that there is other information the router can provide (such as DNS information defined in Stateless DHCPv6 (RFC 3736))

ICMPv6 RAs are intended to help facilitate bootstrapping the connectivity of an IPv6 node on a network.  They tell the hosts on the LAN how they should go about acquiring their global unicast IPv6 address and become productive members of the network.  The RA also provides the end-node information about the local router and its ability to be the default gateway.  This process is well documented in Section 4 of the IETF RFC 4861 “Neighbor Discovery for IP version 6 (IPv6)”.

Unfortunately, there are some security risks related to ICMPv6 RA messages. On networks that do not yet use IPv6, the dual-stack hosts sit dormant waiting for an eventual RA message to awaken their IPv6 connectivity.  An attacker can craft a “rogue RA” message on these networks, get the dual-protocol nodes on the network to configure their IPv6 addresses and utilize the attacker’s system as their default gateway.  The attacker can then easily perform a Man-In-The-Middle (MITM) attack without the user’s knowledge using this technique.  This issue is documented in RFC 6104 “Rogue IPv6 Router Advertisement Problem Statement”.  On networks that already have IPv6 running, rogue RAs can destabilize the network (and still perform a MITM attack).  Rogue RA messages can be easily generated with The Hacker’s Choice IPv6 Attack Toolkit, Scapy, SI6 Networks IPv6 Toolkit, Nmap, and Evil FOCA, among other tools and methods.

There are methods to detect and block these rogue RA messages.  Utilities like NDPMon, Ramond, 6MoN, and others can be used to look for suspicious Neighbor Discovery Protocol (NDP) packets and detect invalid RA messages.  These tools function much like the old ARPWATCH program did for detecting ARP attacks on an IPv4 LAN.

There is a technique called “RA Guard” that can be implemented in an Ethernet switch to permit legitimate RAs from a valid router and block the malicious rogue RA messages.  This technique is documented in IETF RFC 6105 “IPv6 Router Advertisement Guard”.  There is also a very new RFC 7113 “Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)”.  A good example of improved first hop security (FHS) in IPv6 can be implemented in Cisco switches.

Unfortunately, there are also methods to avoid any rogue RA detection accomplished by NDP security methods.  Finding the ICMPv6 layer-4 header information could be made difficult by forcing the system to fully parse the IPv6 header structure.  An attacker can change the location of the RA in the IPv6 packet by using extension headers to avoid detection especially if security tools do not parse the entire RA message.  If an end-node receives an RA with a hop-by-hop extension header or an atomic fragment, the host disregards the header but still processes the RA normally.  This rogue RA attack is called “RA guard evasion”.  Legitimate RA messages should not include fragmentation or other headers.  There is some additional guidance along these lines documented in RFC 6980 “Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery”.

There are other beneficial uses of ICMPv6 RA messages on a LAN.  Another method of getting DNS information to IPv6 nodes is to leverage options within the RA to send the DNS server and domain search list.  Nodes that receive the RA can simply parse these options and get this DNS information and use it with their SLAAC auto-generated IPv6 addresses.  IETF RFC 6106 "IPv6 Router Advertisement Options for DNS Configuration" defines the Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) options within Router Advertisement (RA).  One of the challenges with RDNSS is getting support for it natively in the host operating systems.  This link provides some information on which OSs support this option.  There is also a RDNSS deamon for Linux (rdnssd).

Even if you intend to use DHCPv6 instead of SLAAC in your environment, you still need RA messages to function on the local LAN.  The RAs provide the default gateway information to an end node and, with the M-bit, inform the nodes that the LAN uses stateful DHCPv6.  DHCPv6 does not currently have an option to provide this information to the DHCPv6 client in the same way it is provided with DHCP for IPv4.  Providing the default gateway as a DHCPv6 option was proposed, but never made it into the standards.

DHCPv6 may be desirable in the desktop access portions of an enterprise network and DHCPv6 is absolutely essential in the service provider’s subscriber access networks.  However, organizations may not need DHCPv6 in a data center environment.  Most organizations will prefer to statically configure IPv6 address parameters on specific systems in the network environment.  Static address configuration may be preferred for systems that need to have a fixed, non-changing IPv6 address or for nodes that are unable to perform dynamic address assignment.  The systems in the networks that will most likely use this static IPv6 addressing technique are servers and systems within data center environments.  These servers could be on an internally-accessible networks, private/hybrid cloud infrastructures, or Internet publically-accessible network.  Any system that is going to have its address used in some form of firewall policy or access-control list will need a static address.

Servers within a data center environment would need to be configured with the following information to be able to operate correctly in an IPv6 environment

  • Static IPv6 address for its network interface
  • This address would be allocated from the IPAM system and registered within the DNS system with an AAAA resource record and an accompanying PTR record.
  • Static IPv6 default gateway
  • This could either be a global unicast address of the first-hop router or the Link-Local address of the first-hop router (e.g. FE80::1).
  • Static DNS server
  • This is the caching DNS resolver this system will use when it needs to perform DNS queries (e.g. configured within the /etc/resolv.conf)
  • DNS Domain Name
  • This is the domain name that the system will use in combination with the server's hostname to create its fully-qualified domain name (FQDN) (e.g. the domain suffix search order list)

Typically, servers will have a static IPv6 address assigned, But they will still use the information contained in the ICMPv6 (type 134) Router Advertisement (RA) message sent by the first-hop router to learn information about the default gateway.  RA messages contain the link-local address and the layer-2 (MAC) address of the first-hop router.  Servers can listen to these and use this information to auto-configure their default gateway.

If you want to disable sending of RA messages on a Cisco IOS router, you can use the following commands to accomplish this goal.

interface GigabitEthernet 0/12

  ipv6 address 2001:db8:1234:5678::1/64

  ipv6 nd prefix no-autoconfig

  ipv6 nd suppress-ra

  ipv6 nd ra suppress all

It is important to realize how important the ICMPv6 RA message is to the function of an IPv6-enabled LAN.  Security risks exist, but the attacker must be on-net or have compromised a node on the network to be able to perform these rogue RA MITM attacks.  Most enterprise organizations would prefer DHCPv6 for desktop LANs, but RAs are still needed on these networks.  In a data center, an organization may want to statically assign the address details to hosts and not use RA messages.  Regardless, people should not fear the RAs and learn to embrace them.

 

 

Comments
sumithgk
on ‎05-17-2016 07:26 AM

Really Informative post and it made me sign on to "Infoblox" !

AI
on ‎07-26-2016 10:53 AM

Yeah, so either one has to deal with Router Advertisments, or manually assign addresses. That would be just great if one can just use DHCPv6 for complete network configuration, but...

Infoblox Blogs
The company blog focuses on company updates, product announcements, and related topics covered by many of our...
The Infoblox Support Central Blog highlights recent Knowledge Base (KB) Articles meant to help customers answer...
Check out the Infoblox Security Blog to learn about various challenges our customers share with us, what Infoblox is...
IPv6 adoption can be intimidating. Even people with years of networking experience may break into a sweat thinking...
The Infoblox Community Blog highlights new features, functionality and information related to events, products and...