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.) [#rtadvrol]:

Network design: which systems perform which roles

Some basic IPv6 terminology

Getting some specific terminology straight is likely to be a requirement for correctly understanding some of this documentation related to automatic addressing. Know the difference between the terms “node” and “host”.

What may send router advertisements

After reviewing that terminology, it is clear that a “router” is not a “host”. Now, it is time for a statement about network design:

RFC 4861 (NDP for IPv6): section 6.2.4 (“Sending Unsolicited Router Advertisements”) says, “A host MUST NOT send Router Advertisement messages at any time.” Since the expected response to a “Router Solicitation” is a “Router Advertisement”, there may be little to no surprise that RFC 4861 (NDP for IPv6): section 6.2.6 (“Proccessing Router Soluticitations says, “A host MUST silently discard any received Router Solicitation messages.”

What this means is that if a device is going to be sending out “router advertisement” information, then that device must forward traffic. One way to do this is to make sure that the router, often known as the “default gateway”, provides not only the service of routing/forwarding, but also provides the services of being the automatic addressing server. (Also, the router provides these services at the same IPv6 address(es).)

This design may be different than what was quite commonly done with IPv4 (by using DHCP/IPv4). Before delving into this further to determine how to deal with that situation, here is a review of how things may have been done more flexibly with DHCP/IPv4. (This review may help to explain the just what the impact means to the network design.)

Comparison to DHCP/IPv4: automatic addressing servers

With DHCP/IPv4, one device could be the authorized DHCP server. It was possible (and recommended, for redundancy, but uncommon) to have multiple properly configured DHCP servers, although those DHCP servers did need to either serve out different address pools or, better, coordinate with each other so that they could serve from the same address pool. If there were multiple DHCP servers that did not coordinate, then there could be problems.

It was common for an automatic addressing server to be provided by the same equipment that forwarded network traffic. For instance, a device that was marketed as being a “firewall” could also hand out addresses using DHCP. This could often be found in small networks, such as a typical home network that used a firewall. If a firewall wasn't used (which was typically not recommended), a broadband Internet “modem” might act as the DHCP server. The point being made is that in either of these cases, the device that provides addressing information was the same device as what forwarded network traffic.

Another option, that has been successfully used for many networks, may be to have another device be the DHCP server. For instance, a computer that served as an authentication server (e.g. the “domain controller” for a Microsoft Windows Active Directory domain) might also provide DNS and DHCP services. That computer may not have acted as a router for the network, as the DHCP server could have directed other devices to use a dedicated network firewall as the “default gateway”. The firewall would typically have its DHCP server disabled. Devices would then check for a DHCP server, get a response from the authentication server, and realize that forwarded traffic needs to go to the firewall (since the firewall is the “default gateway”).

To be very clear, with this scenario just described, the device which was the automatic addressing server was a computer that was not acting as the network's router. This worked fine with IPv4. (However, this is not the recommended configuration for IPv6.)

Okay, enough of the IPv4 history lesson. Back to IPv6.

With IPv6 networks using “router advertisements”, the easiest thing to do is to make sure that every server providing “router advertisements” over NDP is also a router. This means that if a device isn't routing traffic, then it should not be an automatic addressing server that hands out routes using the “router advertisement” protocol.

How this gets implemented
Enforced rule

OpenBSD's manual page for rtadvd notes, “Router advertisements can be configured on a per-interface basis”. This may differ from RFC 4861 (NDP for IPv6) section 2 (“Terminology”), which defines a “node” as a “device” (which would imply the entire computer, including all of its interfaces) and then defines “router” and “host” as being nodes. In general, differing from RFCs is not recommended. However, in this particular case, the additional flexibility is probably a good thing, as it will probably not cause problems if things are implemented with sufficient design and care.

That being said, the rtadvd software does require that the computer running rtadvd is a router. Whether or not this is clearly spelled out in documentation, experience will show this is in fact a requirement: running rtadvd on a non-router will likely result in the software quitting, with the following being placed in the /var/log/messages file:

non zero router lifetime is specified for if0, which must not be allowed for hosts.  you must change router lifetime or enable IPv6 forwarding.

Setting the router lifetime value to zero is unlikely to let useful information be spread. The only approach which both fixes this situation and also is actually useful, is to turn the computer into a router. Turning the computer into a router is done by enabling IPv6 forwarding. (See: implementations (how to forward traffic).)

[#rtadvdyn]: Program design

The basic behavior of OpenBSD's rtadvd software also seems to be designed to work off of the assumption that the computer is an active router. (This may be less true for radvd, some other software which it seems may allow more configurability of routes in the config file. However, even if using radvd now, future flexibility may be more available if the network is designed in a way that works well with other major implementations.) Here are some more details about how OpenBSD's rtadvd seems designed to be run from a router.

OpenBSD's manual page for rtadvd states, “rtadvd reads all the interface routes from the routing table and advertises them as on-link prefixes.” “rtadvd also watches the routing table.  By default, if an interface direct route is added/deleted on an advertising interface and no static prefixes are specified by the configuration file, rtadvd adds/deletes the corresponding prefix to/from its advertising list, respectively.”

To clarify, OpenBSD's manual page for rtadvd.conf does not provide details about manually specifying routes. (The closest thing to doing that may be manually specifying some subnet prefixes.) Basically, this software determines, by itself, what routes it will or will not send. So, no custom configuration is required (nor supported). (This may be influenced with rtadvd's -s option, but even still, the system would need to have routes on its routing table when rtadvd starts up. There does not appear to be a separate configuration for routes.)

So, it makes sense to run this software on a machine that will be forwarding traffic, because a machine that forwards traffic is likely to be using the routes that should be getting sent to other hosts.

Exceptions: Violations of the rule

OpenBSD's man page for rtadvd says “hosts MUST NOT send Router Advertisement messages at any time (RFC 2461, Section 6.2.3). However, it would sometimes be useful to allow hosts to advertise some parameters such as prefix information and link MTU.” Basically, a choice was made to violate the documented standard in order to share some information that typically gets sent by router advertisements. However, even in this case, the sent information does not include the routes.

[#rtslrqhs]: What types of devices may be auto-configured

RFC 4861: NDP for IPv6: page 11 (in section 3: “Protocol Overview”) says “hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time.”

Note that the text does say “hosts”, not “routers”. Perhaps an implication is that routers may not send out “Router Solicitations”. A brief review of the RFC did not seem to show any clear statement saying that a router “MUST NOT” do this. So, presumably a router might be able to do this without badly violating any statement in the RFC.

However, client software might not cooperate with having a router send a “Router Solicitation”. The earliest version of OpenBSD with an online manual page for the rtsol command is OpenBSD 2.6. By the very next version, this was prohibited by the second paragraph of the “DESCRIPTION” section of the manual page. By OpenBSD 3.9, this second paragraph added some clarification details: the computer needs to not forward traffic (and the computer needs to accept router advertisements). (OpenBSD 5.0 also specified that redirections must be accepted.) Some related online documentation should be available by viewing OpenBSD manual page for rtsol/rtsold.

In general, it is anticipated that nodes will use NDP.