I’ve grown increasingly weary of the many sharp edges in the Linux kernel implementation of IPv6 router-advertisements for challanging use-cases.
This userspace daemon takes over responsibility for receiving RAs, fixes a lot of the problems and goes back to the good’ol unix ways of composibility and portability in the process.
The main RAcd process does just one thing. It receives ICMPv6 router-advertisement packets from the network and presents the received information in a file hierarchy under /run/racd as both binary ICMPv6 options and text. Interested processes may subscribe to changes using their choice of file notification API or the system may configure RAcd to run a command.
To go along with this model we provide a reference implementation of managment functions as shell script for Linux.
This simple architecture is more powerful than it may seem: other mangment protocol daemons (say DHCPv6) can augment RAcd’s view of the world by writing to (some) of the files further increasing composability.
The racd-mgmt script we ship operates under two main guiding principles: multihoming is the new normal and IPv6-only is coming. As such we support:
- Painfree multihomed routing using source-specific routes.
- Multi route-table support with simple filters.
- RFC conformance, unlike Linux’s defaults. (route options ignored)
- RDNSSD with reasonably secure per-zone query routing.
- NAT64 prefix discovery through PREF64 or ipv4only.arpa
- Note: We need a good tun based translator for ipv4 literal support tayga is crusty.
- Highly scriptable, can support new RA options without patching, unlike Linux.
- Note: keep forward compatibility in mind
Mobile and multihomed hosts have a need for routing DNS requests that only make sense in the scope of a network to the right set of resolvers but this opens up a vulnerability as we cannot assume all networks run DNSSEC for their local domains let alone them being visible in the global DNS and so, unchecked, a malicious network could perform a DNS hijack for an arbitrary set of zones.
To prevent this we require network domains to either:
- not resolve in the global DNS at all or
- provide DNSSEC signatures.
In addition to plain DNSSEC support, all backends must support:
- DNSSEC validated DNS64 and
- per-zone query routing.