Ubuntu Networking – Default IPv6 Route Keeps Disappearing

ipv6networkingUbuntu

I've got an dedicated server hosted by KimSufi that's running Ubuntu Server 18.04. While I've goto both an IPv4 address and an IPv6 address, I keep getting random dropouts on IPv6. Doing a ping -6 google.com when it's dropped out yields this:

Network is unreachable

If I try sudo ifup eth0`, then I get this:

RTNETLINK answers: File exists
Failed to bring up eth0.

…as the interface is already up – just IPv4 only. By executing ifup -n eth0 however, I can see a list of commands it executes when bringing the interface up. In particular, executing the following command appears to fix the issue temporarily:

/sbin/ip -family inet6 route add default via 2001:41d0:e:07ff:ff:ff:ff:ff

….then (after a bit of a delay), testing via ping -6 google.com works again.

However, it drops out again randomly soon after.

Does anyone know what's going on, and how I can stop the default IPv6 route from disappearing?

Edit: The IPv6 section of /etc/network/interfaces looks like this:

iface eth0 inet6 static
    address 2001:41d0:e:074b::1
    netmask 128
    dns-nameservers 2001:41d0:3:163::1
    post-up /sbin/ip -family inet6 route add 2001:41d0:e:07ff:ff:ff:ff:ff dev eth0
    post-up /sbin/ip -family inet6 route add default via 2001:41d0:e:07ff:ff:ff:ff:ff
    pre-down /sbin/ip -family inet6 route del default via 2001:41d0:e:07ff:ff:ff:ff:ff
    pre-down /sbin/ip -family inet6 route del 2001:41d0:e:07ff:ff:ff:ff:ff dev eth0

Best Answer

Based on comments provided so far, I would try replacing the routing on the interface config with the following:

post-up /sbin/ip -family inet6 route add default via fe80::1ee6:c7ff:fe52:740 dev eth0
pre-down /sbin/ip -family inet6 route del default via fe80::1ee6:c7ff:fe52:740 dev eth0

... and see if that has any affect on the reliabiltiy of the default route.

Related Solutions

Linux – IPv6 forwarding not working

Putting a /64 from inside this /48 space behind another router (your diy tunnelbox) will not work because your ISP's router does not route the traffic for this /64 back to your tunnelbox, but expects the hosts to be directly in the local subnet.

Your ISP should not put a /48 on the link, but use a /64 instead.

Either you'll need to do some proxy-arp magic (haven't been there, wouldn't do that) or you'll tell your ISP to put a /64 on link, e.g. the first /64 in the /48. Then, your ISP also has to add a route to some other part of your /48 via your tunnelserver. (been there, have that running at my ISP in colocation). A possibility is to ask to route a /56 inside the /48 to your tunnelbox, so you can create tunnels which have one or multiple /64 on the other side. For the tunnels itself you can either also use /64's from the /56, or use one /64 with something like a /80 as tunnel itself.

(Note: 2001:A000::/20 is address space in use by APNIC, if you want to hide your actual adresses, it's better to use an address range like 2001:db8::/32 which is meant to be used for documentation purpose)

Linux – IPv6 works only after ping to routing box

Are the clients' prefixes being manually assigned? Usually they should automatically find the router via Neighbor Discovery Protocol (during which the router sends out advertisements and assign them prefixes automatically), but it sounds like that step might be missing.

Additionally, the router advertisement should be including its link-layer address as an option in the ICMP header of the router advertisement. If this field is missing, the client won't know how to send data to the router. It sounds like this could be the case. The client doesn't know how to reach the router, until it sends out the Neighbor Discovery message and it receives an Neighbor Advertisement from the router (with the router flag in the ICMP message set).

To include the source link layer address in your router advertisements, add the following into your radvd.conf

AdvSourceLLAddress on;

Related Topic