Forum - Default route vs 2000::/3 on Linux :: SixXS

Default route vs 2000::/3 on Linux

Shadow Hawkins on Tuesday, 20 March 2007 17:34:03

Hi, I've set up my local subnet and tunnel, and everything related to sixxs works fine. Aiccu sets up a default route, which works fine for all communication from the router machine. However, this default route doesn't seem to work for packets coming from other machines on the local network, I seem to have to add a route of 2000::/3 to the gateway. As far as I've been able to gather from comments, this shouldn't be needed on modern kernels (newer than 2.4.20). (Also, since aiccu only sets up a real default route and no 2000::/3 route, I'd suspect that this should be everything that's needed.) I'm using 2.6.8 (Debian sarge), is this new enough? For reference, this is what the routing table looks like:

Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface ::1/128 :: U 0 2 0 lo 2001:14b8:100:1c1::/128 :: U 0 0 0 lo 2001:14b8:100:1c1::2/128 :: U 0 68435 0 lo 2001:14b8:100:1c1::/64 :: U 256 33351 0 sixxs 2001:14b8:147::/128 :: U 0 0 0 lo 2001:14b8:147::1/128 :: U 0 19 0 lo 2001:14b8:147:0:211:24ff:fed5:cc9c/128 2001:14b8:147:0:211:24ff:fed5:cc9c UC 0 3 0 eth1 2001:14b8:147::/64 :: U 256 0 0 eth1 2000::/3 2001:14b8:100:1c1::1 UG 1 4515 0 sixxs fe80::/128 :: U 0 0 0 lo fe80::82e8:78e4/128 :: U 0 0 0 lo fe80::20a:5eff:fe65:998c/128 :: U 0 422 0 lo fe80::230:84ff:fe9f:8af/128 :: U 0 11 0 lo fe80::/64 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth1 fe80::/64 :: U 256 0 0 sixxs ff02::1/128 ff02::1 UC 0 2 1 eth1 ff00::/8 :: U 256 0 0 eth0 ff00::/8 :: U 256 0 0 eth1 ff00::/8 :: U 256 0 0 sixxs ::/0 2001:14b8:100:1c1::1 UG 1024 2156 1 sixxs

This works fine, but when the 2000::/3 route is removed, packets from the local network aren't routed out to the tunnel anymore. Is this normal behaviour (in that case, why doesn't aiccu add such a route?) or should I consider upgrading the kernel? // Martin

Default route vs 2000::/3 on Linux

Jeroen Massar SixXS Staff

on Tuesday, 20 March 2007 18:39:33

