Installing

I again used the openwrt modules, openvpn has its own package. There are, however, several dependencies:

• libssl.so.0.9.8 and libcrypto.so.0.9.8 from libopenssl
• liblzo2.so.2.0.0 (and symlinks) from liblzo

I already had libcrypto installed, so I only needed 713kB of free space.

Configuring

Setup was fairly straightforward. Just make sure to do all heavy calculations on your desktop computer (i.e. generating keys). I installed the CA and host certificate into /jffs/etc/ssl, and added my openvpn-specific config files into /jffs/etc/openvpn. I did rewrite the verify-cn script from perl to bash, since dd-wrt doesn’t come with perl.

Next, I wrote a very simple wanup script to get openvpn (re)started at the appropriate time:

# openvpn.wanup
if [ -e /tmp/openvpn.pid ] ; then
    kill -HUP `cat /tmp/openvpn.pid`
else
    /jffs/sbin/openvpn --cd /jffs/etc/openvpn --config server.conf --daemon --log /tmp/openvpn.log --writepid /tmp/openvpn.pid
fi

Obviously: don’t forget to add the corresponding configuration to the firewall.

Since we currently already have an OpenVPN tunnel, I preferred to stay with OpenVPN rather than switch to a different stack. Turns out OpenVPN supports IPv6, but under a series of assumptions. Among others, you need OpenVPN 2.3 on both the client and the server to be able to use the new config directives such as route-ipv6. At this moment, 2.3 is still beta. While I enjoy beta-software on a daily basis, rolling it out as a production VPN seems a bit to risky.

To provide maximal compatibility, I decided to stay with OpenVPN 2.2 and use the tap-interface. I wrote my own up-scripts to take care of the required IPv6 configuration steps.

Communicating the parameters

OpenVPN has a setenv config directive, which sets additional environment variables for the up-script. Its brother setenv-safe (which prefixes all variables with OPENVPN_) can also be pushed from server to client, allowing arbitrary parameters to be communicated from server to client. I use these three:

push "setenv-safe IP6_PREFIX 2001:db8:0:1::/64"
push "setenv-safe IP6_GW 2001:db8:0:1::1"
push "setenv-safe IP6_ROUTES '2001:db8:0:0::/48 2001:db8:1234::/48'"

Configuring the client

The client now has all the information it needs to enable IPv6 on the tunnel-connection. It just needs to apply that knowledge. I wrote some very basic shell scripts to accomplish this. Basically, the script looks for the MAC-address of the (virtual) VPN interface, which it uses to form a SLAAC address together with the supplied prefix. At this moment, it does not check for duplicate IP addressing. Next, it configures the calculated IP onto the interface and adds the supplied routes to the routing table.

For those interested, I provide, without any warranty <insert legalese disclamer here>

• The MacOSX version, written in bash
• The Linux version, written in bash
• The Windows version, a batch-file and powershell hacked together

For the most part, this major changeover happened without as much of a hitch. In fact, if I hadn’t known it was World IPv6 day, I wouldn’t have noticed anything. But I’m not a normal web-user, so I did notice some issues.

Where it did went wrong

After some troubleshooting, they all boiled down to a single cause of oversight. They were not bugs or issues with IPv6 per se, just some “expected behavior” that we didn’t anticipate: IPv4-only VPNs.

Most servers in our datacenter are not publicly accessible; none of them are manageable over the public internet. In order to connect to them, you need a VPN connection. This serves multiple purposes: it secures all communication between client and server (so even plain-text http can be used securely to manage servers), it limits the number of users with access and most importantly (in the IPv4 world) it allows us to use RFC1918 addresses internally and still get the routing to work out. Technically it behaves an an extra (virtual) network card with a (virtual) cable connected straight to the datacenter. Additionally, some routes are configured automatically on the client to make sure traffic to the servers is sent over this “cable”.

We use two kinds of VPN-connections, but none of them was IPv6 enabled (i.e. could carry IPv6 data through the tunnel). Since by default client software prefers IPv6 connections, this caused the IPv6-internet connection to be preferred above the IPv4-VPN connection. Obviously, the firewall at the datacenter didn’t agree and refused access.

