A problem was discovered on several production machines of a project
installed by client with Debian 8.9 with eth0 being managed by
NetworkManager (to get IP via DHCP):

Even though re6stnet was starting ok, it was either failing completely
to bring any of its interfaces up, or was loosing brought up interfaces
very fast. Symptoms were:

- openvpn links are broken after 60s (we use `--ping-exit 60` on both
  openvpn ends)

- I forced links to stay alive with `O--ping O10`

- I increased babel debug level `B-d B1`

- it indeed shows babel does not send hello

in despite openvpns running interfaces itself become down:

    root@...:/etc/re6stnet# ip link |grep re6st
    145: re6stnet-tcp: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    146: re6stnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    147: re6stnet2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    148: re6stnet3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    149: re6stnet4: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    150: re6stnet5: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    151: re6stnet6: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    152: re6stnet7: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    153: re6stnet8: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    154: re6stnet9: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100
    155: re6stnet10: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 100

nmcli says networkmanager does not manage it:

    root@...:/etc/re6stnet# nmcli d
    DEVICE        TYPE      STATE      CONNECTION
    eth0          ethernet  connected  Wired connection 1
    lo            loopback  unmanaged  --
    re6stnet-tcp  tap       unmanaged  --
    re6stnet1     tap       unmanaged  --
    re6stnet10    tap       unmanaged  --
    re6stnet2     tap       unmanaged  --
    re6stnet3     tap       unmanaged  --
    re6stnet4     tap       unmanaged  --
    re6stnet5     tap       unmanaged  --
    re6stnet6     tap       unmanaged  --
    re6stnet7     tap       unmanaged  --
    re6stnet8     tap       unmanaged  --
    re6stnet9     tap       unmanaged  --

however I see a lot of churn about re6stnetX in NM logs, e.g.

    <info> (re6stnet6): found matching connection 're6stnet6'
    <info> (re6stnet6): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
    <info> (re6stnet6): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
    <info> Activation (re6stnet6) starting connection 're6stnet6'
    <info> Activation (re6stnet6) Stage 1 of 5 (Device Prepare) scheduled...
    <info> Activation (re6stnet6) Stage 1 of 5 (Device Prepare) started...
    <info> (re6stnet6): device state change: disconnected -> prepare (reason 'none') [30 40 0]
    <info> Activation (re6stnet6) Stage 2 of 5 (Device Configure) scheduled...
    <info> Activation (re6stnet6) Stage 1 of 5 (Device Prepare) complete.
    <info> Activation (re6stnet6) Stage 2 of 5 (Device Configure) starting...
    <info> (re6stnet6): device state change: prepare -> config (reason 'none') [40 50 0]
    <info> Activation (re6stnet6) Stage 2 of 5 (Device Configure) successful.
    <info> Activation (re6stnet6) Stage 3 of 5 (IP Configure Start) scheduled.
    <info> Activation (re6stnet6) Stage 2 of 5 (Device Configure) complete.
    <info> Activation (re6stnet6) Stage 3 of 5 (IP Configure Start) started...
    <info> (re6stnet6): device state change: config -> ip-config (reason 'none') [50 70 0]
    <info> (re6stnet6): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]
    <info> Disabling autoconnect for connection 're6stnet6'.
    <warn> Activation (re6stnet6) failed for connection 're6stnet6'
    <info> Activation (re6stnet6) Stage 3 of 5 (IP Configure Start) complete.
    <info> (re6stnet6): device state change: failed -> disconnected (reason 'none') [120 30 0]
    <info> (re6stnet6): deactivating device (reason 'none') [0]
    <info> (re6stnet6): device state change: disconnected -> unmanaged (reason 'none') [30 10 0]
    <info> (re6stnet6): link disconnected

as the result re6stnet does not work

    root@...:/etc/re6stnet# ip -6 r
    unreachable 2001:67c:1254:e:70::/80 dev lo  proto kernel  metric 256  error -101
    unreachable 2001:67c:1254::/48 dev lo  metric 1024  error -101
    fe80::/64 dev eth0  proto kernel  metric 256

On a couple of other machines I see similar symptoms but with e.g. only 1
re6stnet interface staying up and thus "re6stnet working" but if it goes down
it will become all down.

Julien suggested it is really NetworkManager who messes things up and advised to
put `iface re6stnetX inet manual` lines into /etc/network/interfaces and that
worked - re6stnetX interfaces were no longer brought down and IPv6 started to
work everywhere.

So let's do this kind of setup by default, so that next poor soul does not need
to debug that whole conscious old NetworkManager from Debian 8 `nmcli d`
reporting is not telling the full truth and how to make re6stnet work.

I mean when people install re6st-node package on a Debian 8 box with
NetworkManager enabled it should be just working out of the box.

P.S. with recent NetworkManager (1.10.2, from current Debian testing)
     re6st-node works out of the box without this patch.

/cc @jm, @rafael, @Tyagov

The list of authorized IPs for private RPCs is now configurable.
This is required when the registry is not bound to localhost.

With this API, a client can query IPv6/IPv4 information outside re6stnet/babel
for reporting.

The API considers that the email is unique, else it returns the first
occurrence. For SlapOS integration, it is more than enough to consider
that email will not be repeated.

    addToken, isToken and DeleteToken are introduced to manage tokens created
    by other system (like SlapOS for example).

If token is present, raise conflict instead loop until timeout.

This is a useful class that can be used for other reasons.

Which happens when only re6stnet is restarted. The DIF must even be recreated
if the local certificate has changed, so that we can reconfigure the shim DIF.

Commit 6c4a5443 fixes a routing issue and
as usual, all nodes without exception must either route correctly or die:
in the future, we may want to force all nodes to upgrade.

"passive mode" means that re6stnet is configured to not create OpenVPN tunnels.

With :Author:, people may think I am the only author (which is not the case,
as shown by the Git history), whereas I just wanted to specify who is the lead
developer, i.e. the person to contact. And it's not a place to list here people
that are not involved anymore in the project.

- registry: make --dh mandatory
- node: retry if the registry returns nothing (instead of writing an empty file)

I forgot the case where 'config' has slightly different schema.
Now, we don't have any old network left to upgrade.