src-prefix is about the 'from' option in ip-route. When the action value
matches exactly the source prefix of the route to install, the latter
is cleared at install. Otherwise, the route is not installed at all.

The purpose is mainly to provide a fallback for routers without support
of source-specific routes: only one route is kept, to a router that will
be able to route correctly.

TODO: man page

Commit a62b7c9b was broken in that
2 nodes with same id/hmac settings could not communicate when
1 of the 2 has no_hmac_verify.

To be pushed upstream.
Co-authored-by: Julien Muchembled <jm@nexedi.com>

TODO: documentation

To be pushed upstream.
Co-authored-by: Julien Muchembled <jm@nexedi.com>

This would cause an assertion failure whenever we
sent a Unicast Hello.  Thanks to Dave Taht.

We used to accept packets signed by any key.

This was completely wrong.

Also rename DIGEST_LEN to MAX_DIGEST_LEN.

  * clarify code flow, only checking for future state once
  * clarify error messages when MTU is guessed by including the MTU value

Flag to allow empty or wrong hmac in the packet trailer.

Known issues:

  - we create a neighbour entry before the first successful challenge;
  - we compute HMAC for each HMAC TLV rather than just once;
  - we only support sending one HMAC TLV;
  - we don't support key rotation.
Co-authored-by: Clara Do <clarado_perso@yahoo.fr>
Co-authored-by: Weronika Kolodziejak <weronika.kolodziejak@gmail.com>

As suggested by Christof Schulze.

It's a minor optimisation, but it makes me happy.

If no Hello has been buffered yet, insert an unscheduled Hello.
This only works if rfc6126-compatible is false.

This just implements the sending functions, it doesn't actually do anything
with them yet.

This fixes the case where a neighbour only sends unscheduled Hellos.

Incorrect message size when neighbour is not link-local.

Now that we have sub-TLVs and crypto keys, the previous value is no longer
suitable.