Infoblox Community

Disabling IPv6 Router Advertisements in the Data Center

IPv6 differs from IPv4 in a few key areas, perhaps most significantly in how IPv6 behaves on an Ethernet LAN.  IPv6 has far more reliance on ICMPv6 and on multicast, whereas IPv4 uses broadcasts for most administrative LAN traffic like ARP.  The IPv6 Neighbor Discovery Protocol (NDP) (RFC 4861) process includes essential functions that IPv6-capable nodes rely on.  However, the environment that you set up for your end-user access LANs will be different than your perimeter networks and the data center environment.  Therefore, you will likely want to have a different configuration in the data center than in other parts of the enterprise network.

 

ICMPv6 Router Advertisement Functionality

When a host joins the network, it sends an ICMPv6 Type 135 Neighbor Solicitation (NS) packet to perform Duplicate Address Detection (DAD) for its link-local address.  After the host determines its link-local address is safe to use, it then sends an ICMPv6 Type 133 Router Solicitation (RS) message to attempt to learn details about the network from the local router.  Upon receiving this RS, the router sends out an ICMPv6 type 134 Router Advertisement (RA) message so that the requesting host, and all others on that LAN segment, will have information about the LAN and how they should go about obtaining their global unicast address.  The router also periodically sends out the RA messages, typically every 200 seconds, to make sure all the nodes on the LAN have the current information about the local IPv6 prefix.  The RA also includes the prefix lifetime, the MTU size for the network, the router’s link-local IPv6 address and MAC address, among other details.  The ICMPv6 Router Advertisements (RAs) is an essential function on an IPv6 LAN and IPv6 will not properly function without it.

 

The ICMPv6 Router Advertisement (RA) that the router sends to the IPv6 all-nodes link-local multicast group address (FF02::1) will be received and processed by all the nodes on the LAN.  The RA contains a variety of valuable information within it, in addition to guidance to the nodes on the LAN about how they will obtain their IPv6 address.  The RA contains several bits that tell the node how it should behave:

  • Address Autoconfiguration Flag (A flag) indicates if stateless auto-configuration (SLAAC) should be used.
  • On-Link Flag (L flag) indicates that the prefix is “on-link” and local to this network.
  • Managed Address Configuration Flag (M flag) indicates that the nodes should use DHCPv6 to determine their interface identifier.
  • Other Stateful Configuration Flag (O flag) indicates that other information is available to help the node (e.g. DNS server information).

 

As soon as an IPv6 address is added to the router’s interface configuration, it immediately sends out an ICMPv6 Type 134 RA with the following flags set: A=1, L=1, M=0, O=0. These indicate to the nodes on the LAN that they should use SLAAC using the IPv6 prefix included in the RA.  Sending an RA to all-nodes on the LAN activates the global Internet reachability functionality within the IPv6 stack in all hosts on that network.  Those hosts immediately start to operate as if they are connected to the IPv6 Internet.  Therefore, all of the AAAA DNS query responses a host has been receiving from any DNS queries it sent are now seemingly reachable over IPv6 and IPv6 connections are attempted to these resolved addresses.

 

Do You Really Want RAs in your Data Center?

The multicast behavior of the RA sends this information to all IPv6-capable nodes on the LAN simultaneously.  On an end-user wired or wireless access network, it would be beneficial to have all the systems activate IPv6.  However, in a data center environment this may not be what you intend or want.  In a data center environment or server farm, you may prefer to turn up one server at a time with IPv6 connectivity.

 

In a data center environment, servers are typically statically addressed and this is certainly true for IPv4.  While, there exists the ability to use DHCP for IPv4 and create a static reservation for a server, this method is not as common as the technique to simply statically configure the server’s IPv4 address, default gateway, and DNS information.

 

In a data center environment, it may be desirable to turn up servers with IPv6 one at a time to allow for a greater degree of precision and reduce the amount of simultaneous application troubleshooting taking place.  IPv6-enabled servers with statically configured global IPv6 addresses do not need to receive the RA to learn their first-hop router: The first-hop router’s IPv6 address will be configured manually on the server.  This next-hop address can be either a global address for the local router, or the router’s link-local address for the interface to the server.  The IPv6-enabled host in the data center will also have static entries for its DNS server(s) and the DNS domain suffix search order list.

 

Disabling RAs on Routers

