Attachment 216144 Details for Bug 247718 – suggested patch for sys/netinet6/ip6_forward.c

[patch] suggested patch for sys/netinet6/ip6_forward.c

0001-Allow-IPv6-packets-to-loop-back-to-the-same-p2p-if.patch (text/plain), 3.17 KB, created by Mira Ressel on 2020-07-02 15:15:40 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Mira Ressel

Created: 2020-07-02 15:15:40 UTC

Size: 3.17 KB

patch

obsolete

>From d8b3a45d60520e6be48795966caf00f1217a871d Mon Sep 17 00:00:00 2001
>From: Mira Ressel <aranea@aixah.de>
>Date: Thu, 2 Jul 2020 17:08:56 +0200
>Subject: [PATCH] Allow IPv6 packets to loop back to the same p2p if
>
>Currently, FreeBSD's IPv6 stack explicitly drops packets which were received on
>an IFF_POINTOPOINT interface and are then looped back to the same interface.
>
>This piece of code originated in the KAME project, and was controversial even
>when it was enabled there by default back in 2001 [1]. 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 multiple
>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 [2]. In this case, the
>aforementioned logic causes packet drops in a perfectly valid network topology,
>as reported in [3].
>
>Therefore, it isn't correct to drop these packets. Even in the case of true
>point-to-point links, the only purpose of this logic is to avoid transient
>looping of packets sent my misconfigured applications or attackers. This is a
>well-known problem [4] that can be easily avoided by proper route
>configuration, rather than by hardcoded kernel logic to drop packets.
>
>[1] lengthy ML thread archived at
>    https://www.ietf.org/mail-archive/text/ipngwg/2001-04.mail and -05,
>    subject "nonexisting destination on p2p link"
>[2] https://www.wireguard.com/
>[3] https://forums.freebsd.org/threads/wireguard-peers-cant-reach-each-other-on-ipv6.75991/
>[4] https://tools.ietf.org/html/rfc6164#section-5.1
>
>Signed-off-by: Mira Ressel <aranea@aixah.de>
>---
> sys/netinet6/ip6_forward.c | 18 +-----------------
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
>diff --git a/sys/netinet6/ip6_forward.c b/sys/netinet6/ip6_forward.c
>index b94dca89eef..d4306eea416 100644
>--- a/sys/netinet6/ip6_forward.c
>+++ b/sys/netinet6/ip6_forward.c
>@@ -260,24 +260,8 @@ ip6_forward(struct mbuf *m, int srcrt)
> 	 * modified by a redirect.
> 	 */
> 	if (V_ip6_sendredirects && nh->nh_ifp == m->m_pkthdr.rcvif && !srcrt &&
>-	    (nh->nh_flags & NHF_REDIRECT) == 0) {
>-		if ((nh->nh_ifp->if_flags & IFF_POINTOPOINT) != 0) {
>-			/*
>-			 * If the incoming interface is equal to the outgoing
>-			 * one, and the link attached to the interface is
>-			 * point-to-point, then it will be highly probable
>-			 * that a routing loop occurs. Thus, we immediately
>-			 * drop the packet and send an ICMPv6 error message.
>-			 *
>-			 * type/code is based on suggestion by Rich Draves.
>-			 * not sure if it is the best pick.
>-			 */
>-			icmp6_error(mcopy, ICMP6_DST_UNREACH,
>-				    ICMP6_DST_UNREACH_ADDR, 0);
>-			goto bad;
>-		}
>+	    (nh->nh_flags & NHF_REDIRECT) == 0)
> 		type = ND_REDIRECT;
>-	}
> 
> 	/*
> 	 * Fake scoped addresses. Note that even link-local source or
>-- 
>2.25.4
>

Actions: View | Diff

Attachments on bug 247718: 216144