Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[kuznet]

Hello!

> Alexey, please add some sanity to this discussion.

It is about anycast addresses, I maybe not competent here.
I have no idea what is purpose of all-routers anycast.

However, my modest opinion is here:

IN NO WAY ANYCAST ADDRESSES MAY BE USED AS NEXTHOP ADDRESSES.
NEXTHOP ADDRESS IS THE ADDRESS WHICH IS EXPECTED TO BE SOURCE OF REDIRECT
MESSAGES ET AL. ANYCAST ADDRESSES ARE INVALID AS SOURCE, HENCE...

Period.

Alexey

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Tue, 15 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > Alexey, please add some sanity to this discussion.
> 
> It is about anycast addresses, I maybe not competent here.
> I have no idea what is purpose of all-routers anycast.
> 
> However, my modest opinion is here:
> 
> IN NO WAY ANYCAST ADDRESSES MAY BE USED AS NEXTHOP ADDRESSES.
> NEXTHOP ADDRESS IS THE ADDRESS WHICH IS EXPECTED TO BE SOURCE OF REDIRECT
> MESSAGES ET AL. ANYCAST ADDRESSES ARE INVALID AS SOURCE, HENCE...

Modestly, I disagree.

You just can't get away from the requirement of having be able to
"resolve" next-hops.  I.e., the requirement that the users/protocols will
give you non-final nexthop information which you have to "resolve" to get
the final nexthop (e.g. a global address -> a link-local address 
obtained using Neighbor Discovery).

You want to avoid that: simple IPv4 routers can, but IPv6 in particular,
as it implements different scopes which are used extensively especially
with Neighbor Discovery, can't really live without it.

I'm not sure about the level of complexity resolvable next-hops cause, but 
it shouldn't be huge.  The tricky part where proprietary vendors often 
break are the cases when the "global nexthop" changes but the mapping to 
the resolved nexthop is not updated.

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

[kuznet]

Hello!

> "resolve" next-hops.  I.e., the requirement that the users/protocols will
> give you non-final nexthop information which you have to "resolve" to get
> the final nexthop (e.g. a global address -> a link-local address 
> obtained using Neighbor Discovery).

No way to resolve exists, unless it already embedded to corresponding protocol.
F.e. global address and its link-local equivalent could be transferred
as attributes of BGP4+, global address is used to validate nexthop attribute
and as soon as it happens to be on-link, its link-local counterpart is used.

If you have a global address out of context and want to use it as nexthop,
you are in troubles. You have no way to get a unique router identifier,
it is just not defined. So, you have to use global one (and kernel has to allow
this), and surely will screw up the network, unless some policy constraints
make the configuration legal.

Well, actually, we inevitably arrive to conclusion that all the idea
about scoped addresses is just a garbage, which results in nothing
but inconveniences and innumerous inconsistencies. I remember some
people predicted that it will be dropped to start of real Ipv6 deployment.
Well, it is still not night.

Alexey

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Tue, 15 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > "resolve" next-hops.  I.e., the requirement that the users/protocols will
> > give you non-final nexthop information which you have to "resolve" to get
> > the final nexthop (e.g. a global address -> a link-local address 
> > obtained using Neighbor Discovery).
> 
> No way to resolve exists, unless it already embedded to corresponding
> protocol.

Assume you're a host on a link with prefix 3FFE:FFFF:A:B::/64.  The router 
is the one with interface ID one.

What happens when you do "ping6 3FFE:FFFF:A:B::1" ? Seems to resolve a 
link-local address for the router just fine.

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

[kuznet]

Hello!

> Assume you're a host on a link with prefix 3FFE:FFFF:A:B::/64.  The router 
> is the one with interface ID one.

Not going to work. Host autoconfiguration conventions have nothing
to do with real addressing. Proceeding in this way you will denounce
neighbour discovery, what the hell to do this when hw address can be recovered
from EUI64 token? :-)


> What happens when you do "ping6 3FFE:FFFF:A:B::1" ?

Hey, you have lost track, rewind several mails ago. Of course, ping and
any other protocols will work, how can it not work? :-)