You may want to adjust the A/L/M/O bits sent in the RA to adjust behavior of how the end-nodes on the network will perform their dynamic IPv6 addressing.  On a typical end-node network where you might want to use SLAAC, the RA would contain the bits A=1, L=1, M=0, O=0.  If you wanted to provide DNS information to the end-nodes that would be using SLAAC, then you would configure stateless DHCPv6 and the RA would contain the bits A=1, L=1, M=0, O=1.  Alternatively, if you wanted to have the end-nodes use stateful DHCPv6, then the RA would contain the bits A=0, L=1, M=1, O=1.  However, in a data center environment you may want to use static addresses and disable dynamic addressing methods of SLAAC and DHCPv6.

 

Another alternative would be to completely suppress RA and RS messages altogether.  Suppressing IPv6 RSs and RAs allows you to turn on IPv6 one server at a time and much more deliberately deploy IPv6.  The trick is how you apply the configuration commands to the router and give it an IPv6 address without having it immediately send out the RA with the default SLAAC settings.  This can often lead to confusion because there are many IPv6 configuration commands available on a Cisco IOS router interface that seem like they result in the same behavior.

 

The first step to configuring a Cisco IOS interface for IPv6 is to enable the protocol on the interface.  This is done with the following commands:

 

interface vlan 100

 ipv6 enable

 

As soon as IPv6 is enabled on the router’s interface, the router will send out an RA. However, it won’t contain any prefix information and the M and O bits will be set to zero.  The host will then receive the RA and configure the router as its local default gateway. But the host will not have a global IPv6 address with which to communicate with the Internet or any other host (though communication between hosts on the same Layer-2 network could still take place via the link-local address).

 

Now, before we configure the IPv6 address on the router interface, we will want to disable RAs.  There are many IPv6 ND commands available on a Cisco IOS router and it may be confusing which technique we want to use to block the RAs from being sent by the data center router out to all the servers.

 

In your reading of Cisco IOS IPv6 commands, you might have come across the following command that looks like what we want.  But this command actually sends a periodic RA with the A-bit set to zero:

 

 ipv6 nd prefix 2001:db8:1234::/64 300 300 no-autoconfig

 

The following command also looks promising but it too periodically sends RAs (though they don’t have the prefix information and the M and O bits are set to zero):

 

 ipv6 nd prefix default no-advertise

 

Here’s another command that looks promising, but it actually prevents the router from configuring itself with information from RAs it receives from other routers connected via this interface.  The default behavior is already set to prevent the router from using RAs sent by other routers and using SLAAC to configure its own IPv6 interface address:

 

 no ipv6 nd autoconfig prefix

 

Another creative approach would be to set the RA lifetime to zero as a way to stop the RA from affecting hosts on the LAN.  This would be configured with the following command for the VLAN 100 interface:

 

 ipv6 nd ra lifetime 0

 

Another conceivable option would be to use an access control list (ACL) in the outbound direction on the router’s interface to stop the RA from being sent.  The following ACL will be configured first, which is set up to block all RAs, but allow all other IPv6 packets:

 

ipv6 access-list BLOCKRA

 deny icmp any any router-advertisement log

 permit ipv6 any any

 

The next step is to enable IPv6 on the interface, but not give it an IPv6 address yet:

 

interface vlan 100

 ipv6 enable

 ipv6 traffic-filter BLOCKRA out

 

Once this configuration is complete, you can configure the IPv6 address on the router’s interface and then check that the ACL entry is being used by inspecting the packet counter using the following command:

 

show ipv6 access-list

 

However, the problem with this approach is that the ACL doesn’t block packets that are originated by the router.  It would only block packets passing through the router’s data plane.  Therefore, this technique is ineffective at blocking RAs originated by the router itself. 

 

It is possible to create an inbound ACL such as the one below, which blocks the router from receiving RS messages sent by the local hosts.  This ACL is applied in the inbound direction on the router’s interface to the hosts sending the Router Solicitations:

 

ipv6 access-list BLOCKRS

 deny icmp any any router-solicitation log

 permit ipv6 any any

interface vlan 100

 ipv6 traffic-filter BLOCKRS in

 

Another way to disable RAs from being sent out a router’s interface is to use the following command on the interface (in this example, VLAN 100):

 

 ipv6 nd ra suppress

 

This commands seems like it might do what we want. However, on some versions of Cisco IOS, this command will cause the router to respond to an RS but not send periodic RAs.  This is a problem, because today, virtually all modern operating systems are IPv6-enabled by default and would send an RS as soon as they join the network.  If only one system sends an RS to the FF02::2 all-routers link-local multicast group address, the router will respond with an RA, and the default RA settings will indicate that SLAAC should be used.  In newer Cisco IOS versions, it appears that this commands stops both the periodic RAs and prevents the response to a host-sent RS.

 

