On Mon, Feb 11, 2013 at 11:09:00AM +0100, Martin Schmitt wrote:
> All,
>
> I got my first non-tunneled IPv6 uplink a while ago, and now I have
> issues with NDP.
>
> Over the same shared LAN, the ISP apparently serves several (more than
> one, but as far as I can see not neccessarily more than two) customer
> routers, with a logical /125 transfer network for each customer. What I
> currently see, is this:
>
> 1) 2001:db8:1234:5678::08/125 <- Someone else's transfer network
> 2) 2001:db8:1234:5678::10/125 <- "My" transfer network
>
> What happens now is that the ISP router sometimes sends neigbor
> solicitation requests for my OpenBSD router using a source IP from its
> proper physical interface, but a different logical network. In this
> case: 2001:db8:1234:5678::9
>
> When the NDP solicitations from 2001:db8:1234:5678::9 come in, OpenBSD
> does not respond to them, apparently because their source IP doesn't
> match the OpenBSD router's own prefix. The ISP router receives no
> neighbor advertisement from my OpenBSD router, and deems it unreachable.
> IPv6 is now down until a while later, when the solicitations happen to
> come from 2001:db8:1234:5678::11 again.
>
> RFC4861 says about the source IP for neighbor solicitations, that it has
> to be "an address assigned to the interface from which this message is
> sent". The ISP router firmware interprets this to mean "any address from
> the interface", thus using an IP from a different logical subnet.
> OpenBSD, in turn, does not seem to be willing to respond to requests
> from a different subnet.
>
> This was reproduced with OpenBSD 5.2-release, with pf turned off. It
> also happens on the production router, which happens to still run
> OpenBSD 4.6.
>
> To try to better understand the issue, I also set up a Linux system
> (Debian 6), which does in fact send advertisements in response to those
> wrong-prefix solicitations.
>
> What I understand is that either OpenBSD or the ISP router interpret the
> RFC in a way that leads to unintended results.
Interesting problem. I'm not sure who's at fault here.
I'm surprised your ISP doesn't use link-local addresses for transfer
networks (mine does).
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;
}
}
> Is this a bug in OpenBSD? Is there a workaround, e.g. in the form of a
> sysctl or a pf.conf hack that will make OpenBSD's NDP more liberal?
Have you tried using a /64 netmask at your end of the transfer link,
instead of the /125?
