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 RAcd daemon 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 text and encoded ICMPv6 options. 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 composability.
TODO: All of the above.
- Test raw ICMPv6 reception on Linux. Kernel may intercept RA messages.
The system specific racd-script we ship for Linux operates under two main guiding principles: multihoming and IPv6-monostack are the new normal as such we support:
- Painfree multihomed routing using source-specific routes.
- IP VRFs aka multiple route-tables with simple filters.
- RA route options, unlike Linux’s defaults (which are RFC violating)
- RDNSSD with reasonably secure per-zone query routing.
- NAT64 prefix discovery through PREF64 or ipv4only.arpa
- TODO: We need a good tun based translator for ipv4 literal support tayga is slow and broken.
- Highly scriptable, can support new RA options without patching, unlike Linux.
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 (cf. TunnelCrack).
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.
((Aspirational fiction ahead ;-)) Currently we only support configuring knot-resolver and unbound through a drop-in config file as no other DNS resolvers allow either synthesizing DNS64 itself or validating DNS64 answers using DNSSEC.
We explicitly do not support resolvconf or openresolv. They still live in the old single-homed host model, just get in the way and should be deprecated. However we’re hoping systemd-resolved will support combing DNSSEC and DNS64 eventually.
- RFC4443: ICMPv6, specifies option format
- RFC4861: IPv6 Neighbour Discovery, specifies RAs and related ICMPv6 options
- RFC4191: RA Route option and default router preference
- RFC8028: Router selection under multihoming
- NAT64 discovery
- RFC7050+RFC8880, through DNS64 and
- RFC8781, through RA PREF64 option.
- RFC6147 DNS64 operation (delegated to DNS backend)
Beware: RFC6980: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
Relevant: RFC4311 IPv6 Host-to-Router Load Sharing RFC4389 Neighbor Discovery Proxies (ND Proxy) – assigns an RA flag