The command we are really searching for is the following: 

 

ipv6 nd ra suppress all

 

This command suppresses RAs, even in response to RSs that the router might receive from a host.  This command is available in IOS 15.X, so hopefully you are using a newer Cisco IOS version.

 

At this point, you are free to add the IPv6 address to the first-hop router’s interface and no RAs will be sent, immediately or otherwise.  In other words, all outgoing RAs would be blocked.

 

 ipv6 address 2001:db8:1000:1230::1/64

 

We can then check the IPv6 settings for this interface to make sure that we entered the configuration correctly.

 

show ipv6 interface vlan 100

 

When it comes to configuring a Cisco NX-OS switch, the commands are similar, but not exactly the same.  The following is an example of a similar routed interface.  However, the NX-OS switches lack the ability to completely suppress all RAs, in particular those sent in response to an RS.  Because of this, you might want to use the ACL technique shown above to block the incoming RS packets:

 

interface Ethernet 1/10

 ipv6 enable

 ipv6 nd suppress-ra

 ipv6 nd ra-lifetime lifetime 0

 ipv6 nd prefix default no-advertise

 

After this configuration is in place, we would then be ready to configure the IPv6 address on the interface:

 

 ipv6 address 2001:db8:1000:1230::1/64

 

After this configuration, we can then inspect the configuration of the interface:

 

show ipv6 interface Ethernet 1/10

 

Disable RAs on Hosts

Another approach would be to disable receiving RAs on the servers in the data center.  This would prevent the servers from receiving any RA, regardless of the A/L/M/O bits, and prevent it from performing any type of dynamic address configuration.  This technique is a more difficult approach to administer because it must be performed on every single node on the LAN prior to IPv6 being enabled on the first-hop router.  The administrative burden is much higher because it requires configuration on all servers rather than on the router itself.  However, the advantage of this technique is that it would prevent against any rogue RAs on the LAN from an attacker wanting to perform a man-in-the-middle attack.

 

To disable receiving RAs on a Windows host, you can use the following netsh command using the interface number:

 

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

 

Alternatively, you can check the settings of the interface using a command like this:

 

netsh interface ipv6 show interface "Local Area Connection"

 

Alternatively, you can use the PowerShell Set-NetIPInterface command as follows:

 

Set-NetIPInterface -InterfaceIndex 12 -RouterDiscovery Disabled -Dhcp Disabled

 

You can check the configuration using the PowerShell Get-NetIPInterface command.

It is possible to disable receiving and processing RAs on a Linux host using the following commands:

 

sudo sysctl -w net.ipv6.conf.eth1.accept_ra=0

echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra

echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra

 

Another option is to put configuration entries, like the following, into the /etc/sysctl.conf file:

 

net.ipv6.conf.all.autoconf = 0

net.ipv6.conf.all.accept_ra = 0

net.ipv6.conf.default.accept_ra=0

net.ipv6.conf.all.accept_ra=0

net.ipv6.conf.eth0.accept_ra=0

 

To disable RAs on a BSD system, you would use the following sysctl commands:

 

sysctl net.inet6.ip6.accept_rtadv=0

sysctl -w net.inet6.ip6.accept_rtadv=0

 

Keep in mind that this technique does not work on an Apple Mac OS X system because this is a read-only parameter.  See section 5.2 of the “IPv6 Hardening Guide for OS-X” by Antonios Atlasis.

It should also be mentioned that you could configure a host-based firewall such as NetFilter (ip6tables) to block the RA from being received on the host’s interface.

 

Summary

Manually configuring IT systems falls on one end of the spectrum.  Allowing devices and systems to self-provision and leverage automation is at the other end.  Each of these two generic configuration techniques has its advantages and disadvantages (as compared in the table below).

 

Manual Configuration

Automatic Configuration

High administrative overhead/burden

Low administrative overhead/burden

Static, no variability, deterministic

Dynamic, some variability, subject to change

Requires operator, prone to human error

Closed-loop software-driven system, some human error still possible

 

The choice of which method to use should be based on the requirements of the system and your overall IT practice.  When configuring IPv6, it may be preferable to more deliberately (and manually) configure it.  In a data center, this would mean using the manual configuration technique for addressing servers.  However, in the end-user access networks, dynamic configuration using DHCPv6 is preferred.

Comments
AI
on ‎07-26-2016 11:50 AM

Thanks for sharing your experience. That's interesting indeed - IPv6 seems less manageable to me. These annoying autoconfiguration mechanisms seem to be another headache for system administrators. But on the other hand... IPv6 appears to be more powerful.

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...