Investigate sending RAs on behalf of an actual router

[mdlayher]

@skoef writes:

I have a question that relates to this issue but is unrelated to WireGuard however: I'm currently running a RAD that I've built myself to send out router advertisements on behalf of my actual router. Basically the trick is to use the router's link local address in the router advertisement instead of the interface's which is sending the RA.

This wouldn't be possible in the current implementation either since the hardwareaddr is taken from the interface from the dialcontext, but if CoreRAD would allow me to do this, I could replace my own implementation for CoreRAD right away: it has everything I need and then some.

Would this be something that CoreRAD could offer, or is it perhaps against some principal ideas behind CoreRAD and/or hardcore violating RFCs (didn't check but can imagine). Otherwise I would gladly send in a PR for this feature!

I'll need to think on this further and make sure it doesn't result in any weird behaviors to have a mismatch between the Ethernet source MAC and RA source MAC.

[mdlayher]

@skoef first, are you aware of another implementation such as radvd that supports this feature? I am aware that there is an NDP proxy functionality but as far as I can tell, that is primarily used for neighbor solicitation. But it's nothing I've ever deployed and thus have no experience with it.

[skoef]

For the company I work for, I've implemented this. Due to scaling issues I rewritten this in golang but never published it. Main advantage of that project is the ability to send targeted RA's per VM in a shared layer2 domain. This is useful for VPSes that each get a /64 allocated within a /48 that is managed by the actual router.

[mdlayher]

Interesting use case! I had wondered about how something like this might work in the past: a /48 assigned to the router, maybe DHCPv6-PD to give a /56 to each hypervisor, and then having the hypervisor advertise a /64 to each VM for SLAAC.

It isn't currently implemented, but CoreRAD is architected in such a way where it'd be possible to send an HTTP request to dynamically fetch configuration whenever an RA must be generated. This way, you could implement your MAC to prefix mapping via a tiny HTTP JSON service, and CoreRAD would just serve it up in NDP RA format.

If there's a concrete use case for that, I'd be happy to look into building out that HTTP interface.

[skoef]

I think 2 things prevent me from replacing my implementation with CoreRAD:

• the fact I can't specify the Source LLA's address through config (PR incoming for that)
• the Ethernet destination address of the frame with the ICMPv6 packet should be the MAC address of the VPS for a specific prefix (currently it is 33:33:00:00:00:01). This would cause the RA to be received by any VPS instead of the one for that particular range.

The HTTP JSON service would be nice-to-have but that could be worked around by a separate config generator, so that has no real priority for me.