Alexey

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Wed, 16 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > Assume you're a host on a link with prefix 3FFE:FFFF:A:B::/64.  The router 
> > is the one with interface ID one.
> 
> Not going to work. Host autoconfiguration conventions have nothing
> to do with real addressing. Proceeding in this way you will denounce
> neighbour discovery, what the hell to do this when hw address can be recovered
> from EUI64 token? :-)

Did you miss the word "Assume" ?

> > What happens when you do "ping6 3FFE:FFFF:A:B::1" ?
> 
> Hey, you have lost track, rewind several mails ago. 

Nope.  I'm just pointing out the general concept.

> Of course, ping and
> any other protocols will work, how can it not work? :-)

It has been made shown to work on other platforms, so why not Linux?

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

[kuznet]

Hello!

> > > What happens when you do "ping6 3FFE:FFFF:A:B::1" ?
> > 
> > Hey, you have lost track, rewind several mails ago. 
> 
> Nope.  I'm just pointing out the general concept.
> 
> > Of course, ping and
> > any other protocols will work, how can it not work? :-)
> 
> It has been made shown to work on other platforms, so why not Linux?

ping did, does and will work and I do not understand what you want
to say or ask. Do you want to know how it works?

Well, IPv6 stack looks up the address in routing tables, finds the route,
sees that it is on-link, sends NDISC, receiver replies, we create a frame
and send the echo request. To continue? :-)

Alexey

Re: 2.4.21+ - IPv6 over IPv4 tunneling b0rked

[Pekka Savola]

On Thu, 17 Jul 2003 kuznet@ms2.inr.ac.ru wrote:
> > > > What happens when you do "ping6 3FFE:FFFF:A:B::1" ?
> 
> ping did, does and will work and I do not understand what you want
> to say or ask. Do you want to know how it works?
> 
> Well, IPv6 stack looks up the address in routing tables, finds the route,
> sees that it is on-link, sends NDISC, receiver replies, we create a frame
> and send the echo request. To continue? :-)

(Sorry, it seems I've caused a lot of confusion in some parts of this 
thread by typoeing link-local address when I used link-layer address.. 
sorry)

So, assume you have 3FFE:FFFF:A:B::/64 prefix on link.  On a host on that 
link, you've manually configured the next-hop to be the router on that 
link, 3FFE:FFFF:A:B::1.

The procedure to obtain the knowledge on where to send packets whose 
next-hop is 3FFE:FFFF:A:B::1 seems quite simple, similar to ping6.

As to obtaining the link-*local* address, there are several procedures 
none of which I would recomment.  Checking the source address of a ND 
packet (e.g. in the ping6 example above), or using a protocol like ICMP 
name information queries (draft-ietf-ipngwg-icmp-name-lookups-10.txt).

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

See 
http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.txt 
it should answer your questions.

On Mon, 14 Jul 2003, Anand Kumria wrote:
> On Fri, 11 Jul 2003 02:08:20 +1000, Pekka Savola wrote:
> 
> > 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.
> 
> I'm the other end of this link, so I'm wondering how this is a
> misconfiguration. RFC3513 2.6.1 suggests to me that
> 3ffe:8001:c:ffff::36/127 is the router address (my end) and the other
> side should be 3ffe:8001:c:ffff::37/127.
> 
> > 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).
> > 
> 
> Both Yoshifuji and yourself suggested that /127 isn't the way to go and
> that this is something v6ops ought to take up. I had a quick look at the
> v6ops IETF group and nothing struck me.
> 
> What would you recommend I look at to see why /127 is a bad idea or /64
> is a better idea than /127?
> 
> Thanks,
> Anand
> 
> 

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

[Anand Kumria]

On Fri, 11 Jul 2003 02:08:20 +1000, Pekka Savola wrote:

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

I'm the other end of this link, so I'm wondering how this is a
misconfiguration. RFC3513 2.6.1 suggests to me that
3ffe:8001:c:ffff::36/127 is the router address (my end) and the other
side should be 3ffe:8001:c:ffff::37/127.

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

Both Yoshifuji and yourself suggested that /127 isn't the way to go and
that this is something v6ops ought to take up. I had a quick look at the
v6ops IETF group and nothing struck me.

What would you recommend I look at to see why /127 is a bad idea or /64
is a better idea than /127?

Thanks,
Anand

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

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

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]

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

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

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

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

[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

[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

[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

[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

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

[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

[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

[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

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

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

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

[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

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

[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

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