With 2.4.21-pre2 I can get a nice tunnel going over my ppp connection and as such get ipv6 connectivity. I think went to 2.4.21 and then to 2.4.22-pre4 and bringing up the tunnel fails as follows: [0
This is not bug, but rather misconfiguration; you cannot use prefix::, which is mandatory subnet routers anycast address, as unicast address. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project <yoshfuji
While technically correct, I'm still not sure if this is (pragmatically) the correct approach. It's OK to set a default route to go to the subnet routers anycast address (so, setting a route to prefi
But 3ffe:8001:000c:ffff::36 is _not_ subnet routers anycast address. Anyway, looks like a bug to me... --Mika YOSHIFUJI Hideaki / ???? wrote: In article <20030710154302.GE1722@xxxxxxxxxx> (at Fri, 11
That didn't complain but pings to the ext gw were broken. Noticed the route contained: 3ffe:8001:c:ffff::36/127 via :: dev sit1 proto kernel metric 256 mtu 1480 adv mss 1420 And having remembered /12
Well, the thing is that prefix:: is a special anycast address that identifies a router on the link prefix::/n, where n is the prefix length. You had configured a 127-bit link prefix, meaning that you
Thanks for the explanation, I've been struggling to understand what Yoshfuji tried to explain to me earlier on this topic (see "IPv6 bugs introduced in 2.4.21" - ie. my bogus bugreport), now it all m
It doesn't really make sense to use a prefix longer then /64. The last 64 bits are generally reserved for interface ID. What you can do, though, is not configure a link prefix for the tunnel at all.
Well, the system may make some sense, but IMHO, there is still zero sense in policing this thing when you add a route. That's just plain bogus. This is a bug which must be fixed ASAP. -- Pekka Savola
Correct me if I'm wrong but I think in this case the interface had forwarding enabled and the sanity check in fact prevented a default route pointing to the node itself from being configured. Otherwi
If that's the case, it's OK -- it's OK, I don't remember the details. (It might be nice to have configurable /proc option on whether to enable the subnet router anycast address at all, but that's als
With "not to support anycast" you probably meant "not to support subnet-router anycast address [automatically, in the kernel, as now]" ? These are entirely different things. (Note that if there's a u
Who adds the subnet router anycast address, kernel itself? Since what? I don't see this in 2.5. --Mika YOSHIFUJI Hideaki / ???? wrote: In article <Pine.LNX.4.44.0307111143470.26262-100000@xxxxxxxxxx>
Oh, I'm not advocating that; however, being able to turn off the subnet router anycast address might be a plus. I don't understand what you mean. Refcnt'ed by a userland process, so that if you'd wan
Kernel has refcnt for subnet router anycast address. Ref/dereference from userspace is done via socket. You cannot derefer subnet router anycast address from userspace if the socket hasn't refered it
So? The point is that subnet router anycast address *could* be referenced explicitly by a user-land socket (e.g. by radvd), not kernel at all. -- Pekka Savola "You each name yourselves king, yet the