Multicast node discovery for fastd

hwundram commented 3 years ago

This patch series implements multicast node discovery (multicast handshakes) for fastd. Multicast node discovery allows for plug and play network setup of fastd instances on an ethernet backbone, without explicitly setting up IP addressing for peers. This PR forward-ports the patches in #11 for fastd-v21.

To enable multicast, use a bind statement of the form in the configuration:

bind [multicastaddr] port [port] [interface "[multicast interface]"] [source [unicast sourceaddr]] [interval [seconds]];

where interval can be zero to disable active multicast packets, and just passively listen for incoming multicast handshake packets. Further documentation on the implementation can be found in the patch requests.

Additionally, this PR changes the socket behaviour so that fastd always prefers IPv6 sockets with (possibly) IPv4-mapped addresses, even if binding to IPv4 only, except for the IPv4 multicast socket case, which remains on IPv4. This allows using IPV6_PKTINFO for source address retrieval for most use cases, even if IP_PKTINFO is unavailable. For the dual address family bind (two binds, for IPv4 and IPv6 respectively), this does not change the semantics.

Finally, by using getifaddrs(), the bind or source address can be specified as the token ll6, which is resolved to the first link-local IPv6 address that's retrieved from the specified bind interface.

This PR does not update the documentation with the new bind statement syntax as specified above.

neocturne commented 3 years ago

Thanks for updating the PR, I'll start reviewing this soon.

neocturne commented 3 years ago

Hi, thanks again for the PR, and sorry for the long delay. I have just started having a deeper look, but I'll add a few comments to the changes now.

neocturne commented 3 years ago

Generally, I think this PR tries to do too many things at once. Many commits mix coding style changes, cleanup with functional changes, and entirely new features, which makes the review very cumbersome. I understand that opportunities for cleanup often get noticed during the implementation of new features, but it would be of great benefit for my understanding of your changes if cleanups were committed separately.

To keep the code size impact of the multicast feature low, as much code as possible should be ifdef-guarded, so the feature can be configured out.

To make sure my high-level understanding of your changes is correct, does the new feature basically consist of the following parts?

Extension of bind configuration with multicast groups
Periodic sending of handshakes to the configured multicast groups
Ability to join multicast groups and reply to multicast handshakes Does this sound right, or am I forgetting something important?

Another question, are you (or is someone you're aware of) actually using IPv4 multicast, or could this feature be limited to IPv6 multicast to keep the code simpler?

neocturne / fastd

Multicast node discovery for fastd #13