2.4.21+ - IPv6 over IPv4 tunneling b0rked

2.4.21+ - IPv6 over IPv4 tunneling b0rked

[CaT]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT <cat@zip.com.au> 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 <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[CaT]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <20030710154302.GE1722@zip.com.au> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT <cat@zip.com.au> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling broken

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0307101906160.18224-100000@netcore.fi> (at Thu, 10 Jul 2003 19:08:20 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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 <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: 2.4.21+ - IPv6 over IPv4 tunneling broken

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0307101906160.18224-100000@netcore.fi> (at Thu, 10 Jul 2003 19:08:20 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Penttilä]

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@zip.com.au> (at Fri, 11 Jul 2003 01:43:03 +1000), CaT <cat@zip.com.au> 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.
>
>  
>

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[CaT]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Andre Tomt]

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
andre@tomt.net

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling broken

[YOSHIFUJI Hideaki / 吉藤英明]

In article <1057888154.26854.324.camel@localhost> (at 11 Jul 2003 03:49:14 +0200), Andre Tomt <andre@tomt.net> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0307110821110.24981-100000@netcore.fi> (at Fri, 11 Jul 2003 08:22:39 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0307110821110.24981-100000@netcore.fi> (at Fri, 11 Jul 2003 08:22:39 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0307111143470.26262-100000@netcore.fi> (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Penttilä]

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@netcore.fi> (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0307111143470.26262-100000@netcore.fi> (at Fri, 11 Jul 2003 11:46:00 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0307111301520.27036-100000@netcore.fi> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0307111301520.27036-100000@netcore.fi> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0307111347090.27351-100000@netcore.fi> (at Fri, 11 Jul 2003 13:47:48 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> says:
> 
> > On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> > > In article <Pine.LNX.4.44.0307111301520.27036-100000@netcore.fi> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0307111347090.27351-100000@netcore.fi> (at Fri, 11 Jul 2003 13:47:48 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> says:

> On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> > In article <Pine.LNX.4.44.0307111301520.27036-100000@netcore.fi> (at Fri, 11 Jul 2003 13:03:54 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.44.0307111358440.27351-100000@netcore.fi> (at Fri, 11 Jul 2003 13:59:14 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Fri, 11 Jul 2003, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0307111358440.27351-100000@netcore.fi> (at Fri, 11 Jul 2003 13:59:14 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> 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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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..)

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Penttilä]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

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

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Penttilä]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Liljeberg]

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

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 www.ipv6.org
PING 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

--- 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


[-- Attachment #2: 6to4.udiff --]
[-- Type: text/plain, Size: 881 bytes --]

--- 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)) {

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Mika Penttilä]

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 www.ipv6.org
>PING 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
>
>--- 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)) {
>  
>