The solution was fairly obvious to state (enable IPv6 through the tunnels) but difficult to implement. In fact, I have not been able to get it to work well enough to install it on someone else’s computer.

The attempts

IPsec in transport mode

The “natural” solution would be to secure the IPv6 packets with IPsec, preferably in transport mode, between the client and the firewall. Since there are no NAT-issues, tunnel mode is not required.

However, I was not able to get this to work, even in manual keying mode (i.e. without ISAKMP). I couldn’t get setkey to accept the src-dst parameter in the SPD:

# setkey -c
spdadd 2001:db8:0:1::1 2001:db8:1:1::3 any -P fwd ipsec esp/transport/2001:db8:1:0:2-2001:db8:1:1::3/require;
^D
# setkey -DP
2001:db8:0:1::1[any] 2001:db8:1:1::3[any] any
 fwd prio def ipsec
 esp/transport//require
 created: Jun 14 12:13:53 2011  lastused:                    
 lifetime: 0(s) validtime: 0(s)
 spid=1641 seq=1 pid=10485
 refcnt=1

This seems to be a Linux issue (Ubuntu 10.04 LTS with kernel 2.6.32-28-generic and ipsec-tools 0.7.1), since this does work on MacOSX (10.6.7).

IPsec tunnel mode

Since I’m not entirely sure that what I tried above (transport mode) is even supposed to work, I also tried tunnel mode. This worked, but is a pain to configure. I only tried manual keying, but using racoon to do username/password authentication will be even harder to explain to users…

The Mac built-in VPN client only supports “Cisco IPsec“. This uses the mode configuration stage to communicate the set of “networks” to tunnel (i.e. the SPD). However, according to racoon.conf man-page, I can only push IPv4 networks in the split_network directive.

OpenVPN with tun driver

According to the OpenVPN FAQ, IPv6 is only supported if the underlying TUN-driver supports it. The tuntaposx-page does not mention IPv6 at all and hasn’t been updated for almost 2 years, so this seems unlikely to work.

Also, OpenVPN does not provide configuration directives to push IPv6 routes over from server to client.

OpenVPN with tap driver

Even when using the TAP-driver and router advertisements, MacOSX does not seem to like enabling IPv6… Even after manually enabling it, MacOSX still doesn’t pick up its SLAAC address:

# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 7e:95:80:00:90:0e
 inet 192.0.2.10 netmask 0xffffff00 broadcast 10.90.9.255
 open (pid 3847)

# ip6config start-v6 tap0
Starting IPv6 on tap0.

# sleep 60 # Wait for Router advertisement to show up

# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 7e:95:80:00:90:0e
 inet 192.0.2.10 netmask 0xffffff00 broadcast 10.90.9.255
 inet6 fe80::7c95:80ff:fe00:900e%tap0 prefixlen 64 tentative scopeid 0xa
 open (pid 3847)

And this still doesn’t allow me to push IPv6 routes to the clients upon connecting.

The conclusion

IPv6 is very stable and capable, but there are certain network-issues where there is still some work to do. If you happen to know a VPN-solution which supports IPv6 and works on Windows, linux and Mac, please let me know!

Edit: I worked out my own solution.

So I wanted my own router to establish the PPPoE connection and obtain a public IPv4 address. It seems that even here the default setup of the b-box2 is good: PPPoE passthrough is enabled by default. This technique allows you to establish a PPPoE connection from the “LAN”-side of the router, effectively bypassing it. There are numerous posts how to reconfigure the b-box into RFC 1483 bridge-mode, but this is not required! So just plugging in my router and configuring PPPoE on it was enough!

There are some finishing touches however that can be learned from the bridge-posts:

