Almost this entire page may be a large result of various copy-and-paste from internal notes made earlier. Much of this may still need a decent amount of verification to be considered useful/reliable.

(Perhaps some phrases to Router Advertisements should be changed to the more generalized term of Router Discovery Messages.)

Router advertisement implementations

Overview information
[#ndpmoflg]: The configuring flags

A couple of the bits that are sent out as part of the router advertisement may be intended to affect a client's behavior regarding what network settings get configured using information from the NDP protocol. The method of configuring the server may vary based on what server software is being used. However, the meaning of at least some of these bits may be rather universally defined, so their meanings are discussed here (in a section that isn't specific to just one software implementation).

The “Router Advertisement Message Format”, described by RFC 2461 section 4.2 and RFC 4861 section 4.2 describes two bits that communicate whether stateful configuration, which RFC 4861 specifies to be implemented with DHCPv6, is used.

If the bit called the “Managed address configuration” flag is set to 1, RFC 4861 notes this “indicates that adddresses are available via the Dynamic Host Configuration Protocol [DHCPv6].” The older RFC 2461 says a value set to 1 means “hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration.” The phrase “in addition to” would indicate that SLAAC continues to be used even if DHCPv6 is also being used. However, when the newer RFC 4861 discusses this value being set to 1, this newer RFC does not reference stateless information being used at all.

If the bit named “Other configuration” flag is set (to a value of one), RFC 4861 notes this value “indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network.”

If the “Managed address configuration” bit is set to 1, it may be assumed that DHCPv6 provides such information, even if the “Other configuration” flag bit has a cleared value (of zero). This is clearly noted by RFC 4861 which notes, “the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.” RFC 2462 page 12 addresses this as well, stating, “when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well. It is not a valid configuration for a host to use stateful address autoconfiguration to request addresses only, without also accepting other configuration information.” This “Other configuration” flag bit only has meaning when the “Managed address configuration” flag is set to zero.

At least, that is the documented specification. In reality, practice may not match theory. The rtsold software from OpenBSD did not seem to want to run the appropriate DHCPv6 client software if the “Other” flag had its value cleared to zero, even if the “Managed” flag was set to one. So, if there is a possibility to set both values to a value of one, then doing so may increase compatibility with at least some software.

A useless comparison

