Skip to content

Instantly share code, notes, and snippets.

@DanielG
Last active September 10, 2023 21:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save DanielG/4d1cba309c9ed541038e2c2f7a346109 to your computer and use it in GitHub Desktop.
Save DanielG/4d1cba309c9ed541038e2c2f7a346109 to your computer and use it in GitHub Desktop.
[DESIGN] RAcd -- Extensible IPv6 Router Advertisement Client Daemon

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.

Architecture

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.

Features

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

DNS security, query routing and DNS64

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment