Re: point2point network interfaces cannot receive ipv6 packets

[Alan Barrett <apb%cequrux.com@localhost>]

On Mon, 13 Apr 2015, Paul Goyette wrote:
> I can confirm that this patch works on my tun device (carrying ipv6 
> inside ipv4).

This patch is not sufficient for my IPv6 tunnel.

I have a tunnel to sixxs.net, using aiccu (from pkgsrc/net/aiccu) 
in AYIYA mode.  The aiccu.conf file contains:

   username xxxxxx
   password xxxxxx
   protocol tic
   server tic.sixxs.net
   ipv6_interface tun3
   tunnel_id Txxxxxx
   daemonize true
   automatic true
   requiretls true
   pidfile /var/run/aiccu.pid
   defaultroute true
   behindnat true

The tunnel appears to come up, according to messages in 
syslog.  The tun3 device gets configured with an ipv6 address:

   $ ifconfig tun3
   tun3: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> mtu 1280
       inet6 fe80::xxxx:xxxx:xxxx:xxxx%tun3 ->  prefixlen 64 scopeid 0x6
       inet6 fe80::48:xxxx:xxxx:2%tun3 ->  prefixlen 64 scopeid 0x6
       inet6 2a01:348:xxxx:xxxx::2 -> 2a01:348:xxxx:xxxx::1 prefixlen 128

An ipv6 default route gets installed, pointing to the remote tunnel 
endpoint:

   $ netstat -rn -f inet6 | grep default
   default  2a01:348:xxxx:xxxx::1  UGS  -  -  -L  tun3

When I run "ping6 ${ipv6_address_of_remote_endpoint}", 
it appears that ping6 does not receive any responses to outgoing 
packets.  However, "tcpdump -i tun3" shows imp6 echo request and 
echo reply packets, as one would expect if the ping were working 
properly.

So it seems that incoming packets are decapsulated in userland, 
get as far as the part of the kernel that's visible to tcpdump, 
but are then lost or discarded, before making it to the socket 
interface to the application that should receive the packets.

This is on an i386 system, running a kernel from 2015-04-07 00:00 
UTC (with the one line patch to route.c that Roy posted), but with 
userland from 2015-01-27 00:00 UTC.  A kernel from 2015-01-27 
00:00 UTC does not have this problem.

--apb (Alan Barrett)