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.
-martin
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
