IPv6 connections timeout

Question

I'm having issues with IPv6 connections. Only with those. They timeout roughly every 10 minutes (due to address renewal i suppose).

Happens with every debian based flavour of linux i tried in a year or so, x86 and x64, across different PCs, wired and wireless.

I'm currently using Linux Mint 17.1 with kernel 3.13.0-37-generic x86_64 (previously 3.2.0-60) and NetworkManager 0.9.8.8. Sometimes when i try to immediately restart the download i get "no route to host." because my IPv6 addresses seem to be momentarily gone.
Like this: http://pastebin.com/4Xida2qu

I'm running dual stack IPv4 - IPv6 (PPPoE), this is how my Netgear DGND3700v2 router (firmware version V1.1.00.22_1.00.22) is configured: http://i.imgur.com/YgxAyQb.png

The network profile in question is set to ignore IPv6 but i'm getting global IPv6 addresses anyway. Changing to auto does not make any difference. This is confusing but i guess it's just the kernel doing its job.

Firewall rules or lack thereof don't make any difference but they basically are:

iptables -P INPUT DROP
ip6tables -P INPUT DROP
iptables -P FORWARD DROP
ip6tables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -I INPUT  -p icmpv6 -j ACCEPT

Tried using DHCP instead of autoconf for the LAN, now i get no timeouts on windows but no ipv6 connectivity on linux (even though i appear to have a global address but i'm getting "network unreachable" errors anyway).

Relevant parts of tcpdump -vvni wlan0 icmp6 output

Destination unreachable:

19:25:05.381081 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted}
19:25:12.948944 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted}
19:25:18.446900 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted}

Router solicitation:

19:25:18.775794 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) {Unknown link-local ipv6 addr - redacted} > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
      source link-address option (1), length 8 (1): {Unknown MAC - redacted}
        0x0000:  {Unknown MAC - redacted}

Router advertisement:

19:25:18.777825 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) {GW's ipv6 - redacted} > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 112
    hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 30000s, retrans time 1000s
      prefix info option (3), length 32 (4): 2a01:2000:2001:91b1::/64, Flags [onlink, auto], valid time 360s, pref. time 360s
        0x0000:  40c0 0000 0168 0000 0168 0000 0000 2a01
        0x0010:  2000 2001 91b1 0000 0000 0000 0000
      unknown option (24), length 24 (3): 
        0x0000:  4000 0000 0168 2a01 2000 2001 91b1 0000
        0x0010:  0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 600s, addr: 2a01:2000:2001:91b1:861b:{Gateway}
        0x0000:  8800 0000 0258 2a01 2000 2001 91b1 861b
        0x0010:  {gateway MAC - redacted}
      mtu option (5), length 8 (1):  1492
        0x0000:  0000 0000 05d4
      source link-address option (1), length 8 (1): {gateway MAC - redacted}
        0x0000:  {gateway MAC - redacted}

I'm also getting something like this from time to time, don't know if it is of any importance:

17:09:42.546840 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) {GW's ipv6 - redacted} > {My pc's temp ipv6 addr - redacted}: [icmp6 sum ok] ICMP6, packet too big, mtu 1462

Router's radvd.conf (found using telnet)

interface group1 {
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag on;
    MaxRtrAdvInterval 600;
    MinRtrAdvInterval 198;
    AdvSourceLLAddress on;
    AdvReachableTime 30000;
    AdvRetransTimer 1000;
    AdvDefaultLifetime 1800;
    AdvCurHopLimit 64;
    AdvLinkMTU 1492;
    prefix 2a01:2000:2001:cd96::/64 {
        AdvPreferredLifetime 360;
        AdvValidLifetime 360;
        AdvOnLink on;
        AdvAutonomous on;
    };
    route 2a01:2000:2001:cd96::/64 {
            AdvRouteLifetime 360;
    };
    RDNSS 2a01:2000:2001:cd96:XXXX:XXXX:XXXX:XXXX  {
        AdvRDNSSOpen on;
    };
};

On automatic configuration of IPv6 addresses

Currently, IPv6 automatic configuration (in general) always relies on router discovery based on exchanges of ICMPv6 packets. The basic idea is to get the information about the network from the router to the client. Once the client receives the router advertisement with the information, it will also learn whether to use DHCP and especially whether to use it only for other configuration or also for address configuration. Specific configurations tested with NetworkManager are described in the Fedora Wiki.

Configuring IPv6 with NetworkManager

Since NetworkManager 0.9.6, the IPv6 support in NetworkManager is mostly usable but heavily relies on the limited kernel autoconfiguration features. Since NetworkManager 0.9.10 the IPv6 configuration is fully managed by the userspace and kernel is configured in ways that work much better. Current branch of NetworkManager is 1.0.

