Sure and sorry for any confusion I might have caused.
My ISP delegated route 2a02:168:4959::/48 of which I used the 2a02:168:4959:1::/64.
Advertising this prefix and also as a route
route 2a02:168:4959:1::/64
{
};
causes different behaviour on NetBSD vs other systems and I'm curious why that is.
On NetBSD this causes this prefix to be installed in fib with the router's LL as the next hop. This makes NetBSD think this prefix is not on-link and the ND fails for addresses from this prefix. Other systems also install this prefix in their fib but they respond to NS. NetBSD is the only one that is like "not my neighbour not on-link". I verified that with the db debug option on both FreeBSD and NetBSD.
FreeBSD responds to the NS. Linux (vanilla, Android, ChromeOS), OS X all respond to the NS.
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
So I guess I should:
1. Advertise the 2a02:168:4959:1::/64 prefix as on-link
2. Advertise the 2a02:168:4959::/48 route (and not the above /64).
--
Michal
On Thu, Apr 03, 2025 at 08:48:26PM +0200, Micha? Purzy?ski wrote:
> Hm. Really no one knows why?
Can you describe the problem differently? As I read it you showed
correct behaviour with log messages confirming it is correct behaviour
and if there was a hidden reason in there why it should not be correct
I missed it.
Martin