Re: IPv6: what is required of lower layers?

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

On 5/04/23 06:37, Mouse wrote:
> I have a thing I've been using for years now, passing IPv4 packets
> around, using tun interfaces to get packets into and out of the kernel
> networking stack.
>
> But now I want to add support for IPv6.
>
> At first I just added the code to userland and it simply didn't work; I
> never got any packets out of the tun device.  Adding debugging printfs
> to ip6_output(), I discovered that the problem was that the tun device
> was configured as IFF_BROADCAST but not IFF_MULTICAST.  So I added
> that, and now I'm getting packets, but they're addressed to a multicast
> address, ff02:3::1:ff02:2, not the address userland is sending to.


That might just be your system trying to find its default route.

I did a quick check locally running tcpdump on one of my systems while 
making a connection to a non-existent IP address (to mkae sure ND gets 
exercise). I ran "ssh 2406:1e00:b410:3501:21e:67ff:fea4:f090" where that 
IP address is an unused address on my local LAN. Tcpdump said to me


	08:55:24.469105 IP6 2406:1e00:b410:3501:21e:67ff:fea4:f008 >
	ff02::1:ffa4:f090: ICMP6, neighbor solicitation, who has
	2406:1e00:b410:3501:21e:67ff:fea4:f090, length 32

We can see that the multicast destination address is related to the 
neighbour destination address. I suspect that NetBSD is using the bottom 
end of the address to keep track of multiple ND requests.

If that's the case, then requests to ff02:3::1:ff02:2 could well be the 
kernel trying to find all local routers.

What does tcpdump say is inside the ND request?

Cheers,
Lloyd