Two years ago, at JANOG 44, I presented on the following IPv6 setting that I often see incorrectly used:
> ipv6 nd ra suppress
Unfortunately, not much has changed since my presentation, so I’d like to discuss this with the wider network operator community to improve awareness of how and why this needs to be fixed.
Why is this setting bad?
In many situations, routers that are used for connecting to Internet Exchanges (IXs) and server farms need to suppress Router Advertisement (RA) packets from being sent to that segment. To do this, many network engineers have been using the following setting:
> ipv6 nd ra suppress
This setting will suppress RAs being sent but it is not enough. In practice, you should instead use the following setting:
> ipv6 nd ra suppress all
By not adding all, the router will return RAs when a Router Solicitation (RS) packet is received.
There is an example of when we do need to use the >ipv6 nd ra suppress command without all — for Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) — but you’re not using this protocol anymore, right? In ISATAP, RAs are sent through the tunnel. The router needs a command that only responds to RSs because it’s difficult to send multicast packets through tunnels. In the examples below, the RA packet in Case A (Figure 1) is a multicast packet, and the RA packet in CaseB is an unicast packet, so the command to send only the Case B (Figure 2) packet was useful in ISATAP.
What does this mean?
There are two cases when a router will send out an RA:
- At regular intervals (Case A), or
- In response to a RS (Case B).
Let’s look at them in order.
In the case of a router sending an RA at regular intervals (Figure 1), it stops exactly as you intended.
In the case of a router sending an RA in response to an RS (Figure 2), your router will send RAs. Of course, in a segment where the router suppresses the sending of RAs, the actual harm will not occur because it is assumed that devices that ignore RAs will actually be connected.
Even if there’s a problem, you’ll probably think, “There’s an unnecessary packet flowing”.
But what if you accidentally connect a device that is configured to receiving RAs? In many cases, that won’t be a problem. However, there are some cases where problems occur.
The RA in Case B is basically only sent when a node with auto-configuration enabled links up. If you use the address attached by this RA, you may not be able to communicate after the valid lifetime (after 30 days according to RFC 4861 6.2.1).
Below is an example of what happens in certain Linux cases:
- Auto-configuration is enabled.
- Receive a RA packet to own RS.
- An address of eui64 is generated by the RA (for example, 2001:db8::a00:27ff:feb4:76).
- Direct connect 2001:db8::/64 route is created.
- Set static address with /64 (for example, 2001:db8::dead:beaf).
- Specify next-hop as the default gateway using the address with 2001:db8::/64 instead of the link-local address.
- No RAs are sent to that segment until the valid lifetime is expired.
- Valid lifetime has passed and the eui64 address (2001:db8::a00:27ff:feb4:76) disappears.
- The static address (2001:db8::dead:beaf) does not disappear, but the 2001:db8::/64 route disappears from the direct route! (There are some versions that behave this way!)
- As a result, connectivity to the next-hop is lost. (More specifically, depending on the kernel version, writing a static route before receiving an RA may prevent a route that expires from being registered.)
- And communication is not possible.
The above is even easier to reproduce on some operating systems.
Add all
By including ‘all’ in your suppress RA router configuration you will be fine!
May the ‘all’ be with you!
Koichi is a director of the engineering department at Japan Internet Exchange Co., Ltd.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.