From owner-freebsd-net@freebsd.org Thu Jul 2 22:42:08 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 4DA59361C79 for ; Thu, 2 Jul 2020 22:42:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49yY4c1RY9z4NYP for ; Thu, 2 Jul 2020 22:42:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3172B361E01; Thu, 2 Jul 2020 22:42:08 +0000 (UTC) Delivered-To: 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 313A43618D1 for ; Thu, 2 Jul 2020 22:42:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yY4c0ZXXz4NSq for ; Thu, 2 Jul 2020 22:42:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id EACE821EBA for ; Thu, 2 Jul 2020 22:42:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 062Mg7Dl030001 for ; Thu, 2 Jul 2020 22:42:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 062Mg7Rr030000 for net@FreeBSD.org; Thu, 2 Jul 2020 22:42:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 247700] rtadvd: fails to generate error when iface lacks a link-local address Date: Thu, 02 Jul 2020 22:42:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: john@saltant.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hrs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 22:42:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247700 --- Comment #4 from John W. O'Brien --- (In reply to Hiroki Sato from comment #3) > It is a valid situation for a unicast communication where a global-scope > address is the source address and a link-local-scope address is the > destination address though it is not recognized as valid as a Router > Advertisement message. Limiting the address selection to the same zone as > the destination's is too restrictive. The current implementation prefers= a > source scope whose scope is larger than the destination's (c.f. Rule 2, S= ec. > 5, RFC 6724). Even if the source is smaller than the destination, an > address is selected in any way. However, upon sending a packet, the > network stack will discard the packet due to an error "no destination". My understanding of the source selection rules is definitely incomplete, and may also be flawed, so I will gladly defer to you on this matter. > So in the situation with src=3DGUA/dst=3DLLA, a unicast communication wor= ks > and it does not against the specifications. An aspect of this about which I still harbor uncertainty is the question of whether every usable A->B address pair is also a usable B->A pair, assuming unicast semantics. In the rtadvd(8)/RA case, we enjoy the benefit of multic= ast semantics, where B->A is invalid regardless of the scopes. It was for that reason, in addition to the above, that I elected to report this against rtadvd(8) instead of against in6_src.c. > Usually it does not happen because every interface has at least one LLA > configured (c.f. Sec. 2.1, RFC 4291) and the source address selection > algorithm always prefers a smaller scope. >=20 > For an interface with no LLA, I think NDP does not work in various ways > because it (and MLDv2) heavily depends on LLA. It is not limited to > Router Advertisement messages. For this reason, FreeBSD configures an > EUI-64 LLA by default. Accepting this as fact implies that there is another bug somewhere. The rea= son I discovered the rtadvd(8) problem in the first place was through a sequenc= e of steps to create an if_bridge(4) and configure it as a subnet gateway (for multiple VNET jails via epair(4)s) that resulted, unnoticed, in the GUA && = !LLA scenario without explicitly disabling AUTO_LINKLOCAL. I have not attempted = to reproduce those steps. > There are some scenarios where only GUAs are configured on an interface, > however. To prevent rtadvd(8) from sending invalid packets you reported, > I think rtadvd(8) should check if the interface has an LLA or not. I > believe running rtadvd(8) on an interface with no LLA is a wrong > configuration. I concur with the last statement. If I achieve nothing else with this bug, I want to reduce substantially the time required to troubleshoot the specific scenario I encountered: rtadvd(8) + no LLA =3D fail immediately and emit an actionable error. > Please let me know if I understand your report correctly, and comments ab= out > my understanding about the issue you pointed out. If the additional check > on rtadvd(8) is sufficient, I will work on it. Yes, that would be sufficient. Thank you very much for your prompt and thor= ough response. --=20 You are receiving this mail because: You are on the CC list for the bug.=