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

Hm. Really no one knows why?

Em qua., 2 de abr. de 2025 às 01:26, Michał Purzyński <
[email protected]> escreveu:

> You know what is the worst case scenario? When you find a solution you
> don't understand that makes everything work 5min after telling entire world
> you have no idea.
>
> I have disabled
>
> #  route 2a02:168:4959:1::/64
> #  {
> #  };
>
> After the reboot my netbsd shows:
>
> 2a02:168:4959:1::/64                    link#1                         UC
>          -        -      -  usmsc0 <-- it now considers my prefix on-link
> so NS should work, right?
> 2a02:168:4959:1::55                     link#1                         UHl
>         -        -      -  lo0
> 2a02:168:4959:1:ba27:ebff:fea2:ad4e     link#1                         UHl
>         -        -      -  lo0
>
> w
>
> USER     TTY     FROM                                 LOGIN@  IDLE WHAT
> michal   pts/0   2a02:168:4959:1:40c4:edfb:4cbb:444b  5:49AM     0 w
>
> :)
>
> I'm still wondering why NetBSD is the only having problems here. I also
> have this FreeBSD host and not matter if I announce that route or not the
> result is the same:
>
> 2a02:168:4959:1::/64              link#2                        U
>       ue0 <-- FreeBSD considers it on link
> 2a02:168:4959:1:ba27:ebff:fe6c:eb4 link#1                       UHS
>       lo0
>
> OS X unsurprisingly is 100% the same.
>
> Em qua., 2 de abr. de 2025 às 00:57, Michał Purzyński <
> [email protected]> escreveu:
>
>> Hey!
>>
>> For the past two days I've been debugging an interesting issue: neighbour
>> solicitations are ignored for addresses that are not link-local. I'd like
>> to have one of two things working: SLAAC or the static IP6. Ideally
>> the first one. None of them I can get working.
>> There must be something wrong either with my network that NetBSD (known
>> for it's adherence to standards) uncovered or maybe I found a bug?
>> Either way I'm happy to debug and contribute code. I've used the full
>> addresses here. I kinda trust the filtering on the edge ;)
>> The network is just a single switch where all hosts are connected with a
>> Linux firewall/router and the ISP on the other side. They delegated a /48
>> prefix of which I used a single /64 and announced it with radvd (attached
>> below). NetBSD is the only host that's not happy: with the settings below I
>> finally got it working to talk to the router but none of the host on my
>> network can even ping the NetBSD "public" addresses. I can see the NS sent
>> to my netbsd from any other host I try to ping to the public IP6. Just to
>> make sure I disabled the npf. That would not be it, though, because the
>> kernel deliberately ignores the NS. See below:
>>
>> The nd_debug shows:
>>
>> nd6_options: nd6_options: unsupported option 38 - option ignored
>> nd6_options: nd6_options: unsupported option 24 - option ignored
>> nd6_options: nd6_options: unsupported option 25 - option ignored
>> nd6_options: nd6_options: unsupported option 38 - option ignored
>> nd6_options: nd6_options: unsupported option 24 - option ignored
>> nd6_options: nd6_options: unsupported opti25 - option ignored
>> nd6_options: nd6_options: unsupported option 38 - option ignored
>> nd6_options: nd6_options: unsupported option 24 - option ignored
>> nd6_options: nd6_options: unsupported option 25 - option ignored
>> nd6_options: nd6_options: unsupported option 38 - option ignored
>> nd6_options: nd6_options: unsupported option 24 - option ignored
>> nd6_options: nd6_options: unsupported option 25 - option ignored
>> nd6_options: nd6_options: unsupported option 38 - option ignored
>> nd6_options: nd6_options: unsupported option 24 - option ignored
>> nd6_options: nd6_options: unsupported option 25 - option ignored
>> nd6_ns_input: NS packet from non-neighbor
>> 2a02:168:4959:1:ba27:ebff:fe6c:eb4 on usmsc0
>> nd6_ns_input: src=2a02:168:4959:1:ba27:ebff:fe6c:eb4
>> nd6_ns_input: dst=ff02:1::1:ff00:55
>> nd6_ns_input: tgt=2a02:168:4959:1::55
>>
>> I went through the code and it looks like my little box thinks that
>> address is not a neighbor indeed. But why?
>>
>> rc.conf
>>
>> auto_ifconfig=yes
>> ip6mode="autohost"
>> (setting this to host changes nothing)
>>
>> /etc/ifconfig.usmsc0
>>
>> inet6 2a02:168:4959:1::55 prefixlen 64 alias
>> (I've set this static IP in a desperate attempt to get things working)
>>
>> ifconfig
>>
>> usmsc0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>> ec_capabilities=0x1<VLAN_MTU>
>> ec_enabled=0
>> address: b8:27:eb:a2:ad:4e
>> media: Ethernet autoselect (100baseTX full-duplex)
>> status: active
>> inet6 2a02:168:4959:1::55/64 flags 0
>> inet6 fe80::ba27:ebff:fea2:ad4e%usmsc0/64 flags 0 scopeid 0x1
>> inet6 2a02:168:4959:1:ba27:ebff:fea2:ad4e/64 flags 0x40<AUTOCONF>
>>
>> The routing table is actually very interesting:
>>
>> netstat -rn -f inet6
>>
>> Routing tables
>>
>> Internet6:
>> Destination                             Gateway
>>  Flags    Refs      Use    Mtu Interface
>> ::/104                                  ::1
>>  UGRS        -        -  33176  lo0
>> ::/96                                   ::1
>>  UGRS        -        -  33176  lo0
>> default                                 fe80::da5e:d3ff:fe0d:8b1c      UG
>>          -        -      -  usmsc0
>> ::1                                     lo0
>>  UHl         -        -  33176  lo0
>> ::127.0.0.0/104                         ::1
>>  UGRS        -        -  33176  lo0
>> ::224.0.0.0/100                         ::1
>>  UGRS        -        -  33176  lo0
>> ::255.0.0.0/104                         ::1
>>  UGRS        -        -  33176  lo0
>> ::ffff:0.0.0.0/96                       ::1
>>  UGRS        -        -  33176  lo0
>> 2001:db8::/32                           ::1
>>  UGRS        -        -  33176  lo0
>> 2002::/24                               ::1
>>  UGRS        -        -  33176  lo0
>> 2002:7f00::/24                          ::1
>>  UGRS        -        -  33176  lo0
>> 2002:e000::/20                          ::1
>>  UGRS        -        -  33176  lo0
>> 2002:ff00::/24                          ::1
>>  UGRS        -        -  33176  lo0
>> 2a02:168:4959:1::/64                    fe80::da5e:d3ff:fe0d:8b1c      UG
>>          -        -      -  usmsc0 <- The prefix is identified on the
>> correct interface.
>> 2a02:168:4959:1::55                     link#1
>> UHl         -        -      -  lo0 <-- wait why the device is lo0 here?
>> 2a02:168:4959:1:ba27:ebff:fea2:ad4e     link#1
>> UHl         -        -      -  lo0 <- same here this time from SLAAC?
>> fe80::/10                               ::1
>>  UGRS        -        -  33176  lo0
>> fe80::%usmsc0/64                        link#1                         UC
>>          -        -      -  usmsc0
>> fe80::ba27:ebff:fea2:ad4e               link#1
>> UHl         -        -      -  lo0
>> fe80::%lo0/64                           fe80::1                        U
>>           -        -      -  lo0
>> fe80::1                                 lo0
>>  UHl         -        -      -  lo0
>> ff01:1::/32                             link#1                         UC
>>          -        -      -  usmsc0
>> ff01:2::/32                             ::1                            UC
>>          -        -  33176  lo0
>> ff02::%usmsc0/32                        link#1                         UC
>>          -        -      -  usmsc0
>> ff02::%lo0/32                           ::1                            UC
>>          -        -  33176  lo0
>> fe80::c75:f688:7c63:a21f                9a:91:1d:bd:eb:f3
>>  UHL         -        -      -  usmsc0
>> fe80::da5e:d3ff:fe0d:8b1c               d8:5e:d3:0d:8b:1c
>>  UHL         -        -      -  usmsc0 <- the link-local addresses are
>> happy and I just ssh-ed into one from another host on this network without
>> any problems.
>>
>> The neighbour cache is pretty sad:
>>
>> ndp -a
>>
>> Neighbor                                Linklayer Address  Netif Expire
>>  S Fl
>> fe80::c75:f688:7c63:a21f%usmsc0         9a:91:1d:bd:eb:f3 usmsc0 19s
>>   R
>> fe80::da5e:d3ff:fe0d:8b1c%usmsc0        d8:5e:d3:0d:8b:1c usmsc0
>> 23h41m48s S R
>>
>>
>> Now on to the Linux side. Here's what I announce:
>>
>> cat /etc/radvd.conf
>>
>> interface enp7s0
>> {
>>   IgnoreIfMissing on;
>>   AdvSendAdvert on;
>>   MaxRtrAdvInterval 60;
>>   AdvRASolicitedUnicast on;
>>   AdvDefaultLifetime 3600;
>>
>>   prefix 2a02:168:4959:1::/64
>>   {
>>     AdvOnLink on; <-- that should do the job, no?
>>     AdvAutonomous on;
>>   };
>>
>>   route 2a02:168:4959:1::/64 <-- set per
>> https://datatracker.ietf.org/doc/html/rfc6204#section-4 which says to
>> announce a prefix and a route
>>   {
>>   };
>>
>>   nat64prefix 64:ff9b::/96 {
>>     AdvValidLifetime 65528;
>>   };
>>
>>   RDNSS 2a02:168:4959:1::1 {
>>     AdvRDNSSLifetime 1209600;
>>     FlushRDNSS on;
>>   };
>> };
>>
>> Frankly I'm out of ideas at this point.
>>
>