Date: Thu, 02 Jul 2020 15:06:00 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 247718] FreeBSD incorrectly drops IPv6 packets looping back to the same p2p interface Message-ID: <bug-247718-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247718 Bug ID: 247718 Summary: FreeBSD incorrectly drops IPv6 packets looping back to the same p2p interface Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: aranea@aixah.de FreeBSD's IPv6 stack explicitly drops packets which were received on an IFF_POINTOPOINT interface and are then looped back to the same interface [1= ]. This piece of code originated in the KAME project, and was controversial ev= en when it was enabled there by default back in 2001 [2]. Notably, there is no equivalent logic in FreeBSD's IPv4 stack -- it also generates ICMP Redirect messages under these circumstances, but doesn't drop any packets. While this logic may arguably make sense for true point-to-point links, not= all interfaces with the IFF_POINTOPOINT flag are such links. In particular, tun interfaces are always marked with this flag, even though the userland application behind a tun interface might well be forwarding packets to mult= iple peers. One example for an application that uses tun interfaces to present a point-to-multipoint/NBMA link rather than a point-to-point link is wireguard-go, the userland implementation of the wireguard protocol [3]. In this case, the aforementioned logic causes packet drops in a perfectly valid network topol= ogy, as reported in [4]. Therefore, I would suggest removing the entire "if ((nh->nh_ifp->if_flags & IFF_POINTOPOINT) !=3D 0) { ... }" block that drops these packets. Even in t= he case of true point-to-point links, its only function is to avoid transient loopi= ng of packets sent my misconfigured applications or attackers. This is a well-kno= wn problem [5] that can be easily avoided by proper route configuration, rather than by hardcoded kernel logic to drop packets. [1] https://svnweb.freebsd.org/base/head/sys/netinet6/ip6_forward.c?view=3Dmark= up&pathrev=3D362338#l265 [2] lengthy ML thread archived at https://www.ietf.org/mail-archive/text/ipngwg/2001-04.mail and -05, subject "nonexisting destination on p2p link" [3] https://www.wireguard.com/ [4] https://forums.freebsd.org/threads/wireguard-peers-cant-reach-each-other-on= -ipv6.75991/ [5] https://tools.ietf.org/html/rfc6164#section-5.1 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247718-227>