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

The M and O flags are always present in RA messages:

  • 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:

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 (alternative: RFC 6106, which is not yet widely implemented).

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.

Removing the on-link prefix from the RA messages will stop SLAAC, but also enforce PVLAN-like traffic flow. You have to remove the prefix; clearing the L flag won't stop SLAAC.

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.

This feature can be used to send direct traffic between IPv6 hosts in different IPv6 subnets.

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.

The L flag is not a security measure; hosts can use local IPv6 configuration to bypass the information sent in the RA messages.

2012-11-21 7:44Z - reworded some sections based on feedback from Tore Anderson and copied his list of gotchas into the blog post.

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 (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 (but there are very few switches/routers supporting 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 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.
  • For more information, read the IPv6 On-Link Determination blog post.

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

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. You can buy its recording or get it as part of the IPv6 trilogy or yearly subscription.

5 comments:

  1. Hi Ivan,

    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

    ReplyDelete
  2. A prefix information option with both A and L flags unset is meaningless and might as well be removed.
    --- 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?

    ReplyDelete
    Replies
    1. Follow-up post scheduled for early next week. I wouldn't want to bore my US readers with these details during the Thanksgiving weekend.

      Delete
  3. I don't think I'd be recommending L-less RA as a security / TE measure, the hosts could just as well configure the addressing statically!

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.