# IPV6 WAN fails after a few minutes (link-local ok)



## whoops (Dec 2, 2014)

I have a Hetzner server which has been happily running for some time, however I recently discovered IPv6 is dropping a few minutes after booting (I haven't narrowed down the exact time). So far I haven't been able to narrow down what in the network state is changing.

The routing table (via `netstat -r`) is the same (verified by diff), as is the output of `ifconfig` and `ndp -a`. There are no new messages in either dmesg or /var/log/messages after it fails.

The only difference I've been able to find is in a traceroute. When it's working `traceroute6 -v google.com` looks like so:

```
traceroute6 to google.com (2a00:1450:4001:803::1008) from 2a01:4f8:101:1129::1, 64 hops max, 12 byte packets
1
32 bytes from fe80::1%re0 to ff02::1:ff00:1: icmp type 135 (Neighbor Solicitation) code 0
0000: 2a0104f8 01011129 00000000 00000001
0010: 01010021 59c2004c 00000000 00000000
ex3k11.rz10.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  3328.677 ms  2.936 ms  0.671 ms
2  2a01:4f8:0:10:3:0:10:2 68 bytes of data to 2a01:4f8:101:1129::1  1.730 ms
  hos-tr2.juniper1.rz10.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  1.366 ms
  2a01:4f8:0:10:4:0:10:2 68 bytes of data to 2a01:4f8:101:1129::1  0.881 ms
3  core21.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  0.260 ms
  core22.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  0.241 ms
  core21.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  0.225 ms
4  core4.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  4.995 ms
  core4.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  4.828 ms
  core4.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  4.831 ms
5  juniper1.ffm.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  4.895 ms
  juniper4.ffm.hetzner.de 68 bytes of data to 2a01:4f8:101:1129::1  4.886 ms  4.874 ms
6  de-cix20.net.google.com 68 bytes of data to 2a01:4f8:101:1129::1  5.015 ms  5.025 ms  5.200 ms
7  2001:4860::1:0:70c3 68 bytes of data to 2a01:4f8:101:1129::1  6.009 ms  5.780 ms  8.392 ms
8  2001:4860:0:1::6d5 68 bytes of data to 2a01:4f8:101:1129::1  6.210 ms  5.976 ms  6.127 ms
9  2a00:1450:4001:803::11 68 bytes of data to 2a01:4f8:101:1129::1  5.899 ms
  2a00:1450:8000:38::9 68 bytes of data to 2a01:4f8:101:1129::1  5.828 ms
  2a00:1450:8000:38::7 68 bytes of data to 2a01:4f8:101:1129::1  5.757 ms
```

Note the solicitation only occurs occasionally. On the other hand, after it's failed it looks like so:

```
traceroute6 to google.com (2a00:1450:4001:803::1002) from 2a01:4f8:101:1129::1, 64 hops max, 12 byte packets
1
24 bytes from fe80::1%re0 to fe80::21d:92ff:fe32:cecb: icmp type 136 (Neighbor Advertisement) code 0
0000: fe800000 00000000 00000000 00000001
0010: 00000000 00000000
* * *
2  * * *
3  *
24 bytes from fe80::1%re0 to fe80::21d:92ff:fe32:cecb: icmp type 136 (Neighbor Advertisement) code 0
0000: fe800000 00000000 00000000 00000001
0010: 00000000 00000000
```

I've tried researching Neighbor Discovery/Advertisement but it hasn't pointed me to a solution.

My gateway fe80::1%re0 remains pingable even when IPv6 has failed.

Relevant lines from /etc/rc.conf

```
ifconfig_re0_ipv6="inet6 2a01:4f8:101:1129::1 prefixlen 64"
ipv6_defaultrouter="fe80::1%re0"
```

IPv6 Routing table:

```
Internet6:
Destination  Gateway  Flags  Netif Expire
::  localhost  UGRS  lo0
default  fe80::1%re0  UGS  re0
localhost  link#2  UH  lo0
::ffff:0.0.0.0  localhost  UGRS  lo0
2a01:4f8:101:1129: link#1  U  re0
eir.waltonhoops.co link#1  UHS  lo0
fe80::  localhost  UGRS  lo0
fe80::%re0  link#1  U  re0
fe80::21d:92ff:fe3 link#1  UHS  lo0
fe80::%lo0  link#2  U  lo0
fe80::1%lo0  link#2  UHS  lo0
ff01::%re0  fe80::21d:92ff:fe3 U  re0
ff01::%lo0  localhost  U  lo0
ff02::  localhost  UGRS  lo0
ff02::%re0  fe80::21d:92ff:fe3 U  re0
ff02::%lo0  localhost  U  lo0
```

With nothing in the logs I'm not sure where to look next. If anyone has any thoughts I'd greatly appreciate it.


----------



## SirDice (Dec 3, 2014)

whoops said:


> My gateway fe80::1%re0 remains pingable even when IPv6 has failed.


That means the issue is most likely happening _after_ the gateway, which is presumably the ISP's network.


----------



## Mazouab (Dec 7, 2014)

Maybe it's an ARP aging problem? If the lifetime of the ARP expires, that can happen.


----------



## PacketMan (Dec 7, 2014)

SirDice said:


> That means the issue is most likely happening _after_ the gateway, which is presumably the ISP's network.



Agreed.  _*I wonder if your ISP is losing its route back to you.*_ Do you have access to your gateway router? If you do, can you `ping` and `traceroute` successfully to a URL? What does that device's routing table look like when you have failure state? Look for both directions, i.e. back to your IPv6 machine, and to the Internet. Also try to see if a pattern exists. Reboot your machine and see if there is a pattern to when it breaks. Say for example it breaks with xx minutes/hours of reboot. That would suggest certain protocols that have dynamic mechanisms is where to further look. You can also try reaching out to your service provider, but it*'*s usually very appreciated when you contact them and can show lots of troubleshooting results and that you have narrowed it down.


----------



## ShelLuser (Dec 7, 2014)

Agreed with the above comments. It seems very likely that your firewall is somehow blocking your ISP thus they can't determine that your IPv6 address is still being used.

I had the same problem with my ISP. Its one of those differences between IPv4 and IPv6; you can actually block routers ("ARP requests") using your firewall. I eventually solved this by specifically allowing icmp6 to be accepted from my direct uplink.

Also see icmp6(4) for some information on this.


----------

