[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: IPv6 and ND on tap(4)
On Sat, Sep 17, 2011 at 09:20:06AM -0400, Greg Troxel wrote:
> Is the prefix you are using on the tap different than the one on your
> real interface?
Yes. hme0 has 2001:608:8003::/64, tap0 has 2001:608:4:a051::/64.
> ip6mode=autohost is supposed to, more or less, configure a system to
> accept router advertisements
> send router solicitations
... which should be fairly harmless, and "a fairly typical thing for a
> I think there's a general notion in the specs that an autoconfigured
> host is only allowed to have one interface.
Which is fine from the point of view "it shouldn't be acting as a router",
but for the generic VPN case, this is too strict.
(Of course, "a *proper* VPN would be IPSEC", and anything else is an
abomination in the first place - but that doesn't really solve
real-world problems either)
Interesting enough, this doesn't pose a problem for OpenVPN "tun" usage,
and most likely not for other ppp-based VPNs (pptp/l2tp) either as there's
no ND involved anyway...
> But the kernel behavior seems bad.
> You can probably look at the code:
> ~/NetBSD-current/src/sys > egrep accept_rtadv */*.c
> and maybe this will become clearer.
I'll go digging and thinking... (and testing on Free- and OpenBSD whether
this is a common issue on Kame-based stacks)
> > > fe80::f00b:a4ff:fe00:4dd2%tap0 f2:0b:a4:00:4d:d2 UHL 0 0 - lo0
> > This one seems wrong. I have no such entry but instead have an ND cache
> > entry. I suspect this and the missing cloning route are related.
> I see "UHL... lo0" routes for all IPv6 addresses that the system has,
> and "UHLc" for ND (+arp) cache entries:
> Sorry, I see those too, which makes sense.
OK, good. So it was just a "red herring" muddling the original issue :-)
USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany
Main Index |
Thread Index |