I'm having trouble to get my router to discover my macOS laptop's IPv6 address. The problem seems to be in the neighbour discovery. Tapping the traffic with tcpdump, that the routers sends neighbor solicitation messages like these:
Here fd26:e9f1:e833::1 is an ULA associated with the br-lan interface, ff02::1:ff65:88f8 is the multicast address and 2404:7a80:9621:7100:404:978a:5765:88f8 is the global IPv6 address of the macOS laptop. The prefix is correct, and the address should be okay.
However, macOS doesn't answer to these messages at all, so the router doesn't find it. Doing ip -6 neigh on the router shows that it knows about the GUA 2404:7a80:9621:7100:404:978a:5765:88f8, but it doesn't know the associated MAC address, and shows only a failed probe count.
I happend to find this bug / problem report about macOS ignoring neighbor solicitations with GUA as a source address: https://discussions.apple.com/thread/8620806 This made me think that the same might apply to messages with ULA as a source address.
So, I'd like to try out: maybe my IPv6 connectivity problem will get fixed if my router sent messages with link-local address instead of ULA or GUA. Is there any way to make it do so?
If the source address of the packet prompting the
solicitation is the same as one of the addresses
assigned to the outgoing interface, that address
SHOULD be placed in the IP Source Address of the
outgoing solicitation. Otherwise, any one of the
addresses assigned to the interface should be used.
Using the prompting packet's source address when
possible ensures that the recipient of the Neighbor
Solicitation installs in its Neighbor Cache the IP
address that is highly likely to be used in subsequent
return traffic belonging to the prompting packet's
"connection".
I cannot make heads or tails out of this. Surely the source address is decided by the sender of the package, which I think is odhcpd here. But I can't think of a situation where the source address wouldn't be one of the addresses of the sending interface, so I fail to see what's the point of above paragraph.
Anyway, it seems that any address of the interface can be used, which means that link local address could be used also.
If there is no knob in odhcpd that makes it so, do anybody have ideas how to hand-craft a neighbor solicitation packets to test whether using LLA fixes macOS neighbor discovery?
I found out that there is a tool called nping that might help testing this, by hand-crafting ICMPv6 packages. Fortunately it's in OpenWRT's package repository: https://openwrt.org/packages/pkgdata/nping I'll try it later today.
Indeed, as I suspected, macOS doesn't respond to NDP unless the NDP messages (Neighbor solicitation, ICMPv6 type 135) are send with a link-local source address. At the moment, at least in the relay mode, odhcpd sends the packets with unique local source address, if the ULA prefix is set.
If the prefix isn't set, it will use LLA, and the setup will work with macOS.
macOS is a very common OS these days, so even though it isn't by the rules of the RFC (if I understand it correctly, any address corresponding to the sender should do), it would be very helpful if odhcpd used LLA by default, just to make macOS work. (Of course, I don't know if there's some other systems that work better with other setups.)
I'm tremendously thankful for the people on #openwrt@chat.freenode.net IRC channel for helping me out. Especially PaulFertser, thank you!
For this endeavour not to end here, I'd love to get the default behaviour of odhcpd fixed. Hopefully the maintainer of odhcpd responds in IRC. If they don't, I'm going to issue a bug report.