The following sections should help you configure a good testing setup of a host with NetworkManager, suitable for debugging similar issues.

Connection configuration

/etc/NetworkManager/system-connections/:

[ipv6]
method=auto

You must not use method=ignore when you expect your IPv6 connections to work properly. While ignore allows for a limited kernel based IPv6 configuration without DNS and stuff like that, the preferred way is to let NetworkManager handle the IPv6 configuration. We actually hope to remove ignore in the future. There are also [known bugs][1] in the IPv6 autoconfiguration standards that NetworkManager is attempting to work around when method=auto.

Make sure your firewall is not blocking important packets

For simple testing, make the firewall permissive:

ip6tables -P INPUT ACCEPT
ip6tables -F INPUT

ip6tables -P OUTPUT ACCEPT
ip6tables -F OUTPUT

Make sure you're not using privacy extensions

There have been issues with privacy extensions (also known as temporary addresses) in the past. You're using Linux Mint, which is one of the distributions that turn them on by default.

Note: The issue you are getting is not because of privacy extensions. You can probably skip this section but I'd like to keep it for anyone who might be debugging another issue with similar symptoms.

/etc/sysctl.conf:

net.ipv6.conf.default.use_tempaddr = 0

Normally you would just use all insetad of default but NetworkManager is reading the file and looking for default specifically. This setting should be enough to persuade NetworkManager that we don't want to use privacy extensions for any connections. NetworkManager should now ignore per-connection privacy configuration. Just restart NetworkManager afterwards.

Router solicitation and advertisement timing

From your updated question, I can see that when Networkmanager sends out router solicitation, the router immediately responds with router advertisement, which is good behavior from your host's point of view, as you receive the necessary information. The question is whether it happens always.

Also the router should send out router advertisements regularly, more often than the addresses time out. And your host should probably send out router solicitations when the time out is getting close, just in case you missed information from the router. With your version of NetworkManager, the would be a responsibility of the kernel.

From the other update, it is clear that the router doesn't send the router advertisement as often as it should. The validity of some of the information is as short as 360 seconds but the frequency of router advertisements is up to 600 seconds. The correct configuration would be to deliver you a couple of router advertisments in the 360 seconds time span just in case some of them get lost.

On the other hand, your host should probably ask for the information via router solicitation when the lifetime is about to expire. You can watch for solicitations and advertisements with tcpdump to see whether your kernel sends out a solicitation within roughly six minutes from the last advertisements. If it doesn't, the likely symptom is that your connection will only last for six minutes from the last advertisement, which means six or more minutes since the connection was established.

Recommended router configuration

The standards seem to recommend some values but I will rather use the common sense. On very bad links (which applies to wifi and others) you may lose a number of packets. So I would basically keep all lifetimes at least on good multiples of the maximum router advertisement interval.

Your MaxRtrAdvInterval is 600 seconds which is cool as you'll get updated information every ten minutes or less. The only purpose of MinRtrAdvInterval is to randomize the time a bit, so you can keep it or use 300 seconds for example. All of the lifetimes could be changed to e.g. five times the maximum interval, that would mean 3600 seconds which would mean all the information will be valid for an hour but updated roughly every ten minutes.

Final notes

You may want to contact the vendor to fix the timing in their machines. I don't know whether it's configurable. But changing the file directly will probably not help you as the router will rewrite it when commiting the configuration.

You may also want to contact kernel networking developers to comment on sending the router solicitation. Feel free to include me in any communication.

Comments

[Admin]

Please post the full details in your question. Do not link to some other site. Questions should be able to stand on their own, and not depend on a secondary site.

[Admin]

As slm said, you need to move this question from the Ubuntu Forums and post all relevant information here. I have a hunch but it will require customizing your kernel.

[Admin]

The packet too big ICMP(v6) message informs the original sender that he must repeat the communication but split in smaller pieces thus creating smaller packets. Ethernet can typically carry 1500 bytes but PPP over Ethernet uses 8 bytes for its own purpose, thus 1492 for the IP packet.

[Admin]

By the way you should get full connectivity on a combination of router discovery and DHCPv6 on Linux (just as well as on Windows) when using NetworkManager. You can see the data for both ICMPv6 and DHCPv6 using tcpdump just as well.

[ppparadox]

Question edited to add the tcpdump.

[ppparadox]

Thank you for your answers but there's something still unclear to me. You're talking about network manager but these timeouts happen even if network manager is set to ignore IPv6. Doesn't this indicate the scope of this issue may be (also) beyond NM? I'll go ahead and check those timings and report back ASAP anyway.

[Pavel Šimerda]

As now written in the answer, the scope of the issue is definitely in the router and the kernel but also in the fact that NetworkManager 0.9.8.8 relies on the kernel. Thanks for cooperation both here and on IRC, it's good to know about the real world issues.