First off, in general it is better to run Debian unstable for most IPv6 tools, as more of them have found their way into unstable. Etch is of course fairly new too in this respect. As for the kernel, upgrade! 2.6.8 definitely has a couple of security issues (which are maybe patched up by Debian's excellent security team though who tend to backport those things). IPv6 has improved a lot around 2.6.16 though, and recently there was a security bug fixed in 2.6.20.1 so upgrading is heavily recommended for IPv6 usage. We haven't had a report about this for quite some while. Most likely as this problem was resolved in 2.4.20 which was released on 28-Nov-2002, while the first 2.6 kernels are from 18-Dec-2003 and already included that fixup and most if not all distributions use a newer kernel than that. And looking at the source for 2.6.8, it contains CVS version: * $Id: ip6_fib.c,v 1.25 2001/10/31 21:55:55 davem Exp $ and at the top: /* * Changes: * Yuji SEKIYA @USAGI: Support default route on router node; * remove ip6_null_entry from the top of * routing table. */ and 2.6.0 also includes that part. (I would almost think they don't change the $Id's anymore....) Nevertheless both should work fine with a '::/0' route. So clearly this was also in 2.6.8 already. Can you try typing "ip -6 get 2001::1" before and after removing that route? It should show where the packet is going to be routed to. PS: You might want to nullroute your /48 with: "ip -6 ro 2001:14b8:147::/48 dev null" this way packets coming in for other parts of your /48 which you don't route will be 'terminated' at your router, otherwise you are sending them back up the default route, who will reject the packet as it suddenly comes from the wrong address space. This is another reason why you should filter outgoing packets and only allow packets sourced from your own /48 and the tunnel IP to travel outbound.

Default route vs 2000::/3 on Linux

Shadow Hawkins on Tuesday, 20 March 2007 19:35:58

Thanks for the hints!

I'll probably upgrade when etch is released, otherwise I assume the security updates are enough...

Can you try typing "ip -6 get 2001::1" before and after removing that route? It should show where the packet is going to be routed to.

Calling "ip -6 route get 2001::1" gives this

2001::1 via 2001:14b8:100:1c1::1 dev sixxs src 2001:14b8:100:1c1::2 metric 1 mtu 1280 advmss 1220 hoplimit 64

when the 2000::/3 route is in place, and this

2001::1 via 2001:14b8:100:1c1::1 dev sixxs src 2001:14b8:100:1c1::2 metric 1024 mtu 1280 advmss 1220 hoplimit 64

with only the real default ::/0 route in place. I've also tried adding a real default route with a metric of 1, but it didn't change anything.

PS: You might want to nullroute your /48 with: "ip -6 ro 2001:14b8:147::/48 dev null" this way packets coming in for other parts of your /48 which you don't route will be 'terminated' at your router, otherwise you are sending them back up the default route, who will reject the packet as it suddenly comes from the wrong address space. This is another reason why you should filter outgoing packets and only allow packets sourced from your own /48 and the tunnel IP to travel outbound.

When I try to add that null route using "ip -6 ro add 2001:14b8:147::/48 dev null", I get this error message:

Cannot find device "null"

I also tried the same using the old-fashioned route command, "route -A inet6 add 2001:14b8:147::/48 dev null", giving:

SIOGIFINDEX: No such device

// Martin

Default route vs 2000::/3 on Linux

Jeroen Massar SixXS Staff

on Tuesday, 20 March 2007 19:46:11

Calling "ip -6 route get 2001::1" gives this:

2001::1 via 2001:14b8:100:1c1::1 dev sixxs src 2001:14b8:100:1c1::2 metric 1 mtu 1280 advmss 1220 hoplimit 64

when the 2000::/3 route is in place, and this:

2001::1 via 2001:14b8:100:1c1::1 dev sixxs src 2001:14b8:100:1c1::2 metric 1024 mtu 1280 advmss 1220 hoplimit 64

Both the same, so it should definitely work, which implies there is something else wrong with. The metric is of no matter, as the above is 'the best route' that will be chosen for those packets. Time to pull out wireshark and trying to find out what is actually being done packet wise. For the nullroute, it's "ip -6 ro add 2001:14b8:147::/48 dev lo" of course.

Default route vs 2000::/3 on Linux

Shadow Hawkins on Tuesday, 20 March 2007 21:05:32

For some strange reason, the default route started working even for forwarding when I removed it (the one created by aiccu initially when I started the tunnel a week ago) and recreated it manually again. So this isn't an issue anymore. Although it still seems strange, I'm not really able to debug it further at the moment. Got the nullroute added now, too. Thanks! // Martin

Default route vs 2000::/3 on Linux

Shadow Hawkins on Friday, 27 April 2007 17:49:47

I just upgraded to linux 2.6.21, and had to add the 2000::/3 to be able to acces anything behind SixXS PoP... Looks like regression |:(

Default route vs 2000::/3 on Linux

Carmen Sandiego on Thursday, 07 June 2007 19:30:50

Here is a question for the folks that have no doubt thought about much longer than I have. Is using ::/0 as the "catch all" CIDR route really desirable in IPV6? Are any of the unicast addresses that aren't in 2000::/3 going to go anywhere anyway? It looked to me like the only valid "global" addresses were in the 2000::/3 range. It seems like it might be useful to have the local machine send the ICMP instead of passing it up to some router with a full routing table and wait for it to tell one the bad news. BTW. I just upgraded to fedora 7 which uses 2.6.21 by default. In general ipv6 things seem to be working better. (Under FC6, the Fedora ifup shell scripts for sitN tunnel interfaces didn't work at boot time. That is fixed now.) -wolfgang

Default route vs 2000::/3 on Linux

Carmen Sandiego on Thursday, 07 June 2007 01:55:03

Same here on 2.6.21.3... And here I was thinking the 2.6 line has finally gone stable.

Please note Posting is only allowed when you are logged in.