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/4Xida2quI'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.pngThe 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 DROPip6tables -P INPUT DROPiptables -P FORWARD DROPip6tables -P FORWARD DROPiptables -A INPUT -i lo -j ACCEPTiptables -A OUTPUT -o lo -j ACCEPTip6tables -A INPUT -i lo -j ACCEPTip6tables -A OUTPUT -o lo -j ACCEPTiptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTip6tables -I INPUT  -p icmpv6 -j ACCEPTTried 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 outputDestination 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 1462Router'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;    };};
IPv6 connections timeout
debian;networking;ipv6;timeout
On automatic configuration of IPv6 addressesCurrently, 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 NetworkManagerSince 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=autoYou 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 packetsFor simple testing, make the firewall permissive:ip6tables -P INPUT ACCEPTip6tables -F INPUTip6tables -P OUTPUT ACCEPTip6tables -F OUTPUTMake sure you're not using privacy extensionsThere 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 = 0Normally 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 timingFrom 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 configurationThe 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 notesYou 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.