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