Lars Schotte
2012-10-21 17:15:35 UTC
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.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
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.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de