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
___
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"
