Re: IPv6: NetBSD does not respond to NS for non-link local addresses

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.

That being said I think I also misunderstood this paragraphs from
https://datatracker.ietf.org/doc/html/rfc6204#section-4.3

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

Em sex., 4 de abr. de 2025 às 12:00, Martin Husemann <[email protected]>
escreveu:

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