• I disabled my PPPoE connection on the b-box itself. I will not be using it, so there is no need to waste a public IPv4 address here.
  In the webinterface (http://192.168.1.1/ by default) go to Advanced Settings – Network Interfaces. Open the Wan PPPoE and Disable it, confirm by clicking OK.
• I also disabled the built-in WiFi access point, since I have my own 802.11n access point right next to it. This is even officially documented.
  Advanced Settings – Wireless and click Deactivate.

So I wrote a very simple perl-script that automates this for me. It behaves like cat, but inserts empty lines between input lines proportional to the amount of time between them. The numbers of lines inserted in logarithmically proportional to the elapsed time: one line for the first second, a second line for the next two seconds, a third line for the next 4 seconds, …

$ tail -f /var/log/mail.log | logtail.pl | sed 's/ .*//'
2011-03-09T10:33:02+01:00
2011-03-09T10:33:02+01:00
2011-03-09T10:33:02+01:00
2011-03-09T10:33:02+01:00
 
 
 
 
2011-03-09T10:33:36+01:00
2011-03-09T10:33:36+01:00
2011-03-09T10:33:36+01:00
 
 
 
 
2011-03-09T10:34:01+01:00
2011-03-09T10:34:01+01:00
 
 
 
 
 
2011-03-09T10:34:36+01:00
2011-03-09T10:34:36+01:00
2011-03-09T10:34:36+01:00
 
 
 
2011-03-09T10:34:48+01:00
2011-03-09T10:34:48+01:00
2011-03-09T10:34:48+01:00

I chose to leave smtpd_client_restrictions, smtpd_helo_restrictions and smtpd_sender_restrictions blank and do all the checks in smtpd_recipient_restrictions. While it’s possible to reject messages earlier, this setup gives more info in the logs for rejected messages. These are the filters that I apply.

First, the local originated mail is allowed:

• permit_mynetworks: Allow local originated mail

Mail servers introduce themselves with their hostname. RFC 5321 requires that all hostnames are fully qualified.

• reject_non_fqdn_hostname: Non fully qualified hostnames names are rejected.
• reject_invalid_hostname: Hostnames which have an invalid syntax are rejected as well.

The next phase in the SMTP conversation is identifying the sender. SMTP has an “envelope sender”. This is the address where bounces are returned to. Usually, this is the same as the “From” field, but this is not required. If my mailserver is to accept responsibility to deliver the mail, it should have a way to contact the sender. If the sender address is not usable, we can’t bounce if needed. Don’t accept responsibility in this case.

• reject_non_fqdn_sender
• reject_unknown_sender_domain

The same applies for the recipients:

• reject_non_fqdn_recipient
• reject_unknown_recipient_domain

The next statement is very important: don’t become an open relay. Only accept mail for the domains you’re actually responsible for:

• reject_unauth_destination

The previous tests were local and fast. The mail-server can verify them with minimal effort. But this is not enough to fight spam. Greylisting in particular is very effective. Greylisting will cause every mail to be initially rejected with a temporary failure. RFC 5321 requires sending mail-servers to retry this delivery. On a second attempt, the message is accepted.

• check_policy_service inet:127.0.0.1:10023: The greylisting server listens on this port and keeps the database of seen mails

SPF is another anti-spam technique. This verifies that the sending mail-server is actually allowed to send mail from this email-address. However, this causes problems with standard forwarding of emails, so I don’t use it to reject messages, but I do log the result

• warn_if_reject, check_policy_service unix:private/policy-spf

As a final test, several blacklists are checked. If the sending mail-server is listed as a known spammer, the mail is rejected.

• reject_rbl_client bl.spamcop.net
• reject_rbl_client sbl-xbl.spamhaus.org
• reject_rbl_client dnsbl.sorbs.net

All previous configuration will either accept the mail for delivery, or reject the mail. It will not silently drop mail, which is a very important thing in my opinion. If you really want to, you can chain spamassassin to the end.

In this post, I’ll explain how to set up an IPsec (without L2TP) tunnel endpoint on an Ubuntu server, capable of handling an iPhone/iPad/iPod/iWhatever. The users will be authenticated against an LDAP directory.

Packages

IPsec usually consists of two parts: the IPsec layer itself and the IKE layer on top. IPsec itself is usually implemented in the kernel. It handles all encryption, decryption and authentication of the packets, based on the set of security policies (SP) and security associations (SA). Since you usually don’t want to setup these SA’s and SD’s yourself, Internet Key Exchange (IKE) comes into play. IKE is usually implemented in user space. In this post, I’ll be describing racoon.

The standard Ubuntu racoon package does not have LDAP support compiled in. So I pulled in the source, changed the ./configure line to include –with-libldap and rebuild the package. Since I have no experience whatsoever with packaging, I will have made more mistakes that you can dream off.

Racoon configuration

The racoon.conf file has different sections, each with their own purpose. The listen group specifies the IP’s to bind on. By default racoon listens on any IP. The path directives tell racoon where to find its other configuration files.

listen {
 isakmp 192.0.2.1 [500];
 isakmp_natt 192.0.2.1 [4500];
}
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

Next up is a remote section, specifying the phase 1 settings. Normal IPsec tunnels are point-to-point. You can configure the tunnel statically on both ends. Here we are setting up a roaming tunnel: we don’t know where the client is. This has some implications:

• the server can never initiate the connection (since the IP of the client(s) are unknown)
• The client’s tunnel-IP needs to be assigned from the server. This minimizes client-side configuration
• The client must authenticate itself using a username/password combo.

remote anonymous { # Do not filter on source IP, anyone can connect to this tunnel
 passive on; # Don't initiate, only listen
 exchange_mode main,aggressive; # Accept both modes
 my_identifier fqdn "vpn.example.net"; # Identify ourselves with this name
 mode_cfg on; # configure the client's IP address using mode configuration
 verify_cert off; # Don't check client certificate
 ike_frag on; # Announce IKE-fragmentation support
 generate_policy on; # automatically install SPD's
 nat_traversal on; # Support NAT traversal
 dpd_delay 20; # Disconnect dead clients after 20 seconds
 proposal { # Phase 1 parameters
  encryption_algorithm aes;
  hash_algorithm sha1;
  authentication_method xauth_psk_server; # Require PreSharedKey group authentication and username/password user authentication
  dh_group 2;
 }
}

Next section is the mode configuration. This is sometimes called phase 1.5, because it happens between phase 1 and phase 2. In this step, the client is authenticated.

mode_cfg {
 auth_source ldap; # Authenticate against LDAP
 save_passwd on; # Allow users to save passwords

 group_source ldap; # Verify group membership in LDAP
 auth_groups "ipsec vpn";  # Require users to be member of this group in order to connect

 network4 10.0.0.0;  # Give clients addresses starting from this address
 pool_size 255;  # up to 255 addresses higher

 split_network include 10.1.0.0/16; # split tunneling, only tunnel traffic to these subnets
}

ldapcfg {
 host "ldap.example.net";
 base "dc=example,dc=net";
 subtree on;
 bind_dn ""; # Anonymous simple bind
 bind_pw "";
 attr_user "uid";  # Searches for (<attr_user>=<userid>)
 attr_group "cn";  # Searches for (&(<attr_group>=<groupname>)(<attr_member>=<userid>))
 attr_member "member";
}

The sainfo section specifies the parameters to use for phase 2, the actual data-encryption:

sainfo anonymous {
 encryption_algorithm aes;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
}

Next, you need to add the group-name and the group password to the psk.txt file:

iOStunnel     $ecr3tPassW0rd

iPhone configuration

The iPhone is set up fairly easily: Under Settings -> General -> Network -> VPN, you need to Add VPN Configuration:

• Select a (Cisco) IPsec tunnel
• The Description can be whatever you want
• Server should be the FQDN of your server, this is checked against the my_identifier in the server config
• Account and Password are the credentials of the user in the LDAP database
• Group Name and Secret are the group credentials as specified in the psk.txt file

Installing

I again used the openwrt modules, nsupdate is contained within bind-client. There are, however, several dependencies:

• libbind9.so.40.0.3, libdns.so.43.0.0, libisc.so.41.1.0, libisccc.so.40.0.0, libisccfg.so.40.0.3, liblwres.so.40.0.0 (and symlinks) from bind-libs
• libcrypto.so.0.9.8 from libopenssl

These are some serious libraries, takeing up 2.7MB of free space…

Configuring

I tried to use SIG(0), but that failed. nsupdate complains about a missing symbol ‘flockfile’. So I settled for TSIG authentication. Since this is a post about dd-wrt, I’ll assume the sever is already set up and tested (this will guide you through if it’s not), so I’ll go straight to the config files:

/jffs/etc/ddns.key:

fqdn.of.key. 0huPr3nqFnxUETlrM/VxGg==

/jffs/etc/config/ddns-update.wanup:

#!/bin/sh

# wanup scripts seem to run without LD_LIBRARY_PATH set
export LD_LIBRARY_PATH='/lib:/usr/lib:/jffs/lib:/jffs/usr/lib:/jffs/usr/local/lib:/mmc/lib:/mmc/usr/lib:/opt/lib:/opt/usr/lib'

# wanup scripts have the IPLOCAL variable set, but cron does not
if [ -z "$IPLOCAL" ]; then
 IPLOCAL=`ip addr sh dev ppp0 | grep 'inet ' | cut '-d ' -f6`
fi

sleep 30 # wait for IPv6, DNS, … to stabilize

echo -e "server ddns.master.server.fqdn\nkey `cat /jffs/etc/ddns.key`\n
update delete fqdn.to.set A\nupdate delete fqdn.te.set TXT\n
update add fqdn.to.set 300 A $IPLOCAL\nupdate add fqdn.to.set 300 TXT `date "+%Y-%m-%d_%H:%M:%S"`\n
send" | /jffs/bin/nsupdate

I cut that last echo-line into pieces for readability, make sure that it’s one single line (from echo all the way to nsupdate).

I added the following line to the Additional cron jobs on the webinterface. Contrary to the dd-wrt wiki page, /jffs/etc/crontab does not seem to work. This will run the ddns-update script every hour, at 5 minutes past the hour:

5 * * * *  root  /jffs/etc/config/ddns-update.wanup

Kernel support

Unfortunately, I couldn’t use the OpenWRT kamikaze 8.09.2 kernel modules, since they’re build for a different kernel. My previous post explains how I compiled the modules myself. I stripped and installed:

• ipv6.ko : the main IPv6 module
• sit.ko : IPv6-in-IPv4 tunneling, for Sixxs support
• ip6_tables.ko : IPv6 firewalling, main module
• ip6table_filter.ko : IPv6 firewalling, filtering module
• nf_conntrack_ipv6.ko : Connection tracking for IPv6
• ip6t_REJECT.ko : Reject target for ip6tables
• Additional matching modules: ip6t_frag.ko, ip6t_hbh.ko, ip6t_hl.ko, ip6t_ipv6header.ko, ip6t_rt.ko

Radvd

radvd is responsible for communicating the presence of a router. Hosts can automatically configure an IPv6 address in the correct range and know what gateway to use to the rest of the world. I simply used the radvd binary that shipped with the big build of dd-wrt and dropped that in to /jffs/sbin/.

The configuration file looks like this: /jffs/etc/radvd.conf

interface br0 {
    AdvSendAdvert on;
    MaxRtrAdvInterval 600;
    AdvManagedFlag off;
    AdvOtherConfigFlag off;
    prefix 2001:db8:0:0::/64 {
        AdvAutonomous on;
        AdvValidLifetime 604800;
        AdvPreferredLifetime 86400;
    };
};
interface br1 {
    AdvSendAdvert on;
    MaxRtrAdvInterval 600;
    AdvManagedFlag off;
    AdvOtherConfigFlag off;
    prefix 2001:db8:0:1::/64 {
        AdvAutonomous on;
        AdvValidLifetime 604800;
        AdvPreferredLifetime 86400;
    };
};

Obviously, put your own prefixes in there!

Ip6tables

Since I like to keep my setup as lean as possible, I choose not to use ipkg and only copy the files that are actually used by dd-wrt; ipkg also installs the scripts that OpenWRT uses. Hence, I needed to manually keep track of the dependencies. To get ip6tables working, I installed:

• ip6tables binary from the ip6tables-utils package
• all libip6t_* libraries from the ip6tables-utils package
• the libxt_* libraries from the iptables package
• libxt_state.so from the iptables-mod-conntrack package

Debugging tools

I also installed ping6 (from iputils-ping6) and traceroute6 (from traceroute6) to aid in debugging IPv6 connectivity.

Aiccu

To get a working Sixxs tunnel, they provide a small tool called AICCU. This tool automatically configures the tunnel and keeps it alive. I just used the aiccu binary from the aiccu package.

I use a fairly basic configuration file: aiccu.conf

username <your nichandle/username>/Txxxxx
password <your password>
protocol tsp
tunnel_id Txxxxx
server tic.sixxs.net
ipv6_interface sit_sixxs
daemonize true
automatic true
requiretls false

I use a standard IPv6-in-IPv4 (SIT) tunnel, so I added a corresponding hole in my firewall:

iptables -A INPUT -p 41 -j ACCEPT

Setup

To get this all up and running, I added a few script in /jffs/etc/config: ipv6.startup (run at bootup):

insmod /jffs/kmods/ipv6.ko
insmod /jffs/kmods/sit.ko
insmod /jffs/kmods/ip6_tables.ko
insmod /jffs/kmods/ip6table_filter.ko
insmod /jffs/kmods/nf_conntrack_ipv6.ko

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

ip -6 addr add 2001:db8:0:0:0011:22ff:fe33:4455/64 dev br0
ip -6 addr add 2001:db8:0:1:0011:22ff:fe33:4456/64 dev br1

/jffs/sbin/radvd -C /jffs/etc/radvd.conf

and ipv6.wanup (run after the WAN and firewall are up):

ntpclient europe.pool.ntp.org   # aiccu requires a correct clock, so make sure our clock is set
/jffs/sbin/aiccu start /jffs/etc/aiccu.conf

As a finishing touch, I added my IPv6 address in DNS.

Firewall

Since IPv6 does not offer the automatic traffic blocking that NAT does, an IPv6 firewall is a must. Here is my very basic script, which I put in firewall.wanup

ip6tables -F INPUT
ip6tables -F FORWARD
ip6tables -X

ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A INPUT -i br0 -j ACCEPT
ip6tables -A INPUT -i br1 -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
ip6tables -P INPUT DROP

ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A FORWARD -i br0 -j ACCEPT
ip6tables -A FORWARD -i br1 -o sit_sixxs -j ACCEPT
ip6tables -P FORWARD DROP

Since you can’t run a complete build environment on the router itself, you’ll have to set up a cross-compiling environment on your own machine. As I found out, this isn’t always very easy to do…

Since there are some requirements on the development host (64bit host, case-sensitive filesystem), I used a clean Ubuntu-64bit 10.04 install in a virtual machine.

Preparations

Start by getting the sources for the 2.6.24.111 kernel:

# svn checkout svn://svn.dd-wrt.com/DD-WRT/src/linux/brcm/linux-2.6.23 -r 14929
# head -n5 linux-2.6.23/Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 24
EXTRAVERSION = .111
NAME = Arr Matey! A Hairy Bilge Rat!

See, I told you it’s 2.6.24.111!

Next we’ll get the cross-compiling toolchain:

# cd /opt
# wget http://www.dd-wrt.com/dd-wrtv2/downloads/others/sourcecode/toolchains/current-toolchains.tar.bz2
# tar jxvf current-toolchains.tar.bz2

Configuring the kernel

First some cleanup to do: I don’t need the madwifi drivers, so I remove their reference. The config.h file is a broken softlink, so I remove that as well. For some reason, jhash2.h is not included (presumably because jhash.h is included first). This causes JHASH_GOLDEN_RATIO not to be defined. There are probably nicer ways to solve this, but I just redefine the constant outside of the #ifndef‘s

# grep -v madwifi drivers/net/wireless/Kconfig > drivers/net/wireless/Kconfig.new
# mv drivers/net/wireless/Kconfig{.new,}
#
# rm include/linux/config.h
#
# echo "#define JHASH_GOLDEN_RATIO    0x9e3779b9" >> include/linux/jhash2.h

Next configure the options you want, starting from dd-wrt’s default:

# cp .config_std .config
# make menuconfig
# PATH=$PATH:/opt/toolchain-mipsel_gcc4.1.2/bin make modules

Stripping the modules

Now just cherry-pick the modules you want. If you really want to squeeze out every last byte, you can strip each individual module:

# /opt/toolchain-mipsel_gcc4.1.2/bin/mipsel-linux-strip --strip-unneeded ipv6.ko

Then copy these modules onto your router and insmod them, probably in a script.