I have now run into this problem also. (which sadly affects
anoncvs.eu.openbsd.org).
The router has another ip on a loopback interface somewhere which it thinks
is it's own "main" v6 ip, and then it sends it as the source ip of the
solictation.
This in turn means that my obsd wont respond to the NDP which makes the
router ignore my box and v6 anoncvs users don't get v6 access. 8-/
14:21:43.113824 2001:6b0:5:1::151 > ff02::1:ffa9:f5ba: icmp6: neighbor sol:
who
has 2001:6b0:5:1825:1c2f:5c1b:dfa9:f5ba
So the network segment is really 2001:6b0:5:1825/64 but the NDP'ing router
sends from 2001:6b0:5:1::151 instead which isn't inside the prefix of
course.
Grrr.
2013/2/12 Stuart Henderson <s...@spacehopper.org>
> On 2013-02-11, Martin Schmitt <m...@scsy.de> wrote:
> > Am 11.02.2013 12:12, schrieb Stefan Sperling:
> >
> >> I believe the code path you're hitting is this one in
> netinet6/nd6_nbr.c,
> >> in nd6_ns_input():
> >>
> >> } else {
> >> /*
> >> * Make sure the source address is from a neighbor's
> address.
> >> */
> >> if (!in6_ifpprefix(ifp, &saddr6)) {
> >> nd6log((LOG_INFO, "nd6_ns_input: "
> >> "NS packet from non-neighbor\n"));
> >> goto bad;
> >> }
> >> }
> >
> > Thanks for your quick response!
> >
> > The ISP has now worked around the issue by adding a fixed NDP entry for
> > my router's address so I can't really test with it, but I have added
> > another address on the interface, which gives me this, after sysctl
> > net.inet6.icmp6.nd6_debug=1:
> >
> > nd6_ns_input: src=2001:0db8:1234:5678::0009
> > nd6_ns_input: dst=ff02:0001::0001:ff00:0015
> > nd6_ns_input: tgt=2001:0db8:1234:5678::0015
> > nd6_ns_input: NS packet from non-neighbor
> >
> >> Have you tried using a /64 netmask at your end of the transfer link,
> >> instead of the /125?
> >
> > I had already tried /123, which made it work. Such a workaround comes
> > across a bit desperate, because with further expansion of the ISP's IPv6
> > customer base, further widening of the prefix will be required. I'm not
> > sure whether this is how the uplink is intended to work and if it has
> > the potential to do any damage.
> >
> > How is your understanding of NDP? Do you think OpenBSD is at fault for
> > ignoring these solicitations, or do you think the ISP router's OS
> > selects the wrong source IP? The wording in the RFC is really very terse
> > and leaves room for interpretation.
>
> RFC 4861 says
>
> 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.
>
> so it would seem permissible for another address to appear here.
> RFC 5942 updates RFC 4861 and to my reading it doesn't change this.
>
> NetBSD will have the same problem btw, the check in nd6_nbr.c came
> from there. The check goes beyond the validation specified by RFC
> 4861 7.1.1 (by itself this is not necessarily a problem, in some
> cases it is eminently sensible to be stricter than RFC, but it
> looks like we may possibly need to relax this here..).
>
>
--
May the most significant bit of your life be positive.
