USAGI IPv6 kernel patches are not very big for kernel v2.6. To apply them, we then get, among other things, IPv6 ipfilter stateful connection tracking, provided we also get their "userland" tools for that too. Here is the size of the latest kernel patch snapshot, uncompressed: From daily snapshot directory <URL:"ftp://ftp.linux-ipv6.org/pub/usagi/daily-snap/200405/linux26-2.6.6-rc3-usagi-20040501.patch.gz">: $ wc linux26-2.6.6-rc3-usagi-20040501.patch 11508 41589 324675 linux26-2.6.6-rc3-usagi-20040501.patch $ Only a third of a megabyte. The latest biweekly snapshot is <URL:"ftp://ftp.linux-ipv6.org:/pub/usagi/snap/kit/usagi-linux26-s20040426.tar.bz2">: -rw-r--r-- 39419242 Apr 26 14:46 usagi-linux26-s20040426.tar.bz2 if you get the above biweekly snapshot, it includes within it both a Linux 2.6 kernel source with USAGI patches applied, and their tools (they call it "userland") directory (nicely named usagi/usagi/, of all things). Also, you can get tools separately, but it's probably harder to compile them since you have to point it at Gentoo sources somehow instead; you'll see if you follow their instructions like I described below what they do with symlinks, etc. Probably to change that all you need to do is determine and test different configure options, but I do not know., Notice how small their compressed patch for Linux kernel 2.6.5 is: from <URL:"ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-linux26-s20040426-2.6.5.diff.bz2">: -rw-r--r-- 64759 Apr 26 14:53 usagi-linux26-s20040426-2.6.5.diff.bz2 $ wc usagi-linux26-s20040426-2.6.5.diff 11568 41798 326094 usagi-linux26-s20040426-2.6.5.diff $ That patch is from a pure 2.6.5 kernel. This is the patch directory you could use to patch gentoo-dev-sources with for your extras. It would be included whenever the user has IPv6 in their /etc/make.conf USE flags. E.g., you could apply the above onto your 2.6.5 (unless you're alreadying using an -rc version for your 2.6.5-r1 ebuild). Basically, it's the KAME et al group's Linux development site. While most of it makes it into 2.6 eventually, they keep fixing, updating, and in some cases including patches of things that IPv6 is supposed to have but which Linux kernel just doesn't have. For instance, and the whole reason I pursued them in the first place (I found out about them from ipfilter's development mailing list, which I downloaded an archive of), their kernel and tools have updated ipfilter code for IPv6 stateful connection tracking. Stock ip6tables and 2.6.5 kernel still don't have IPv6 stateful connection tracking. There is some statement that the implementation in USAGI kernel might be suboptimal, hackish, "cut&paste" type of work, but the main issue is that it seems to work, despite being marked "EXPERIMENTAL". Follow the INSTALL.USAGI file to install that. What I did was: 1. Apply latest patch to *my* latest kernel source (in my location, e.g., /usr/src/linux). You would apply whatever version they have which fits your version as an option in the ebuild which is taken out of ipv6 USE flag from /etc/make.conf; right now, that's their 2.6.5 patch to your 2.6.5 kernel source. 2. Turn on new options (make oldconfig, make menuconfig, etc.). I did make clean, too. Make and install new kernel. 3. Follow INSTALL.USAGI instructions, with following modifications: * After "make mrproper", cp /usr/src/linux/.config to their src tree, and make oldconfig. Compile as they described ("make"). * kernel's "make install": skip; using your own kernel source tree. you just built USAGI version of kernel out of paranoia that config files are important for next steps. Notice their big symlink structure. If you can apply this to your kernel location instead so can skip all of USAGI's tarball kernel, much better. I didn't bother; just compiled twice. * ./configure in usagi/usagi ("userland"): add option --enable-ip6tables; if you do "./configure --help|egrep -v default", you'll notice it says "(This need a linux24 source.)", but that is not true. I think that comment is outdated. * Fetch ip6tables* out of /usr/local/v6/sbin/. I think Gentoo already has most of that other stuff, so don't use theirs unless there is a good reason to. For ip6tables, there is a good reason to. * Skip include file installation. You could investigate whether include file installation helps. I skipped it because it looked imprudent to do it, and that seems ok, since they said it's ok, and warned you to not do it if you didn't have a reason to. I think it's a mystery there's no new files in /lib/iptables, and yet I tested IPv6 stateful connection tracking, and it worked. (Ask your local netfilter guru for examples of stateful connection tracking; e.g., FTP servers and clients, with both passive and active settings (e.g., lftp has those settings -- commands to get ready to watch that are "set ftp:passive-mode false" and "set ftp:passive-mode true", and "debug 9" to see the protocol work; for some reason, you have to put the big IPv6 IP# on the command line of lftp when you open, otherwise it defaults to IPv4 IP# when it's available.)) Also, please test to make certain IPv6 connection tracking works: that it allows what it should and blocks what it shouldn't. All I was able to test was the minimal level I can from my home network; I don't have remote IPv6 access anywhere where I can test those things. E.g., you could test using lftp like I described above to my ftp://DEB.Q.NET/ and play with that (right now I have IPv6 stateful connection tracking on for FTP, but I am not certain I configured it properly, and I will also work more on my ipfilter rules later). Here's their statement regarding USAGI Linux IPv6 overview, edited slightly to correct their English (this of course is from Asia, where IPv6 is probably needed first, and where they probably use their own distributions instead of Gentoo, but we need to know how to use IPv6 too here in the rest of the world, too), from <URL:"http://WWW.LINUX-IPV6.ORG/overview.html#overview">: Project Overview Currently we [the world] has an IPv6 implementation in [mainline Kernel.Org] Linux kernel source tree. Only enabling "Internet Protocol Version 6" option in the Networking section, we can enjoy IPv6 life. However, once you begin to use IPv6 on [such a mainline kernel] Linux box, you will soon be aware that the implementation have some problems... Because an existing [historically before they started doing more work on it] Linux implementation is too old and not so well-tested, it has many bugs and unimplemented functions. Then we decided to start USAGI Project(UniverSAl playGround for Ipv6 Project) with WIDE Project, KAME Project and TAHI Project. The project aim to improve IPv6 environment on Linux and deploy the IPv6 Internet on the world. We've started to hack the kernel, libraries and applications aggressively and will provide our product freely for Linux and IPv6 community. In the near future we would contribute and merge our code into the main trunks of Linux kernel and glibc. [My memory and a quick search of Google imply that a lot of USAGI code is in mainline 2.6 kernel now; e.g., an old author line states "2.5.45 IPsec support (Alexey Kuznetsov, Dave Miller, USAGI team)", and it is plain to see USAGI has been working on main 2.6 kernel with less than a minute of Google searching.] Because of the contribution for main trunks [a well known metaphor and nice way to describe main line kernel, in case somebody didn't know that], we have a policy that we don't make and accept changes which depend on Linux distributions [e.g., Gentoo]. Instead the policy, we will provide binary packages for Linux distributions on every stable release. [Which in the lovely world of Gentoo, is just not a valid concept :) Pfttftftftftf! Screw those binary distributions ... blegh I am so annoyed with Debian and Redhat mostly because of that.] Let's try out USAGI IPv6 environment with us!! Note that reading ipfilter development mailing list, they have been actively working on and off on implementing IPv6 stateful connection tracking in ipfilter code since at least 2000, if not before. The reason it keeps not getting finished is that they want to do it right, e.g., they don't want duplicate code for ipfilter from ipv4 & ipv6 trees; they want to make a common codebase, and then ust have ipv4 & ipv6 functions refer to it. I didn't read enough of the development tree and the USAGI patches to decide whether they've left the old "copy & paste port" version, but I think they have not. Meanwhile, we have what we need. However, it does mean it's going to be reimplemented. But, since 2.6 (stable kernel) is up to 2.6.5 already, we can doubt whether or not it will be ready soon; 2.7 to 2.8 and late 2.6 are our best hope for now, I think. That's why I think it is appropriate to include the above patches when IPv6 is in USE flags for gentoo-dev-sources, when gentoo-dev-sources is actually the stable 2.6 release series. I recommend this continue to be the case when "gentoo-dev-sources" gets appropriately renamed to whatever 2.6 stable version will be named, at least until 2.6 gets most of the above fixes and hacks from USAGI. Yes, they said and meant "aggressively"; that's why they include EXPERIMENTAL maybe working code that is not the intended implementation of that code, but which for now seems to work. P.S., I do not use gentoo-dev-sources; I prefer using a pure kernel source. I don't like yours since I have a hard time knowing what kinds of stuff you've put into it, like what I'm asking you to put into it in above, and knowing exactly what Portage does with those trees, and how I'm supposed to interact with it when I work on it. I am curious if your LIRC support works, since I might need that if I reconfigure my home systems. I'm very, very slowly edging towards installing gentoo-dev-sources and using it on my system. I still don't even know how to tell emerge to make a kernel.
I've since installed sys-kernel/linux-headers-2.6.5 and sys-kernel/gentoo-dev-sources-2.6.5-r1, and am still using my own version of the kernel. I've become comfortable enough with ebuild that I could even submit the patch myself for USAGI inclusion if someone has enough interest, now that I've learned that you already have USAGI as an option in other kernel sources. Please let me know if you want it for gentoo-dev-sources and/or development-sources.
Sorry, but we'er not going to add things that are "addons" to the main gentoo-dev-sources package. Feel free to submit a ebuild to build this package separatly.