From owner-freebsd-net@freebsd.org Wed Mar 4 20:10:21 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 909D22777FC for ; Wed, 4 Mar 2020 20:10:21 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from mail.neveragain.de (chao.neveragain.de [94.16.113.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48XlNq3gY0z43BB for ; Wed, 4 Mar 2020 20:10:19 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from [IPv6:2a02:908:113b:fb5c:4981:c81d:4c5:2c01] (unknown [IPv6:2a02:908:113b:fb5c:4981:c81d:4c5:2c01]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neveragain.de (Postfix) with ESMTPSA id AE921200773 for ; Wed, 4 Mar 2020 21:10:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=neveragain.de; s=2015-10; t=1583352610; bh=R2F+a65/YdCzPnDVFX6Nm8CpC5cSHSOqhBBBct4rJKE=; h=From:Subject:Date:To; b=LuA0F3eJRBiL5c1iq+FnfIKQ2o0KohFPavsSGiNNRQD60rf9ytlP1eXVzAmWPI81K JBSyDrn9QRWTzSJtj6TjY/UG0gkru6eM7j+eFA5yoTTch3O9FnxqJDsXO6uAeGbagK gMok7z/aFpwsMLHNtvG0UwGBpO1oi3ogpAhHEIRx7pkkYhRpAUhMti/o+m0w70X7c6 2Q1DOCBzPEIH0huES+tPJRXvTENPbi8Shu+9kfZw+P7AC2IA90yo3bhi/jjUrp5jgv +jF/i1w5BFv8CPLaHasj4pWFBZPJcXmcYRcDYyEdjfFh5nYjdd2r/Bzn1sWeM2yWbs aAqdLteZ+Rl7w== From: =?utf-8?Q?Dennis_K=C3=B6gel?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Revisiting FreeBSD-SA-08:10.nd6 (or: avoiding IPv6 pain) Message-Id: <523BA6CF-C2C3-4E55-B81C-CB8816E56DDE@neveragain.de> Date: Wed, 4 Mar 2020 21:10:09 +0100 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48XlNq3gY0z43BB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=neveragain.de header.s=2015-10 header.b=LuA0F3eJ; dmarc=pass (policy=none) header.from=neveragain.de; spf=pass (mx1.freebsd.org: domain of dk@neveragain.de designates 94.16.113.56 as permitted sender) smtp.mailfrom=dk@neveragain.de X-Spamd-Result: default: False [-1.04 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[neveragain.de:s=2015-10]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.neveragain.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.57)[0.571,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[neveragain.de:+]; DMARC_POLICY_ALLOW(-0.50)[neveragain.de,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.12)[asn: 197540(-0.56), country: DE(-0.02)]; ASN(0.00)[asn:197540, ipnet:94.16.112.0/21, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 20:10:21 -0000 Hi, I=E2=80=98ve spent quite some time debugging weird intermittent IPv6 = connectivity issues over the last few days. It turned out that net.inet6.icmp6.nd6_onlink_ns_rfc4861=3D1 fixed those = problems. This flag was introduced in a 2008 Security Advisory, because = "non-neighbors" could abuse Neighbor Discovery to potentially cause = denial-of-service situations. In my situation it caused valid Neighbor Solicitation packets from my = provider to be silently dropped, making the connection effectively = unusable. In the comments in nd6_nbr.c[0] it says that IETF discussion on this = issue is still ongoing.=20 In the meantime, 12 years have passed. There are several reports on = similar connection issues over the years, each time due to this default = setting. An OpenBSD discussion from 2013 [1] explains the effects in depth, but = ultimately ends up nowhere. The key takeaway from this thread is RFC = 4861 sect. 7.2.2, which states that any address "should" be used as = source. Dragonfly decided to disable this protection by default in 2018 [2]. I=E2=80=98d propose to do the same in FreeBSD, given that the issue 1) = is rather hard to debug 2) breaks interop with RFC-compliant setups = again and again and 3) I cannot see any harm here (Solicitation can only = originate from the rather trusted local network, i.e. from a neighbor). What do you think? Am I missing something? Thanks, - D.=20 [0]: = https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_nbr.c#L188= [1]: = http://openbsd-archive.7691.n7.nabble.com/OpenBSD-ignoring-RFC-compliant-I= Pv6-neighbor-solicitation-td223348.html [2]: https://www.mail-archive.com/commits@dragonflybsd.org/msg14496.html