Slashdot Mirror

Oh, that sounds like a tough one to me. Ok, ok, it's actually not that tough - but it DOES require combining a number of kernel patches, there's no one-stop-shop (at the moment) for this. It also requires that network connections be IPv6, as there's bugger all mobility support out there for IPv4 for Linux as best as I can tell.

8:33pm up 2 days, 22:20, 1 user, load average: 0.00, 0.00, 0.00
37 processes: 35 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0.0% user, 7.0% system, 0.0% nice, 93.0% idle
Mem: 2582324K av, 353544K used, 2228780K free, 0K shrd, 82364K buff
Swap: 1073016K av, 0K used, 1073016K free 90972K cached

[root@somewhere]# ipsec eroute | wc -l
393

Dedicated Hpaq Proliant DL380 G3 server, Xeon 2.8Ghz CPU, 2+GB RAM. Multiple site-to-site tunnels up to about 130 sites across WAN links of varying speed, but mostly between 3-8Mbit/s. Handles about 1.2GB of 3DES/MD5 encrypted/authenticated traffic per day. Runs like a champ, the box barely notices the encryption overhead, it just takes a while (2-3 minutes) to rebuild all the tunnels when you restart FreeS/WAN.

Only headache is deciding which open-source VPN/ipv6 software to use now that FreeS/WAN is at end-of-life.

No no no. There is "free" for developpers and "free" for users. These are completly different things. BSD is "free" for developpers - they take the code, do whatever they want no question asked. GPL is "free" for users - they are sure to get the source code, and be able to add modifications (possibly written by third parties), and they are sure to be allowed to redistributed the code they got.

The fact that they are quibbling over something as banal as whether Linksys' code is statically linked to their code or not shows the stupidity of this license. I mean, come on -- what difference does it really make if the Linux kernel code is linked directly to it or not? It's just a few different library flags.

It makes a tremedous difference. In one case, you can take the Linux kernel, add enhancements from other parties, for instance the lastest usagi patches, recompile it, and run with binary modules. In the other case (like with non released modified BSD), you can't. The first case is the entire point of the GPL.

Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

Here's a little info . Doesn't go into specifics. Follow the links and you end up here .

They key is the "my home network" part. The router for an autonomous system would probably require full support. I'm running RH7.3 (kernel v2.4.18) and i don't see kame dancing.

OK, so I jumped the gun a bit there - there are bits still missing from the Linux IPv6 stack which make it non-compliant, such as IPSec and such. See the USAGI project. But the major points of IPv6 certainly work on Linux.

Cisco now has IPv6 in Cisco IOS 12.2T and higher:

http://www.cisco.com/warp/public/732/Tech/ipv6/ipv 6_techdoc.shtml

At least in the kernel on Red Hat 7.1, they
do not enable IPv6 by default:

% ping6 ::1
socket: Address family not supported by protocol

Does Debian enable IPv6 support in their kernel
by default?

If there was a mainline Linux distro that
supported IPv6 out of the box, that would be
one way to stir up demand for it.

Most of the Linux IPv6 work is going on in Japan, not in the U.S.:

http://www.linux-ipv6.org

The Linux IPv6 work doesn't seem to be the major focus of the core Linux kernel developers these days.

Here's one guy's experience setting up a tunnel to the 6bone with OpenBSD. By doing it this way you get a connection the IPv6 backbone and you can run IPv6 in your local network without needing IPv6 services from your ISP.

Note that KAME is for BSD. If you really want Linux, try USAGI.

For those of you who would like to implement ipv6 on your systems, there are howto's available at http://www.ipv6.org/howtos.htmlAlso check out the USAGI Project