Re: IPv6: NetBSD does not respond to NS for non-link local addresses
Michał Purzyński <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <CAJ6bFK1Bm_BzrRrd5SCwSk-RN5eoUVfePS=BUfXVTvad3kDvZw@mail.gmail.com> |
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.
>