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 | <CAJ6bFK1ag=h9BYAreRAPr9JS+JquYPdXxnRYJEKStpm6t09SZA@mail.gmail.com> |
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.