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