Revisiting FreeBSD-SA-08:10.nd6 (or: avoiding IPv6 pain)
Dennis Kögel
dk at neveragain.de
Wed Mar 4 20:10:21 UTC 2020
Hi,
I‘ve 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=1 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.
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‘d 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.
[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-IPv6-neighbor-solicitation-td223348.html
[2]: https://www.mail-archive.com/commits@dragonflybsd.org/msg14496.html
More information about the freebsd-net
mailing list