Date: Thu, 02 Jul 2020 22:42:07 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 247700] rtadvd: fails to generate error when iface lacks a link-local address Message-ID: <bug-247700-7501-UYqa8mbKsK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-247700-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-247700-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247700 --- Comment #4 from John W. O'Brien <john@saltant.com> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247700-7501-UYqa8mbKsK>