radvd

radvd is the router advertisement daemon for IPv6. It listens to router solicitations and sends router advertisements as described in "Neighbor Discovery for IP Version 6 (IPv6)" (RFC 4861). With these advertisements hosts can automatically configure their addresses and some other parameters. They also can choose a default router based on these advertisements. It also implements "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" (RFC6775) & many other related IPv6 RFCs. Please check the source & below table for details. Run 'make' and 'make install'. On BSD, you may need to use 'gmake'. Setting up radvd is very simple, so the most frequently asked questions have been about what radvd doesn't do... -- You don't. By the specification, routers ignore RAs. You'll probably need to use manual configuration. But you can't use the same prefix on two links in any case unless you use something like proxy-ND (draft-ietf-ipv6-ndproxy-04.txt). You may need to re-think your topology; prefix delegation (e.g., manually or with RFC3633) may help. -- You don't. The design philosophy of radvd is that it's not the router's configuration tool, but a route advertising daemon. You'll need to set up all the addresses, routes, etc. yourself. These tasks are something that system initscripts could possibly do instead. Notes: RFC3971, RFC6496 & related SEND None of the Secure Neighbor Discovery (SEND) options are implemented. This would be a substantial future project, and is a good candidate for corporate support: directly contributed code, funded and/or sponsored. Notes: RFC4861 The following parts of RFC4861 are not implemented: Support for few protocol constants defined in RFC 4861 Sec 10 is missing. section 6.2.5: when AdvSendAdvertisements changes to FALSE, radvd should send a final RA with zero Router Lifetime (radvd presently sends during shutdown). (SHOULD) section 6.2.8: if the link-local address of the router changes, it should multicast a few RAs from the old address with zero router lifetime, and a few from the new address. (SHOULD). Notes: RFC7222 The following parts of RFC7222 are not implemented: Section 5.1.3: Networks that serve battery-powered devices SHOULD NOT send multicast RAs too frequently (see Section 4) unless the information in the RA packet has substantially changed. If there is a desire to ensure that hosts pick up configuration changes quickly, those networks MAY send frequent Router Advertisements for a limited period of time (e.g., not more than one minute) immediately after a configuration change.