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:
[01:37:04] root@nessie:/usr/src/linux>> ifup --verbose sit1
Configuring interface sit1=sit1 (inet6)
run-parts /etc/network/if-pre-up.d
ip tunnel add sit1 mode sit remote 138.25.6.14
ip link set sit1 up
ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
ip route add ::/0 via 3ffe:8001:000c:ffff::36
RTNETLINK answers: Invalid argument
Basically nothing gets through. Any attempts to ping/connect past my
gw fail and pinging the external gw results in packets coming back from
my gw (though with the eth0 IP addy) as if I were pinging it instead.
ie:
15 [01:41:34] hogarth@theirongiant:/home/hogarth>> ping6 3ffe:8001:000c:ffff::36PING 3ffe:8001:000c:ffff::36(3ffe:8001:c:ffff::36) from 3ffe:8002:1005::2 : 56 data bytes
64 bytes from 3ffe:8002:1005::1: icmp_seq=1 ttl=64 time=0.159 ms
64 bytes from 3ffe:8002:1005::1: icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from 3ffe:8002:1005::1: icmp_seq=3 ttl=64 time=0.109 ms
64 bytes from 3ffe:8002:1005::1: icmp_seq=4 ttl=64 time=0.116 ms
64 bytes from 3ffe:8002:1005::1: icmp_seq=5 ttl=64 time=0.114 ms
--- 3ffe:8001:000c:ffff::36 ping statistics ---
5 packets transmitted, 5 received, 0% loss, time 3999ms
rtt min/avg/max/mdev = 0.109/0.123/0.159/0.019 ms
Mind you, the same exact config works beautifully under 2.4.21-pre2.
If there are any patches you want me to try or help in any other way
(as far as debugging goes anyways :) then holler. :)
--
"How can I not love the Americans? They helped me with a flat tire the
other day," he said.
- http://www.toledoblade.com/apps/pbcs.dll/artikkel?SearchID=73139162287496&Avis=TO&Dato=20030624&Kategori=NEWS28&Lopenr=106240111&Ref=AR
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT <[email protected]> says:
>
> > 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:
> :
> > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
> > ip route add ::/0 via 3ffe:8001:000c:ffff::36
> > RTNETLINK answers: Invalid argument
>
> This is not bug, but rather misconfiguration;
> you cannot use prefix::, which is mandatory subnet routers
> anycast address, as unicast address.
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 prefix:: should
not give you EINVAL).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In article <[email protected]> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT <[email protected]> says:
> 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:
:
> ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
> ip route add ::/0 via 3ffe:8001:000c:ffff::36
> RTNETLINK answers: Invalid argument
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 <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
On Fri, Jul 11, 2003 at 12:55:42AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
> > ip route add ::/0 via 3ffe:8001:000c:ffff::36
> > RTNETLINK answers: Invalid argument
>
> This is not bug, but rather misconfiguration;
> you cannot use prefix::, which is mandatory subnet routers
> anycast address, as unicast address.
Ok. I'm a bit lost then. What should the line be then? To me the above
makes sense (and used to work), but then I'm not that experienced with
IPv6...
--
"How can I not love the Americans? They helped me with a flat tire the
other day," he said.
- http://www.toledoblade.com/apps/pbcs.dll/artikkel?SearchID=73139162287496&Avis=TO&Dato=20030624&Kategori=NEWS28&Lopenr=106240111&Ref=AR
In article <[email protected]> (at Thu, 10 Jul 2003 19:08:20 +0300 (EEST)), Pekka Savola <[email protected]> says:
> 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 prefix:: should
> not give you EINVAL).
But, on the other side cannot use prefix::, and
the setting is rather non-sense.
We should educate people not to use /127; use /64 instead.
v6ops? :-)
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
On Thu, 2003-07-10 at 18:43, CaT wrote:
> ip tunnel add sit1 mode sit remote 138.25.6.14
> ip link set sit1 up
> ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
> ip route add ::/0 via 3ffe:8001:000c:ffff::36
> RTNETLINK answers: Invalid argument
Try this:
ip route add ::/0 dev sit1
MikaL
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Thu, 10 Jul 2003 19:08:20 +0300 (EEST)), Pekka Savola <[email protected]> says:
>
> > 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 prefix:: should
> > not give you EINVAL).
>
> But, on the other side cannot use prefix::, and
> the setting is rather non-sense.
Not really. From the host perspective:
"I want to set default route to SOME default router"
(there may be multiple routers in the LAN, while only one at a time is
actively responding to the anycast address; if that one goes away,
another one takes its place.)
> We should educate people not to use /127; use /64 instead.
> v6ops? :-)
That's another story..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
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 <[email protected]> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT <[email protected]> says:
>
>
>
>>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:
>>
>>
>:
>
>
>>ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
>> ip route add ::/0 via 3ffe:8001:000c:ffff::36
>>RTNETLINK answers: Invalid argument
>>
>>
>
>This is not bug, but rather misconfiguration;
>you cannot use prefix::, which is mandatory subnet routers
>anycast address, as unicast address.
>
>Thank you.
>
>
>
On Thu, Jul 10, 2003 at 07:27:13PM +0300, Mika Liljeberg wrote:
> On Thu, 2003-07-10 at 18:43, CaT wrote:
> > ip tunnel add sit1 mode sit remote 138.25.6.14
> > ip link set sit1 up
> > ip addr add 3ffe:8001:000c:ffff::37/127 dev sit1
> > ip route add ::/0 via 3ffe:8001:000c:ffff::36
> > RTNETLINK answers: Invalid argument
>
> Try this:
>
> ip route add ::/0 dev sit1
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 /127 being mentioned as bad I changed the
interface config to a netmask of /64. Dropped it and brought it
up and it all works.
There's something fundamental about ipv6 netmasks that I just don't
understand...
--
"How can I not love the Americans? They helped me with a flat tire the
other day," he said.
- http://www.toledoblade.com/apps/pbcs.dll/artikkel?SearchID=73139162287496&Avis=TO&Dato=20030624&Kategori=NEWS28&Lopenr=106240111&Ref=AR
On Fri, 2003-07-11 at 02:39, CaT wrote:
> And having remembered /127 being mentioned as bad I changed the
> interface config to a netmask of /64. Dropped it and brought it
> up and it all works.
>
> There's something fundamental about ipv6 netmasks that I just don't
> understand...
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 had
only one valid unicast address (last bit == 1) in addition to the router
anycast address (last bit == 0).
Normally, IPv6 networks are supposed to use 64-bit on-link prefixes but
the implementation can be written in such a way that other prefix
lengths can be configured.
Setting your tunnel prefix to /64 is certainly the right thing to do.
MikaL
On fre, 2003-07-11 at 02:04, Mika Liljeberg wrote:
> 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 had
> only one valid unicast address (last bit == 1) in addition to the router
> anycast address (last bit == 0).
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 makes
perfect sense :-)
> Normally, IPv6 networks are supposed to use 64-bit on-link prefixes but
> the implementation can be written in such a way that other prefix
> lengths can be configured.
>
> Setting your tunnel prefix to /64 is certainly the right thing to do.
If you don't have anything but one /64 for example.. I guess /126's
would be ok as you could rule out the the anycast address? It will
probably work with Linux - but is it wrong in any sense, other than
"breaking" with EUI-64/autoconfiguration?
--
Cheers,
Andr? Tomt
[email protected]
In article <1057888154.26854.324.camel@localhost> (at 11 Jul 2003 03:49:14 +0200), Andre Tomt <[email protected]> says:
> 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 makes
> perfect sense :-)
Sorry for my poor explanation...
> If you don't have anything but one /64 for example.. I guess /126's
> would be ok as you could rule out the the anycast address? It will
> probably work with Linux - but is it wrong in any sense, other than
> "breaking" with EUI-64/autoconfiguration?
I don't think so, but I won't recoomend doing this.
(I even don't assign global addresses to p-t-p interface at all.)
--yoshfuji
On Fri, 2003-07-11 at 04:49, Andre Tomt wrote:
> > Setting your tunnel prefix to /64 is certainly the right thing to do.
>
> If you don't have anything but one /64 for example.. I guess /126's
> would be ok as you could rule out the the anycast address? It will
> probably work with Linux - but is it wrong in any sense, other than
> "breaking" with EUI-64/autoconfiguration?
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. I.e. you can add the local tunnel end-point as a /128. This
won't create an on-link route in the routing table, so you need to point
the default route to the interface rather than the peer end-point. For
example:
ifconfig sit0 add 3ffe:dead:beef::dead:beef/128
ip route add ::/0 dev sit0
Cheers,
MikaL
On 11 Jul 2003, Andre Tomt wrote:
> On fre, 2003-07-11 at 02:04, Mika Liljeberg wrote:
> > 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 had
> > only one valid unicast address (last bit == 1) in addition to the router
> > anycast address (last bit == 0).
>
> 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 makes
> perfect sense :-)
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 "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, 2003-07-11 at 07:51, Pekka Savola wrote:
> 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.
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.
Otherwise I fully agree. The subnet router anycast address doesn't
warrant any special handling.
MikaL
On 11 Jul 2003, Mika Liljeberg wrote:
> On Fri, 2003-07-11 at 07:51, Pekka Savola wrote:
> > 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.
>
> 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.
>
> Otherwise I fully agree. The subnet router anycast address doesn't
> warrant any special handling.
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 also a different
story..)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In article <[email protected]> (at Fri, 11 Jul 2003 08:22:39 +0300 (EEST)), Pekka Savola <[email protected]> says:
> (It might be nice to have configurable /proc option on whether to enable
> the subnet router anycast address at all, but that's also a different
> story..)
I don't like this
while I would be ok to have configuration option
not to support anycast.
--yoshfuji
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 11 Jul 2003 08:22:39 +0300 (EEST)), Pekka Savola <[email protected]> says:
>
> > (It might be nice to have configurable /proc option on whether to enable
> > the subnet router anycast address at all, but that's also a different
> > story..)
>
> I don't like this
> while I would be ok to have configuration option
> not to support anycast.
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 user-level API for setting anycast addresses, one
could kick the subnet-router anycast address out of the kernel too.
Whether that's desirable is another thing.)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In article <[email protected]> (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola <[email protected]> says:
> > I don't like this
> > while I would be ok to have configuration option
> > not to support anycast.
>
> 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.
I meant disabling anycast entirely.
> (Note that if there's a user-level API for setting anycast addresses, one
> could kick the subnet-router anycast address out of the kernel too.
> Whether that's desirable is another thing.)
We have but we cannot; it is refcnt'ed.
--yoshfuji
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 <[email protected]> (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola <[email protected]> says:
>
>
>
>>>I don't like this
>>>while I would be ok to have configuration option
>>>not to support anycast.
>>>
>>>
>>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.
>>
>>
>
>I meant disabling anycast entirely.
>
>
>
>>(Note that if there's a user-level API for setting anycast addresses, one
>>could kick the subnet-router anycast address out of the kernel too.
>>Whether that's desirable is another thing.)
>>
>>
>
>We have but we cannot; it is refcnt'ed.
>
>--yoshfuji
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola <[email protected]> says:
> > > I don't like this
> > > while I would be ok to have configuration option
> > > not to support anycast.
> >
> > 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.
>
> I meant disabling anycast entirely.
Oh, I'm not advocating that; however, being able to turn off the subnet
router anycast address might be a plus.
> > (Note that if there's a user-level API for setting anycast addresses, one
> > could kick the subnet-router anycast address out of the kernel too.
> > Whether that's desirable is another thing.)
>
> We have but we cannot; it is refcnt'ed.
I don't understand what you mean. Refcnt'ed by a userland process, so
that if you'd want the subnet-router anycast address, the whole time a
process (like radvd) should be running.. or what?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <[email protected]> says:
>
> > > We have but we cannot; it is refcnt'ed.
> >
> > I don't understand what you mean. Refcnt'ed by a userland process, so
> > that if you'd want the subnet-router anycast address, the whole time a
> > process (like radvd) should be running.. or what?
>
> 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
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In article <[email protected]> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <[email protected]> says:
> > We have but we cannot; it is refcnt'ed.
>
> I don't understand what you mean. Refcnt'ed by a userland process, so
> that if you'd want the subnet-router anycast address, the whole time a
> process (like radvd) should be running.. or what?
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.
--yoshfuji
In article <[email protected]> (at Fri, 11 Jul 2003 13:59:14 +0300 (EEST)), Pekka Savola <[email protected]> says:
> > So, you cannot remove subnet router anycast address from
> > kernel via this interface; kernel keeps one reference.
>
> .. which is why kernel shouldn't keep *any* reference *at all*!
No, it is because REQUIRED and UNREMOVABLE anycast address.
I don't think it is good to change this.
--yoshfuji
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 11 Jul 2003 13:59:14 +0300 (EEST)), Pekka Savola <[email protected]> says:
>
> > > So, you cannot remove subnet router anycast address from
> > > kernel via this interface; kernel keeps one reference.
> >
> > .. which is why kernel shouldn't keep *any* reference *at all*!
>
> No, it is because REQUIRED and UNREMOVABLE anycast address.
Smells like a circular requirement :-)
> I don't think it is good to change this.
That's another issue entirely.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Fri, 11 Jul 2003 13:47:48 +0300 (EEST)), Pekka Savola <[email protected]> says:
>
> > On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> > > In article <[email protected]> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <[email protected]> says:
> > >
> > > > > We have but we cannot; it is refcnt'ed.
> > > >
> > > > I don't understand what you mean. Refcnt'ed by a userland process, so
> > > > that if you'd want the subnet-router anycast address, the whole time a
> > > > process (like radvd) should be running.. or what?
> > >
> > > 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.
>
> So, you cannot remove subnet router anycast address from
> kernel via this interface; kernel keeps one reference.
.. which is why kernel shouldn't keep *any* reference *at all*!
> (Hmm, I may misunderstand your mail...)
.. seems like it..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In article <[email protected]> (at Fri, 11 Jul 2003 13:47:48 +0300 (EEST)), Pekka Savola <[email protected]> says:
> On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> > In article <[email protected]> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <[email protected]> says:
> >
> > > > We have but we cannot; it is refcnt'ed.
> > >
> > > I don't understand what you mean. Refcnt'ed by a userland process, so
> > > that if you'd want the subnet-router anycast address, the whole time a
> > > process (like radvd) should be running.. or what?
> >
> > 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.
So, you cannot remove subnet router anycast address from
kernel via this interface; kernel keeps one reference.
(Hmm, I may misunderstand your mail...)
--yoshfuji
Ok,
Here's a valid use for subnet router anycase that isn't working.
Somebody asked me how to set up 6to4, so I did a little testing.
Doesn't work:
hades:~# ip route add ::/0 via 2002:c058:6301::
RTNETLINK answers: Invalid argument
Works:
hades:~# ip route add ::/0 via 2002:c058:6301::1
Unfortunately the first form is what I need:
hades:~# host -t AAAA 6to4.ipv6.funet.fi
6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624
6to4.ipv6.funet.fi has AAAA address 2002:c058:6301::
So apparently there really is an inappropriate subnet router anycast
sanity check. Please fix this!
MikaL
On Fri, 2003-07-11 at 08:22, Pekka Savola wrote:
> On 11 Jul 2003, Mika Liljeberg wrote:
> > On Fri, 2003-07-11 at 07:51, Pekka Savola wrote:
> > > 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.
> >
> > 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.
> >
> > Otherwise I fully agree. The subnet router anycast address doesn't
> > warrant any special handling.
>
> 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 also a different
> story..)
On 11 Jul 2003, Mika Liljeberg wrote:
> Here's a valid use for subnet router anycase that isn't working.
> Somebody asked me how to set up 6to4, so I did a little testing.
>
> Doesn't work:
>
> hades:~# ip route add ::/0 via 2002:c058:6301::
> RTNETLINK answers: Invalid argument
>
> Works:
>
> hades:~# ip route add ::/0 via 2002:c058:6301::1
>
> Unfortunately the first form is what I need:
>
> hades:~# host -t AAAA 6to4.ipv6.funet.fi
> 6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624
> 6to4.ipv6.funet.fi has AAAA address 2002:c058:6301::
I think that in this particular case, if should have configured your
interface address with 2002:v4:addr::/16, of which subnet anycast router
address would be 2002::.
> So apparently there really is an inappropriate subnet router anycast
> sanity check. Please fix this!
This *may* be caused by another issue too: nexthop's must be given in the
compatible "::192.88.99.1" format, not 2002:xxxx :-(
I sent a patch on over a year or so ago, but it didn't gain that much
enthusiasm..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, 2003-07-11 at 14:48, Pekka Savola wrote:
> On 11 Jul 2003, Mika Liljeberg wrote:
> > Here's a valid use for subnet router anycase that isn't working.
> > Somebody asked me how to set up 6to4, so I did a little testing.
> >
> > Doesn't work:
> >
> > hades:~# ip route add ::/0 via 2002:c058:6301::
> > RTNETLINK answers: Invalid argument
> >
> > Works:
> >
> > hades:~# ip route add ::/0 via 2002:c058:6301::1
> >
> > Unfortunately the first form is what I need:
> >
> > hades:~# host -t AAAA 6to4.ipv6.funet.fi
> > 6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624
> > 6to4.ipv6.funet.fi has AAAA address 2002:c058:6301::
>
> I think that in this particular case, if should have configured your
> interface address with 2002:v4:addr::/16, of which subnet anycast router
> address would be 2002::.
Ah ok. It *is* configured with a /16. As far as my host is concerned,
2002:c058:6301:: should be just a unicast address like any other, so
maybe there is a IID==0 check somewhere?
> > So apparently there really is an inappropriate subnet router anycast
> > sanity check. Please fix this!
>
> This *may* be caused by another issue too: nexthop's must be given in the
> compatible "::192.88.99.1" format, not 2002:xxxx :-(
>
> I sent a patch on over a year or so ago, but it didn't gain that much
> enthusiasm..
I vote for fixing this too. :-)
MikaL
It turns out to be the (otherwise valid) check for IFF_LOOPBACK for
gateway's address in ip6_route_add() that gives EINVAL for prefix::, and
has nothing to do with iid being 0, just a coinsidence....
--Mika
Mika Liljeberg wrote:
>On Fri, 2003-07-11 at 14:48, Pekka Savola wrote:
>
>
>>On 11 Jul 2003, Mika Liljeberg wrote:
>>
>>
>>>Here's a valid use for subnet router anycase that isn't working.
>>>Somebody asked me how to set up 6to4, so I did a little testing.
>>>
>>>Doesn't work:
>>>
>>>hades:~# ip route add ::/0 via 2002:c058:6301::
>>>RTNETLINK answers: Invalid argument
>>>
>>>Works:
>>>
>>>hades:~# ip route add ::/0 via 2002:c058:6301::1
>>>
>>>Unfortunately the first form is what I need:
>>>
>>>hades:~# host -t AAAA 6to4.ipv6.funet.fi
>>>6to4.ipv6.funet.fi has AAAA address 2001:708:0:1::624
>>>6to4.ipv6.funet.fi has AAAA address 2002:c058:6301::
>>>
>>>
>>I think that in this particular case, if should have configured your
>>interface address with 2002:v4:addr::/16, of which subnet anycast router
>>address would be 2002::.
>>
>>
>
>Ah ok. It *is* configured with a /16. As far as my host is concerned,
>2002:c058:6301:: should be just a unicast address like any other, so
>maybe there is a IID==0 check somewhere?
>
>
>
>>>So apparently there really is an inappropriate subnet router anycast
>>>sanity check. Please fix this!
>>>
>>>
>>This *may* be caused by another issue too: nexthop's must be given in the
>>compatible "::192.88.99.1" format, not 2002:xxxx :-(
>>
>>I sent a patch on over a year or so ago, but it didn't gain that much
>>enthusiasm..
>>
>>
>
>I vote for fixing this too. :-)
>
> MikaL
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Fri, 2003-07-11 at 15:48, Mika Penttil? wrote:
> It turns out to be the (otherwise valid) check for IFF_LOOPBACK for
> gateway's address in ip6_route_add() that gives EINVAL for prefix::, and
> has nothing to do with iid being 0, just a coinsidence....
Not sure. Seems to me that ipv6_addr_type() flags the gateway address as
anycast. In ip6_route_addr() [2.5.74] we have:
if (rtmsg->rtmsg_flags & RTF_GATEWAY) {
struct in6_addr *gw_addr;
int gwa_type;
gw_addr = &rtmsg->rtmsg_gateway;
ipv6_addr_copy(&rt->rt6i_gateway, &rtmsg->rtmsg_gateway);
gwa_type = ipv6_addr_type(gw_addr);
if (gwa_type != (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST)) {
struct rt6_info *grt;
/* IPv6 strictly inhibits using not link-local
addresses as nexthop address.
Otherwise, router will not able to send redirects.
It is very good, but in some (rare!) curcumstances
(SIT, PtP, NBMA NOARP links) it is handy to allow
some exceptions. --ANK
*/
err = -EINVAL;
if (!(gwa_type&IPV6_ADDR_UNICAST))
goto out;
Looks like it would bail out here, unless I read the code wrong. How about:
if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST)))
goto out;
MikaL
afaics, ipv6_addr_type() checks just for some rfc-specified reserved
anycast addresses, not the ones in device list. Anyway, it will surely
also bail out from the loopback test (anycast subnet router address is
ours).
--Mika
Mika Liljeberg wrote:
>On Fri, 2003-07-11 at 15:48, Mika Penttil? wrote:
>
>
>>It turns out to be the (otherwise valid) check for IFF_LOOPBACK for
>>gateway's address in ip6_route_add() that gives EINVAL for prefix::, and
>>has nothing to do with iid being 0, just a coinsidence....
>>
>>
>
>Not sure. Seems to me that ipv6_addr_type() flags the gateway address as
>anycast. In ip6_route_addr() [2.5.74] we have:
>
> if (rtmsg->rtmsg_flags & RTF_GATEWAY) {
> struct in6_addr *gw_addr;
> int gwa_type;
>
> gw_addr = &rtmsg->rtmsg_gateway;
> ipv6_addr_copy(&rt->rt6i_gateway, &rtmsg->rtmsg_gateway);
> gwa_type = ipv6_addr_type(gw_addr);
>
> if (gwa_type != (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST)) {
> struct rt6_info *grt;
>
> /* IPv6 strictly inhibits using not link-local
> addresses as nexthop address.
> Otherwise, router will not able to send redirects.
> It is very good, but in some (rare!) curcumstances
> (SIT, PtP, NBMA NOARP links) it is handy to allow
> some exceptions. --ANK
> */
> err = -EINVAL;
> if (!(gwa_type&IPV6_ADDR_UNICAST))
> goto out;
>
>Looks like it would bail out here, unless I read the code wrong. How about:
>
> if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST)))
> goto out;
>
> MikaL
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Fri, 2003-07-11 at 17:27, Mika Penttil? wrote:
> afaics, ipv6_addr_type() checks just for some rfc-specified reserved
> anycast addresses, not the ones in device list. Anyway, it will surely
> also bail out from the loopback test (anycast subnet router address is
> ours).
Nope, since the tunnel interface will have 2002::/16. It seems to work
with the attached patch (against 2.4.21-ac4). A small fix to sit was
required as well. Look:
hades:~# ifconfig 6to4
6to4 Link encap:IPv6-in-IPv4
inet6 addr: ::213.243.180.94/128 Scope:Compat
inet6 addr: 2002:d5f3:b45e::1/16 Scope:Global
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:416 (416.0 b) TX bytes:496 (496.0 b)
hades:~# ip -6 route list
::/96 via :: dev 6to4 metric 256 mtu 1480 advmss 1420
2002::/16 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
fe80::/64 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420
ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
ff00::/8 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420
default via 2002:c058:6301:: dev 6to4 metric 1024 mtu 1480 advmss 1420
hades:~# ping6 -c4 -n http://www.ipv6.org
PING http://www.ipv6.org(2001:6b0:1:ea:a00:20ff:fe8f:708f) 56 data bytes
64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=1 ttl=250 time=207 ms
64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=2 ttl=250 time=206 ms
64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3 ttl=250 time=177 ms
64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=4 ttl=250 time=78.5 ms
--- http://www.ipv6.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3030ms
rtt min/avg/max/mdev = 78.547/167.637/207.698/52.821 ms
Anyone see any problems with this?
MikaL
Mika Liljeberg wrote:
>Nope, since the tunnel interface will have 2002::/16. It seems to work
>with the attached patch (against 2.4.21-ac4). A small fix to sit was
>required as well. Look:
>
>
ok, forgot that...looks ok to me.
--Mika
>hades:~# ifconfig 6to4
>6to4 Link encap:IPv6-in-IPv4
> inet6 addr: ::213.243.180.94/128 Scope:Compat
> inet6 addr: 2002:d5f3:b45e::1/16 Scope:Global
> UP RUNNING NOARP MTU:1480 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:416 (416.0 b) TX bytes:496 (496.0 b)
>
>hades:~# ip -6 route list
>::/96 via :: dev 6to4 metric 256 mtu 1480 advmss 1420
>2002::/16 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420
>fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
>fe80::/64 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420
>ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
>ff00::/8 dev 6to4 proto kernel metric 256 mtu 1480 advmss 1420
>default via 2002:c058:6301:: dev 6to4 metric 1024 mtu 1480 advmss 1420
>hades:~# ping6 -c4 -n http://www.ipv6.org
>PING http://www.ipv6.org(2001:6b0:1:ea:a00:20ff:fe8f:708f) 56 data bytes
>64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=1 ttl=250 time=207 ms
>64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=2 ttl=250 time=206 ms
>64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=3 ttl=250 time=177 ms
>64 bytes from 2001:6b0:1:ea:a00:20ff:fe8f:708f: icmp_seq=4 ttl=250 time=78.5 ms
>
>--- http://www.ipv6.org ping statistics ---
>4 packets transmitted, 4 received, 0% packet loss, time 3030ms
>rtt min/avg/max/mdev = 78.547/167.637/207.698/52.821 ms
>
>Anyone see any problems with this?
>
> MikaL
>
>
>
>------------------------------------------------------------------------
>
>--- route.c.org 2003-07-11 16:41:55.000000000 +0300
>+++ route.c 2003-07-11 16:42:16.000000000 +0300
>@@ -743,7 +743,7 @@
> some exceptions. --ANK
> */
> err = -EINVAL;
>- if (!(gwa_type&IPV6_ADDR_UNICAST))
>+ if (!(gwa_type&(IPV6_ADDR_UNICAST|IPV6_ADDR_ANYCAST)))
> goto out;
>
> grt = rt6_lookup(gw_addr, NULL, rtmsg->rtmsg_ifindex, 1);
>--- sit.c.org 2003-07-11 16:57:53.000000000 +0300
>+++ sit.c 2003-07-11 17:17:42.000000000 +0300
>@@ -495,10 +495,13 @@
> addr_type = ipv6_addr_type(addr6);
> }
>
>- if ((addr_type & IPV6_ADDR_COMPATv4) == 0)
>- goto tx_error_icmp;
>+ if ((addr_type & IPV6_ADDR_COMPATv4))
>+ dst = addr6->s6_addr32[3];
>+ else
>+ dst = try_6to4(addr6);
>
>- dst = addr6->s6_addr32[3];
>+ if (!dst)
>+ goto tx_error_icmp;
> }
>
> if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) {
>
>