Re: point2point network interfaces cannot receive ipv6 packets

[Paul Goyette <paul%vps1.whooppee.com@localhost>]

Hmmm.

Mine is a simple tunnel using openvpn:

# ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 172.16.1.2 -> 172.16.1.1 netmask 0xffffffff
        inet6 fe80::7a24:afff:fe3d:6410%tun0 ->  prefixlen 64 scopeid 0x3
        inet6 fd17:1::2 ->  prefixlen 64

pokey:netbsd-local {183} ping6 fd17:1::1
PING6(56=40+8+8 bytes) fd17:1::2 --> fd17:1::1
16 bytes from fd17:1::1, icmp_seq=0 hlim=64 time=395.545 ms
16 bytes from fd17:1::1, icmp_seq=1 hlim=64 time=335.459 ms
16 bytes from fd17:1::1, icmp_seq=2 hlim=64 time=398.618 ms
^C
--- fd17:1::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 335.459/376.541/398.618/35.611 ms

I've got all appropriate route entries:

default                                 fd17:1::1 
UGS         -        -      -  tun0
...
fd17:1::/64                             fe80::7a24:afff:fe3d:6410 
UC          -        -      -  tun0
fd17:1::1                               fd17:1::2 
UHL         -        -      -  tun0
fd17:1::2                               fd17:1::2 
UHl         -        -      -  lo0


And ping6 to my tunnel's remote-ipv6 endpoint seems to work fine:

# ping6 fd17:1::1
PING6(56=40+8+8 bytes) fd17:1::2 --> fd17:1::1
16 bytes from fd17:1::1, icmp_seq=0 hlim=64 time=395.545 ms
16 bytes from fd17:1::1, icmp_seq=1 hlim=64 time=335.459 ms
16 bytes from fd17:1::1, icmp_seq=2 hlim=64 time=398.618 ms
^C
--- fd17:1::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 335.459/376.541/398.618/35.611 ms


Note that I am _not_ using Roy's 1-line patch to route.c ...


This is a kernel from about 24 hours ago, and userland from about a week 
ago.

(And yes, I know I'm using "local" IPv6 addresses - I'm waiting for a 
real block to be allocated...)


On Mon, 13 Apr 2015, Alan Barrett wrote:

> 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)

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------