gif(4) periodically fails to route packets

[Jay L. T. Cornwall]

Hi,

I'm running FreeBSD 7.0-RELEASE with an IPv6 tunnel through gif(4):

gif0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1280
	tunnel inet 82.70.152.20 --> 77.75.104.126
	inet6 fe80::20d:b9ff:fe14:1d18%gif0 prefixlen 64 scopeid 0x6
	inet6 2a01:348:6:13a::2 --> 2a01:348:6:13a::1 prefixlen 128

The tunnel works correctly for much of the time. Periodically, however, 
it appears to stop routing inbound packets (outbound remains fine) for 
hours at a time before beginning to work again with no intervention. I 
initially suspected a problem with the tunnel endpoint but I now have a 
packet capture providing evidence to the contrary.

For a ping6 to an IP routed through the tunnel these are the packets 
passing over the external (IPv4) interface:

17:10:51.640317 IP 82.70.152.20 > 77.75.104.126: IP6 2a01:348:6:13a::2 > 
2001:4860:0:1001::68: ICMP6, echo request, seq 0, length 16
17:10:51.691653 IP 77.75.104.126 > 82.70.152.20: IP6 
2001:4860:0:1001::68 > 2a01:348:6:13a::2: ICMP6, echo reply, seq 0, 
length 16
17:10:52.640631 IP 82.70.152.20 > 77.75.104.126: IP6 2a01:348:6:13a::2 > 
2001:4860:0:1001::68: ICMP6, echo request, seq 1, length 16
17:10:52.683821 IP 77.75.104.126 > 82.70.152.20: IP6 
2001:4860:0:1001::68 > 2a01:348:6:13a::2: ICMP6, echo reply, seq 1, 
length 16

Looks correct. Now the same packet capture on the gif0 interface:

17:10:51.640267 IP6 2a01:348:6:13a::2 > 2001:4860:0:1001::68: ICMP6, 
echo request, seq 0, length 16
17:10:52.640587 IP6 2a01:348:6:13a::2 > 2001:4860:0:1001::68: ICMP6, 
echo request, seq 1, length 16

It appears, for reasons beyond my understanding, that the tunnel is not 
aware of the return packets. No firewall is enabled that could be 
filtering the missing packets.

Shortly after the ping6 is sent my endpoint appears to be trying to find 
the remote endpoint:

17:10:56.639517 IP6 2a01:348:6:13a::2 > 2a01:348:6:13a::1: ICMP6, 
neighbor solicitation, who has 2a01:348:6:13a::1, length 24
17:10:57.639513 IP6 2a01:348:6:13a::2 > 2a01:348:6:13a::1: ICMP6, 
neighbor solicitation, who has 2a01:348:6:13a::1, length 24
17:10:58.639499 IP6 2a01:348:6:13a::2 > 2a01:348:6:13a::1: ICMP6, 
neighbor solicitation, who has 2a01:348:6:13a::1, length 24

But I am not sure if this is related as it successfully sends the ping6 
outbound regardless. radvd is running on the host if that makes a 
difference. To my knowledge its routing table is correct:

default             2a01:348:6:13a::1   UGS        gif0
2a01:348:6:13a::1   link#6              UHL        gif0
2a01:348:6:13a::2   link#6              UHL         lo0

Am I missing something?

-- 
Jay L. T. Cornwall
http://www.jcornwall.me.uk/