IPv6 Router Advertisement (RA) is a Neighbor Discovery Protocol (NDP) ICMPv6 message that is used to communicate specific information (via flags) to IPv6 hosts (or a device that does both routing and ‘hosting’). RA messages are sent by routers periodically without solicitation and in response to Router Solicitation (RS) messages from the hosts, depending on your specific configuration and timers. IANA has an up-to-date list of all the flags that RA can be used for.
When do we need IPv6 RA?
Generally, we require and want to enable IPv6 RAs on a given link when said link is designed to be used for IPv6 addressing on a given Layer 2 domain (LAN). IPv6 addressing on a LAN is handled by two methods, Stateless Address Autoconfiguration (SLAAC) or DHCPv6. Both methods have one thing in common — IPv6 RAs.
IPv6 RA can be used for a combination of SLAAC + DHCPv6 using the O (other) flag, whereby we tell the hosts for non-address configuration-related parameters to communicate with a given DHCPv6 server instead.
This article gives an in-depth explanation of RA use cases.
When do we not need IPv6 RA?
Since IPv6 RAs are required and meant for LAN use cases for SLAAC/DHCPv6 and the ‘other’ information that can be provided for hosts — it has essentially zero use-case value for Point-to-Point (PtP) links, inter-AS links such as IP Transit, Private Network Interconnect (PNI) and IXP LAN connectivity.
Security
There are well-documented security risks related to IPv6 RA, which can be exaggerated when a network operator enables RA on interfaces that do not need it. Then there is another angle related to hyper-specific security issues that we cannot foresee — undiscovered security holes that an attacker may discover and exploit. Such a security hole could allow an attacker to crash a router’s OS or crash the corresponding daemon(s) simply by sending malformed RA packets. Even the godfather of network protocols, BGP, is not bullet-proof to malformed packets. For example, here and here from 2023 alone.
Performance and network noise
IPv6 NDP in general and to RA, specifically, relies on multicast routing on a given link. What this means is multicast packets are delivered to all devices on a network link, regardless of whether they are interested in receiving them or not. This can lead to unnecessary traffic load on the network — the usual BUM traffic.
Now imagine the situation in production at scale, where you have hundreds to thousands of members or devices in an Internet Exchange Point (IXP) LAN, where all members decided to ignore IPv6 RA configuration and are flooding IPv6 RAs. This is not a smart practice, is it?
Therefore, with all the potential performance and security risks that come with general misconfigurations and/or unneeded configurations (such as enabling IPv6 RA on interfaces that do not need it), as a network engineering professional, it is your responsibility (and in good faith) to ensure that IPv6 RA misconfigurations are completely avoided network-wide.
I did a quick packet capture on my port that is connected to ExtremeIX Bangalore, and as expected, I found some network operators who failed to correctly configure IPv6 RA on their equipment. For example, one member is using Cisco equipment and the other is using MikroTik equipment, which we derived from the MAC addresses.
What about vendor-default IPv6 RA behaviour?
Unfortunately, as usual in the world of networking, virtually no discussion is complete without vendor comparison — there are behavioural inconsistencies among network vendors.
| Vendor | Default IPv6 RA behaviour |
| Arista | Floods only RA MTU, but does respond to Router Solicitation |
| Cisco | Floods RAs by default |
| Cumulus Linux | RAs are disabled globally by default |
| Huawei | RAs are disabled globally by default |
| Juniper | RAs are disabled globally by default |
| MikroTik | Floods RAs by default |
As we can see in Table 1, different vendors have different behaviours. Below is the documentation of each vendor:
- Arista
- Cisco
- Cumulus Linux
- Huawei
- Juniper
- MikroTik does not explicitly state it, but you can find the configuration details and some explanation in my Edge/BNG guide.
I think the Huawei, Juniper, and Cumulus Linux approach makes the most sense. Instead of flooding RAs 24/7 on IPv6-enabled interfaces by default, they disabled RA globally by default allowing the user to enable RA on a per-interface basis as and when needed, therefore the end result is minimal to zero misconfigurations.
How to disable IPv6 RA
On Arista, you disable it on per per-interface basis:
# This command suppresses all RAs on interface vlan 200.
# interface vlan 200
# ipv6 nd ra disabled allOn Cisco, you disable it on per per-interface basis as well:
# This command suppresses all RAs on interface vlan 100.
# interface vlan 100
# ipv6 nd ra suppress allOn MikroTik, you disable it at the global level; enable it on per per-interface basis when required:
/ipv6 nd set [ find default=yes ] disabled=yesMy opinion on vendor implementations
The problem with varying implementations, documentation, and in some cases standards, is that it leads to Layer 8 overhead, and when we have Layer 8 overhead, it is a prime factor that can lead to misconfigurations, performance, or security-related issues. Humans, by nature, can make mistakes, be incompetent, and be unwilling to learn the correct information.
This article touched upon this specific subject of IPv6 RA, where the author emphasized that nothing has changed much from their previous presentation work:
Two years ago, at JANOG 44, I presented on the following IPv6 setting that I often see incorrectly used:
> ipv6 nd ra suppressUnfortunately, 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.
APNIC Blog
In the world of aviation, when a specific aeroplane hardware/software design or implementation is known to be a potential cause or factor for disaster, the responsible manufacturers and engineers will work to improve the design and implementation to minimize possible input errors from the human operator (pilot and copilot) and therefore potentially be life-saving in practice. The same kind of approach is found in automobile engineering, with a very famous example — the seatbelt.
Yet in the world of networking, a proactive mindset towards improving the human-network compatibility layer such as UI/UX, some quirky protocol behaviour or, in this case, vendor default behaviour, is something that is missing — what I am referring to specifically is Human Factors and Ergonomics (HFE). Somewhere, somehow, the networking industry either grew into (or started off) not really paying attention to ergonomics and I think this needs to change.
Therefore, I think vendors ought to do more and make proactive efforts with ‘sensible defaults’, not just for IPv6 RAs to be disabled by default on a global level, but for anything else we could think of that would warrant a sensible default.
IPv6 RA is an essential part of IPv6 SLAAC and DHCPv6, but it is important to remember that IPv6 RAs are not required nor suitable for all situations. Therefore, it should be explicitly disabled when not required and enabled only on an interface where you require its functionalities.
It would be appreciated if you could help me continue to provide valuable network engineering content by supporting my non-profit solitary efforts. Your donation will help me conduct valuable experiments. Click here to donate.
Daryll Swer is an IT and networking enthusiast (AS149794), driven by a passion for computer networking, particularly in the realm of IPv6 deployment. Through his ongoing research and insightful contributions, he offers valuable guidance and practical examples to empower professionals in leveraging the full potential of IPv6.
This post is adapted from the original at Daryll’s Blog.
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.
Ok