https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247700
--- Comment #4 from John W. O'Brien <j...@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, Sec. > 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=GUA/dst=LLA, a unicast communication works > 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 multicast 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. > > 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 reason I discovered the rtadvd(8) problem in the first place was through a sequence 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 = fail immediately and emit an actionable error. > Please let me know if I understand your report correctly, and comments about > 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 thorough response. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
