Babel-users mailing list threads:
- [Babel-users] Higher CPU usage since 1.9.x leads to instability on slow devices
  https://alioth-lists.debian.net/pipermail/babel-users/2020-May/003734.html
- [Babel-users] Removing source-specific for older kernels [was: Higher CPU usage since 1.9.x leads to instability on slow devices]
  https://alioth-lists.debian.net/pipermail/babel-users/2020-June/003742.html

Rules are obsoleted by the removal of the disambiguation code.
See https://alioth-lists.debian.net/pipermail/babel-users/2020-June/003744.html

The buffer is already zero'ed on declaration.

The C standard (§J.1-1) reads:
> The following [is] unspecified
> — The value of a union member other than the last one stored into (6.2.6.1).

Zero-ing the `raw` member first makes the value of the `nh` member
unspecified. It’s better to zeroise the whole union.

An empty IPv4 source prefix is represented by a v4mapped
default prefix.  This was not always the case.  Thanks to
Fabian Blaese.

The code was removed in 0111f5c1.

The original code was taken from netlink's manpage, which is buggy.
The buffer might not be aligned to struct nlmsghdr pointers.

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

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

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.