point2point network interfaces cannot receive ipv6 packets

[Takahiro HAYASHI]

hi,

Hi,

It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot
receive ipv6 packets.
This occurs on NetBSD/amd64 -current since Feb 27 2015.
For example, establishing gif tunnnel between 2 hosts.
[host1] <---> [host2]
192.168.0.1 192.168.0.2 ipv4 address of real interface
fd00::1 fd00::2 gif address
When I ping6, a host can send ICMPv6 ECHO(128), but the other host
returns ICMPv6 DST_UNREACH(1) code UNREACH_ADDR(3) to pinging host.

http://www.nerv.org/netbsd/?q=id:20150226T095446Z.75354d997222ae09acc944ba1c6cf573c3ea724b
This commit changes the route entry for gif as describe below
========== before ==========
Destination Gateway Flags Refs Use Mtu Interface
fd00::2 link#13 UHL 0 0 - lo0
========== before ==========
========== after ==========
Destination Gateway Flags Refs Use Mtu Interface
fd00::2 fd00::2 UH - - - gif0
========== after ==========
This route change caused the function flow change in ip6_input(), in
paticular the below line
http://nxr.netbsd.org/xref/src/sys/netinet6/ip6_input.c#497
After above commit, this statement become false, and then, the packets
is discarded through line#565.
I found the above reason, however I have no idea to fix this issue...

Thank you for your analysis.
Newer netstat shows gif0 route like this:

fd00::2 fd00::2 UHl - - - gif0

Could you file a PR?

I'll do.

Justin

[Kengo NAKAHARA]

Hi,

Post by Takahiro HAYASHI

It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot
receive ipv6 packets.

Could you file a PR?

I'll do.

Thank you for PR#49829.


Thanks,
--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-***@iij.ad.jp>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Hi

Sorry for the late response, been busy on the Spanish beaches!

It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot
receive ipv6 packets.
This occurs on NetBSD/amd64 -current since Feb 27 2015.
For example, establishing gif tunnnel between 2 hosts.
[host1] <---> [host2]
192.168.0.1 192.168.0.2 ipv4 address of real interface
fd00::1 fd00::2 gif address
When I ping6, a host can send ICMPv6 ECHO(128), but the other host
returns ICMPv6 DST_UNREACH(1) code UNREACH_ADDR(3) to pinging host.

http://www.nerv.org/netbsd/?q=id:20150226T095446Z.75354d997222ae09acc944ba1c6cf573c3ea724b

The following patch helps for me. It results in the RTF_LLINFO flag getting
set for the route for the interface.
The comment looks to be incorrect in any case.
Robert Swindells
Index: in6.c
===================================================================
RCS file: /cvsroot/src/sys/netinet6/in6.c,v
retrieving revision 1.186
diff -u -r1.186 in6.c
--- in6.c 7 Apr 2015 23:30:36 -0000 1.186
+++ in6.c 10 Apr 2015 16:10:31 -0000
@@ -1695,7 +1695,7 @@
/* Add ownaddr as loopback rtentry, if necessary (ex. on p2p link). */
if (newhost) {
/* set the rtrequest function to create llinfo */
- if ((ifp->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT)) == 0)
+ if ((ifp->if_flags & IFF_LOOPBACK) == 0)
ia->ia_ifa.ifa_rtrequest = nd6_rtrequest;
in6_ifaddlocal(&ia->ia_ifa);
} else {

This fixes the problem where you can now ping the fd00::2 address on
gif2, but it still lacks the same gateway as in the original netstat
output. A similar patch to sys/net/route.c is needed.

Index: net/route.c
===================================================================
RCS file: /cvsroot/src/sys/net/route.c,v
retrieving revision 1.142
diff -u -r1.142 route.c
--- net/route.c 7 Apr 2015 04:36:19 -0000 1.142
+++ net/route.c 10 Apr 2015 21:23:09 -0000
@@ -1040,7 +1040,7 @@
}

flags = RTF_UP | RTF_HOST | RTF_LOCAL;
- if (!(ifa->ifa_ifp->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT)))
+ if (!(ifa->ifa_ifp->if_flags & IFF_LOOPBACK))
flags |= RTF_LLINFO;
e = rtrequest(cmd, ifa->ifa_addr, ifa->ifa_addr, all1_sa, flags, &nrt);


However, I cannot seem to fix the IPv4 case described in the PR.
More investigation needed there.

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Barrett]

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)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de