this patch (stupidly) fixes my problem. I don't like my broken setup,
but this works.


Index: nd6_nbr.c
===================================================================
RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.66
diff -u -p -r1.66 nd6_nbr.c
--- nd6_nbr.c   7 Mar 2013 09:03:16 -0000       1.66
+++ nd6_nbr.c   7 May 2013 11:44:56 -0000
@@ -132,17 +132,7 @@ nd6_ns_input(struct mbuf *m, int off, in
                            "(wrong ip6 dst)\n"));
                        goto bad;
                }
-       } 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;
-               }
        }
-

        if (IN6_IS_ADDR_MULTICAST(&taddr6)) {
                nd6log((LOG_INFO, "nd6_ns_input: bad NS target (multicast)\n"));




2013/5/6 Janne Johansson <icepic...@gmail.com>

> 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.
>



-- 
May the most significant bit of your life be positive.

Reply via email to