IPv6 ICMPv6 neighbor solicitation - ignored between different prefixes

[Lars Schotte <gustik%gustik.eu@localhost>]

Hi NetBSD tech-net,

I did set up a testing scenario with VirtualBox and first i did think
that there is something wrong with the virtualized network, but then i
realized that the problem is much bigger that it may seem.

Scenario looks like following:

Host     Linux----NetBSD1 --- NetBSD2 ---NetBSD3
Prefix::50:1    LinkLocal       LinkLocal       Prefix::50:33/128

Routing looks well, and it actually works when i for example ping6 the
NetBSD3 box from the host, because then the LinkLocal IPv6 addresses
are being used, but it does not work other way round until someone
ping6's the host or from the host using LinkLocal IPv6 addresses to get
the neighbour solicitation right.

Now here is what happens:
17:29:41.180138 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 
<<Prefix>>::50:33 > ff02::1:ff54:103: [icmp6 sum ok] ICMP6, neighbor 
solicitation, length 32, who has fc00::54:103
          source link-address option (1), length 8 (1): 08:00:27:40:75:2c
            0x0000:  0800 2740 752c
17:29:42.176780 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 
<<Prefix>>::50:33 > ff02::1:ff54:103: [icmp6 sum ok] ICMP6, neighbor 
solicitation, length 32, who has fc00::54:103
          source link-address option (1), length 8 (1): 08:00:27:40:75:2c
            0x0000:  0800 2740 752c
17:29:43.173184 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 
<<Prefix>>::50:33 > ff02::1:ff54:103: [icmp6 sum ok] ICMP6, neighbor 
solicitation, length 32, who has fc00::54:103
          source link-address option (1), length 8 (1): 08:00:27:40:75:2c
            0x0000:  0800 2740 752c

You do not see LinkLocal addresses here, because i tried it also with
another aliases so that he might use them instead, but that did not help.
However, with link local addresses it's the same problem.

Then i enabled the nd6_debug option in sysctl and i got the breakthrough:
nd6_ns_input: NS packet from non-neighbor
nd6_ns_input: src=<<Prefix>>::50:33
nd6_ns_input: dst=ff02:2::1:ff54:103
nd6_ns_input: tgt=fc00::54:103

Until then i thaught it would be some networking/routing issue, but here i see
on the DESTINATION host that he not only gets the packages (like we see from
its own TCPDUMP) but he _deliberately_ ignores them.

However, after ping6ing the ff02:2::1:ff54:103 address directly, or the 
linklocal address
it works. so somehow he has no neighborhood problems then. He has only a 
problem with
his neighbor when he is using an address that is not in the addresses portfolio.

There would be two solutions to this:
either 1.) the source host does try other ipv6 addresses he has after not 
succeeding
with neighbor solicitation, for example the link local one, or other aliases to 
get the
neighbor solicitation of his default gateway, instead of sending solicitations 
indefinitely
as long as there would be packets going out (for example a ping6 on a outside 
host)
or      2.) the destination host answers the neighbor solicitation and there 
could be some
sysctl tunable that would make him more permissive in respect to this 
solicitations.

I do not see a reason why he does not do it anyway, because a MAC address is 
not something
"secret" and Layer2 security should be left to Ethernet and should not be of 
IPv6' business.
In case he would not be his neighbor, the packet would not come through anyway.

Thanks and i appreciate some comments on this.

PS: I know that this problem could also be solved by tearing up the network in 
more,
say, /64 prefixes, but that's not kind of my question, because then you get a 
lot of subnet
hopping and the computers/routers in between would be accessible/have a global 
IPv6
address and that was exactly what i was trying to prevent here.