A note, perhaps particularly for Microsoft Windows users, about the previous paragraph (where RFC 2462 page 12 is quoted): This is rather reversed of how Windows XP handles IPv4 auto-configuration. (How Windows XP handles IPv4 auto-configuration is a rather unrelated topic to IPv6's NDP, but this behavior seems a bit similar enough that the apparent similarity is being discussed.) With both Windows XP's IPv4 auto-configuration and also these IPv6's NDP configuration bits, there are two types of settings: automatic address assignment, and nameserver settings. Also, in both cases, one of those types of settings may rely on another.

However, the roles are reversed. With Windows XP, using automatic (DHCP-provided) addresses for DNS requires the client to use DHCP for addressing. If the GUI is used to make DNS be handled automatically, then it is a sure bet that DHCP addressing is also handled automatically. If DHCP addressing is handled automatically, then DNS settings might, or might not, be handled automatically.

In contrast, what RFC 2462 says is that using DHCPv6 for addressing requires that the client also pay attention to any DNS addresses that DHCPv6 provides. So in this case, the DNS settings are always honored if automatic addressing is enabled. If DNS settings, then the more optional part (which might or might not happen, depending on the configuration) is whether or not DHCPv6 is providing the automatic address assignment information.

(The point why this comparison is made is because it was thought that some experienced technicians might intuitvely make it, thinking that the behavior is the same. And, the key goal to making this comparison is to point out that the behavior is not the same; it is in fact reversed/opposite.)

(When describing the “Managed address configruation” and “other stateful configuration” flag bits in section 4.2, The older RFC 2461 simply referred to “the administered (stateful) protocol for” “autoconfiguration”, which describes DHCPv6, but DHCPv6 wasn't explicitly mentioned by name. That changed with the new RFC 4861.)

Those are the first two defined and named “flag” bits that help router advertisements determine what gets configured. There are six other bits that are described as being reserved, and should be zero. Update: That info may be outdated: FreeBSD manual page about rtadvd.conf describes such bits with the raflags variable, noting ways to use those bits. RFC 4191 section 2.2 may cover this.) There may be no point to using 0x80 since 0x40 would also be implied by an RFC. blog: IPv6-enabled home network with OpenBSD does reference the man pages which don't seem to clarify the need to convert the hexademical shown in documentation to decimal for implementation.

Wayback Machine @ copy of IPv6 DNS Server Discovery by DHCPv6 @ suggests may use raflags of "o" or raflags#64. For radvd, it appears this might be handled by AdvManagedFlag and AdvOtherConfigFlag (using the flag names that are reported by radvdump 22.4.2) TLDP on radvd: section 22.4.2: Debugging

Information provided

Even if another protocol like DHCPv6 is being used for automatic addressing, NDP/SLAAC may still be used for other network settings including the prefix length (even if it is typically a very standardized size of /64) and the default router, as noted by OpenBSD CVSWeb patch file for dhcp6s.conf.sample (version

How a default gateway is set

Perhaps: This information may still be speculative at the time of this writing. Please verify this before assuming it is quite true...

Perhaps the routing servers do not have settings about what default gateway should be used. Rather, perhaps the simple presense of a routing advertisement implies that the automatic addressing server is a router/forwarder of network traffic, and the client just uses the address that the addressing information came from.

ISC: Routing configuration over DHCPv6 discusses RA, stating, “Routers send Router Advertisement (RA) messages that contain their addresses and a list of routes that are reachable through them.” “This mechanism is an essential part of the Neighbor Discovery protocol. Currently, that is the only reasonable way of provisioning routing information to hosts. The other alternatives are usually avoided.”

DHCPv6 Route Options draft-ietf-mif-dhcpv6-route-option-03

RFC 4191: Router Preferences and More-Specific Routes

ICMP Router Discovery

RFC 1256 says, “Any router address advertised with a preference level of hex 80000000 is not to be used by the host as default router address; such an address may be omitted from the default router list, unless”...

Another option for handling a default gateway may be using a relevant DHCPv6 option... (see information on DHCPv6 and/or DNS (“Configuring system-wide DNS) for further details...)

radvd.conf manual page seems to indicate a place to define route definitions. OpenBSD manual page for rtadvd.conf may not have similar options. OpenBSD manual page for rtadvd states, “In particular, rtadvd reads all the interface routes from the routing table and advertises them as on-link prefixes.”

Multiple implementations may be available

An implementation may come with the operating system. The most convenient approach may be starting by checking out what implementation comes bundled with the operating system.

[#rtadoscf]: Configuring the “IPv6 support” code for compatibility with router advertisements

For an operating system that supports IPv6 using code that is part of the kernel, this sort of configuration may involve using tools that modify settings for the actively running kernel. (At least one example, of an operating system that is typically set up that way, is OpenBSD.)

Example: OpenBSD
Enable forwarding, disable accepting advertisements
echo Showing the current values...
sysctl net.inet6.ip6.accept_rtadv
sysctl net.inet6.ip6.forwarding
echo Change the values if they are not set to the desired values
sudo sysctl net.inet6.ip6.accept_rtadv=0
sudo sysctl net.inet6.ip6.forwarding=1

Once it is known that these values are desired, they may be enabled long term. This may be done using information in (or referenced by) the section about sysctl values. The following example command line uses the cpytobak program.

cpytobak /etc/sysctl.conf
echo ${VISUAL}
sudo ${VISUAL} /etc/sysctl.conf
[#rtadsvcf]: Configure server software

Find out what is included with the operating system


(Typically used by BSD operating systems. Mac OS X uses this.)

Configuring the kernel

Make sure to enable router advertisement support if needed. (With at least some implementations, this may involve changing the configuration options for the running operating system kernel. (See Supporting router advertisements: kernel config.) For BSD operating systems, that may be fairly safe to do, using sysctl command.)

Configuring rtadvd (the server software)

The following attempts to back up files, and then edits a file that is named after the network interface that this server will be communicating with.

echo If the following file does not exist, do not bother with trying to back it up.
ls -laF /etc/rtadvd.conf
for x in /etc/rtadvd.conf* /etc/rtadvd-*.cnf ; do cpytobak $x; done
echo ${VISUAL}
sudo $VISUAL /etc/rtadvd-if0.cnf

(This file may not have pre-existed, so may be blank.)

Recommended template for the file's contents:

# The following line starts configuration related to the if0 NIC
Customizations that should be performed

Customize the name of the NIC. (It shows up twice: once on a configuration line, as well as in a comment.)

Customize the IPv6 subnet. (Change the fd01:2345:6789:abcd:: to whichever IPv6 subnet is actually going to be used.)

In theory, update the subnet's “prefix length”. However, if SLAAC is going to be used, then the example length of /64 is already the perfect subnet size for SLAAC, and should not be changed.

If SLAAC is going to be used (without DHCPv6), set raflags should be set to zero. When (and if) DHCPv6 does get deployed, that value may need to be altered (as discussed in the section on Configuration flags in rtadvd.conf).

Additional notes

(These details may not be necessary for simple configuration, but provide references for people who may be willing to explore a bit further.)

The format for this file may be described by OpenBSD's manual page for rtadvd.conf. Basically, the first line contains the name of a NIC or a “capability”. A “capability” is essentially a set of configuration options. (The term “capability” refers to how this syntax is used by the “termcap” format, as documented by OpenBSD manual section 5 (file formats) manual page about termcap file, which is a file stored in /etc/.) The following example basically comes from OpenBSD's manual page, and shows a custom-defined capability called “default”. Later, a tc= makes a reference to that custom-defined “capability”.

Syntax notes: As it is noted that # is the comment character, perhaps most of that text is doing nothing other than documenting comments. Perhaps an equal sign is needed, like what is shown by the addr= part?

Addressing notes: since the IPv6 address starts with the hexadecimal digits of fd and the first segment of the IPv6 is four hexadecimal digits long (so there is not a leading zero), this does imply that the address being shown is a “private” address. After those first two hexadecimal digits, the remaining 14 hexadecimal digits (some of which will be visible digits, and some of which might be invisible leading zero digits) may be customized to any desired value for such a private address to work. If using a public address, the first two digits do not start with fd and the first digits may be assigned, so there may be fewer digits that are quite as customizable. Customized digits should not appear after the forth colon if a /64 subnet is being used.

Further customizing note: be sure to customize the name of the NIC (which is if0 although surely that needs to be customized).

[#rtadvdfl]: Configuration flags in rtadvd.conf

A piece that may want to be customized is raflags. These are discussed by the configuring flags. Very simply, if DHCPv6 is not being used (yet), many simple cases may just have this be set to zero. (In general, the best bet is likely to just set it to zero, unless there is a known reason to do otherwise. Of course, if there is such a known reason, then perhaps another value should be used.)

Setting the stateful configuration flag bit named “other” (to a value of one) indicates that DHCPv6 may have some information other than setting the IPv6 address. (For instance, DHCPv6 may provide details about DNS servers.) Setting the value of the stateful configuration flag big named “Managed” (to a value of one) causes DHCPv6 to also provide addressing information. (As noted in the overview, if the stateful configuration flag bit named “Managed” is set to a value of one, then the effect is that “Other” information is also used. Therefore, there is no need to set both bits to a value of one.)

Now, here is the really tricky part: the numbers placed in this configuration file do not visually look like the example numbers referenced in the official documentation. So, directly copying the numbers shown in the documentation will not produce the desired results. Ouch! Although the documentation does contain a degree of technical accuracy, this shameful mismatch is very cruel and unusual from the perspective of providing a nice end user experience. (And people have wondered why IPv6 adoption has been slow to pick up...)

The documentation for this software discusses setting the flags byte (meaning the byte that contains the flag bits) to a value such as 0x80. Skilled and experienced programmers might instantly be able to recognize that equates to a binary value of 10000000 (so perhaps that is why hexadecimal is discussed in the documentation). However, despite the documentation using hexadecimal, the syntax in the configuration file, does NOT support using hexadecimal. So, convert the desired hexadecimal value to a decimal value, and place that in the configuration file.

To set the “M” bit (“Managed address configuration” flag) to a value of 1, raflags (“router advertisement” flags) could be set to 128 which is equivalent to 10000000 in binary, and 0x80. To set the “O” bit (“Other configuration” flag) to a value of 1, raflags could be set to 64 which is equivalent to 01000000 in binary, and 0x40. To leave both of those bits cleared to a value of zero, set the value set to a value under 64 (and, unless other flags are supported and meant to be set to 1, using a value of zero for the entire flags bit may be a great choice). To set both flags to a value of one (which should not be necessary according to the RFC; this is discussed in the section about the configuring flags), set the value to 192 (which is equivalent to 11000000 in binary, and 0xc0).

Starting the server

Figure out the name of the NIC that will be receiving traffic. (This is technically unnecessary for a system with just a single NIC, but a sensible approach for habit that also works well for systems that do have multiple NICs.)


sudo rtadvd -dc /etc/rtadvd-if0.cnf if0

The -d parameter causes this server to remain in the foreground when it runs. Before worrying about backgrounding the process and having it run automatically, go ahead and test the server, by checking out the client software.

After trying to start the server, wait a second so that the software has a chance to quit, and then check that it is still running. (See the section about seeing what software is running.) If it is not running, check the log file (which would be the /var/run/messages for any messages that came in after trying to start the software. Fix what is needed: once it is running, make sure that a remote client can interact with the software. (See the section about client software.)

Improving the server configuration

If things are looking acceptable, then start by making the sysctl values remain long term.

Make sure that the program starts during the system startup. (In OpenBSD, the most appropriate place for this could be the NIC configuration files. e.g., if the NIC is named if0 then run:

cpytobak /etc/rtadvd-if0.cnf
cpytobak /etc/hostname.if0
echo !ortadvd -c /etc/rtadvd-\$if.cnf \$if | sudo tee -a /etc/hostname.if0

(There should be no need to customize the references to the “\$if” as that variable may be referenced literally. The backslash just escapes the dollar sign for the command line, and does not show up in the file.)


Try running the server with “ -D -f ”. That may provide error messages:

Insufficient permissions
CSS/HTML needed Mon/DD/YYYY hh:mm:ss: server6_init: failed to initialize control message authentication
Mon/DD/YYYY hh:mm:ss: server6_init: bind(insock): Operation not permitted
Solution: Use sudo
Configuration file issues
Wrong executable
Mon/DD/YYYY hh:mm:ss: configure_pool: /etc/dhcp6s.conf:## pool statement is server-only
CSS/HTML needed Quit specifying the configuration file for the server when running the executable file for the client.
Linux IPv6 Router Advertisement Daemon (radvd): says “Both Linux and BSD are supported.” To clarify, it seems this may be available for FreeBSD and NetBSD.
netsh for Microsoft Windows

(At the time of this writing, the following has not been recently tested by the author of this text. Hopefully it'll work well.)

The commands start with “ netsh interface ipv6 ”.

The first step is to support the interface. (Add the following after the start of the command: the start of the command was just mentioned.) set interface "1" advertise=enabled

The part in quotation marks there may be an index (a number) or a name: see available NICs.

Perhaps also: set interface "1" forwarding=enabled

Make sure the route is defined. e.g., to add a network traffic route. (Note: this may be a topic to investigate further: Does this need to be added to the NIC specifically, using netsh?

netsh interface ipv6 add route prefix=2001:db8::/32 "1" 2001:db8::1

Then make sure that the existing route gets published.

netsh interface ipv6 add route prefix=2001:db8::/32 publish=yes

(Used by Solaris)


Another command, perhaps used by AIX?


This may be used by Tru64, and perhaps OpenVMS?


Despite its name ending with the letter “d” (perhaps because it does support being backgrounded), the rtsold command is for the hosts (clients, not the SLAAC servers, a.k.a. routers). (See the section about automatic addressing (host/client implementations) for more details on that software.)

People who have just set up a server for NDP routing advertisements may want to rush off to check the client. Those who have done this a few times, and who have more patience, may want to keep focusing on server-side setup, and configure DHCP for IPv6 (DHCPv6, a.k.a. DHCP6) while still adjusting server-side automatic addressing.

Adding protocol security

SEND is covered by RFC 3971: SEcure Neighbor Discovery (SEND). There is some Errata for RFC 3971 that has been posted.

RFC 6104: Rogue IPv6 Router Advertisement Problem Statement

RFC 6105: Rogue IPv6 Router Advertisement Guard (and commentary: ISC Diary: IPv6 RA-Guard.

(This above details may be related to SEND, and be merged in with the following section.)

[#ipv6send]: Secure Neighbor Discovery (“SEND”)

RFC 3971 (and RFC 3972???) ( has brief overview), some IETF discussion, RFC 4861 (NDP IPv6) section 3.3 refers people to the document abbreviated SEND, which is RFC 3971.

Wikipedia's article for “Secure Network Discovery Protocol” states, “It is a subject to patent US 2008/0307516 A1”.

RFC 6104: Rogue IPv6 Router Advertisement Problem Statement: section 3.4: “SEcure Neighbor Discovery (SEND)”

(See also the documentation just prior to the start of this section; it may also have info related to SEND.)

Let software work automatically

If there are any kernel configuration changes, make them happen regularly. For instance, on a BSD operating system, back up the sysctl configuration file, and modify it. Relevant details are available in the sections about backing up (by copying files) and Configuring the “IPv6 support” code for compatibility with router advertisements.

Make sure that any created/modified configuration files are also suitably backed up. Once again, a reference is made to the section about backing up (by copying files).

Make sure that the server is automatically started when the system is started up. (At least for OpenBSD, a sensible place for this sort of configuration may be the configuration for the NIC that will be acting as a forwarding router.)