IPv6 Router Advertisements Deep Dive
I’m constantly getting questions about the intricate interworking of various flags present in IPv6 Router Advertisement messages. Here’s a (hopefully comprehensive) summary taken primarily from RFC 4861.
A Bit of the Theory
Router advertisement (RA) message include numerous flags. The M and O flags are always present:
- M – Managed Address Configuration. DHCPv6 is available for IPv6 address allocation.
- O – Other Configuration. Other configuration information (ex: DNS server IPv6 address) is available through DHCPv6.
RA messages may include prefix information. Each prefix has L and A flags:
- L – On-Link Flag. The prefix can be used for on-link determination (IPv6 addresses within that prefix are on the same L2 subnet).
- A – Address Configuration Flag. The prefix can be used for stateless address configuration (SLAAC).
Default Behavior: SLAAC
The most common IPv6 address allocation mechanism is SLAAC. If you want the hosts to use SLAAC, the routers MUST include one or more prefixes with A flag set in their RA messages.
The RA messages SHOULD have the O flag set to prompt the end hosts to use DHCPv6 to get DNS server IPv6 address, or you have to use RA RDNSS option (RFC 6106 – check whether it’s supported on your operating system).
Enforcing DHCPv6-only Address Assignment
Setting the M flag in RA messages is not enough to enforce IPv6 address assignment through DHCPv6. Some hosts (example: Windows 7) will use DHCPv6 to get an IPv6 address, but also create a pseudo-random IPv6 address using SLAAC privacy extensions (RFC 4941), and prefer the SLAAC-generated address.
You MUST clear the A flag in the prefixes advertised by the router to enforce DHCPv6-only address assignment.
Enforcing PVLAN-like Traffic Flow
You can use the on-link determination functionality to force local host-to-host traffic through the first-hop router. IPv6 hosts use RA messages to discover on-link prefixes: all prefixes advertised in RA messages with L bit set are in the same layer-2 domain.
To force the local host-to-host traffic through the first-hop router, clear the L flag or remove the on-link prefix from RA messages. Hosts can still use SLAAC (if the A flag is set) or DHCPv6 (if the M flag is set); the L flag affects the traffic flow, not the address assignment process.
More RA/SLAAC/DHCPv6 Gotchas (Courtesy of Tore Anderson):
Tore Anderson listed numerous other gotchas in his comment (thank you!). The italicized comments are mine.
- The O flag is meaningless if the M flag is set, as the O flag is basically a subset of the M flag (broken OS stack might require both though);
- When it comes to DNS server assignment, there are OS-es that only support DHCPv6 (for example, many Windows versions), and there are some that only support the RDNSS Option (for example, Mac OS X 10.6.x). Therefore, for maximum host compatibility, I recommend using both simultaneously (assuming your switch/router supports RDNSS).
- A prefix information option with both A and L flags unset is meaningless and might as well be removed.
- SLAAC can only occur for prefixes with a length of 64, so setting the A flag for other prefix lengths is meaningless. The L flag, on the other hand, works for any prefix length.
- DHCPv6 does not carry prefix length information, so a prefix information option with L=1 is the only way a host may acquire an on-link route.
- Receipt of a RA (with lifetime > 0) will cause the host to install a default route to the RA’s source address. This is the only way to advertise a default route in IPv6 (on Ethernet at least), as DHCPv6 cannot carry this information. Furthermore, the RA is guaranteed to come from a link-local address (within fe80::/64), which is crucial in making off-link prefixes work.
Revision History
- 2012-11-21
- Reworded some sections based on feedback from Tore Anderson and copied his list of gotchas into the blog post.
More information
You’ll find detailed description of RA and DHCPv6 functionality, design recommendations and router configurations in the Building Large IPv6 Service Provider Networks webinar (part of yearly subscription).
I disagree with a few things here:
- "You MUST clear the A flag in the prefixes advertised by the router to enforce DHCPv6 address assignment" - disagree. It is my understanding that the SLAAC (A flag) and DHCPv6 (M flag) are mutually independent. If you set both, the host will obtain addresses from both methods. RFC4861 section 3 says clearly that SLAAC and DHCPv6 is "*and*/or", not strictly "or".
- "Removing the on-link prefix from the RA messages will stop SLAAC" - if you by this mean "clearing the L flag", I disagree. SLAAC works for off-link prefixes just as well as for on-link ones. If you on the other hand meant "removing the prefix information option completely", I agree.
- "The routers supporting SLAAC ..." - this is somewhat misleading. Routers don't support SLAAC, hosts do. The only thing the router does is to inform the host that it may perform SLAAC or not by using the A flag.
Other than that, a few other things I've found that people often find confusing, include:
- The O flag is meaningless if the M flag is set, as the O flag is basically a subset of the M flag.
- When it comes to DNS server assignment, there are OS-es that only support DHCPv6 (e.g., Windows), and there are some that only support the RDNSS Option (e.g., Mac OS X 10.6.x). Therefore, for maximum host compatibility, I recommend using both simultaneously.
- A prefix information option with both A and L flags unset is meaningless and might as well be removed.
- SLAAC can only occur for prefixes with a length of 64, so setting the A flag for other prefix lenghts is meaningless. (The L flag, on the other hand, works for any prefix length.)
- DHCPv6 does not carry prefix length information, so a prefix information option with L=1 is the *only* way a host may acquire an on-link route.
- Receipt of a RA (with lifetime > 0) will cause the host to install a default route to the RA's source address. This is the *only* way to advertise a default route in IPv6 (on Ethernet at least), as DHCPv6 cannot carry this information. Furthermore, the RA is guaranteed to come from a link-local address (within fe80::/64), which is crucial in making off-link prefixes work.
Tore
--- Why is this?
BTW I'm really confused as to what on-link is. In IPv4 on-link meant that you would send a broadcast to find a neighbor rather than direct to the router. How does this compare to IPv6 and why cant SLAAC be on-link?
In other words, say you have 2 hosts configured with (Windows) NLB (whereas 2 hosts share the same IPv6 Address).
- Let's say the shared IPv6 Address is meant to be used as the Default Gateway on a LAN.
How would you go about it?
- I am confirming that NLB works very well for both IPv4 and IPv6.
The issue I have is with RAs (and the crippled DHCPv6 services not being able to send a *specific* Default Gateway).
I just had a case where an RA dropped to a VLAN where it doesn't belong. This caused servers to add an prefix to their routing tables as "on-link".
While it's possible to set the lifetime of the router itself to 0 and remove the default route from the routing table I haven't found a way to remove the on-link route automatically as well.
Do you know if this possible using NDP?
Thanks
Michael
> AdvValidLifetime seconds|infinity
>
> The length of time in seconds (relative to the time the packet is sent) that the
> prefix is valid for the purpose of on-link determination. The symbolic value infinity
> represents infinity (i.e. a value of all one bits (0xffffffff)). The valid lifetime is
> also used by RFC 4862.
>
> Note that clients will ignore AdvValidLifetime of an existing prefix if the lifetime is
> below two hours, as required in RFC 4862 Section 5.5.3 point e).
I have not read the RFC yet. At least I was able to reduce the lifetime of the routing table entry to two hours. Which however, if this happens in production, is not very helpful.
"A prefix information option with both A and L flags unset is meaningless and might as well be removed."
I'm not sure this is true. You can statically address a host, prevent it from also using SLAAC (A=0) and want to force everything to a default router (L=0).
I assume you could so some creative routing A=0,L=0 too. ie. one router is the default but another might be a better first hop for a specific prefix.
I've been trying to get private vlans working with FreeBSD hosts but when you statically assign an IPv6 address it adds the derived prefix to the prefix table as on-link, even with a router advertising the prefix with L=0. Same for Windows. One workaround is to use /128 as the prefixlen for the static address. If you're not using community vlans that's not great though as hosts in the same community would still talk via a router.
This behaviour of both OSes seems contrary to RFC 5942: "The assignment of an IPv6 address ... MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List."
> This behaviour of both OSes seems contrary to RFC 5942: "The assignment of an IPv6 address ... MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List."
One could argue that you're not assigning an address but a prefix to an interface as you specify the prefix length when configuring the interface IPv6 address.
As for "the hosts can talk through a router", that's always the case with private VLANs, and you have to stop that on the router.
Thanks for the reply Ivan.
When I said "that's not great though as hosts in the same community would still talk via a router" - this is not the behaviour you want on a community vlan (otherwise why would you create the community vlan in the first place?). It's isolated vlans where you want layer 2 segmentation.
Private vlans with inter-host controls performed at the router are made possible for IPv4 by a combination of local routing, no ip redirects, and local proxy-arp. However for IPv6, while the first two functions are possible (at least on a Cisco router), the third is not. It makes sense that IPv6 local proxy-arp is unavailable/impossible since ND is done with multicasts, not broadcasts. Therefore to get private vlans working with IPv6 you must be able to force the hosts to consider the prefix derived by their address and prefix length to be considered "off-link", and therefore they should forward all traffic to the default router. (Mimicking the local proxy-arp behaviour).
As I said both Windows and FreeBSD (I'm yet to test Linux) both add the derived prefix to the prefix table when you statically configure an address - despite what they may learn from an RA - and in violation of RFC 5942. On the other hand if they use SLAAC by learning the prefix from an RA, then if that RA says the prefix is not on-link (L=0) then neither OS adds the prefix to the prefix table.
So I have successfully implemented isolated private vlans with IPv6 with SLAAC/DHCPv6, but not static addressing. Well, static with /128 prefix lengths work.
Have you ever come across private vlans and IPv6?
Thanks.