Moving...

Well, it's been about 6 months since I last blogged. I've not had much interesting to say really, just had my head down working. Things have lightened up a bit since then, so hopefully I'll have a bit more time on my hands to order my thoughts and scribble them down. All this is going to happen at my new site, http://www.chris-read.net. See you there...

Why reading books is still important

I finally got around to reading my copy of IPv6 Network Administration and in chapter 4 there's a section that deals with transition mechanisms which covers the kinds of problems I've been trying to solve with STFL. When I was first digging around the net to see what people had done about allowing IPv6 clients to connect to IPv4 only applications, I found some elusive references to something from the KAME project called faithd. All I could find out about it at the time was that it seemed to be half implemented in user space, and half in the kernel of FreeBSD, but it seems to have been lost in the mists of time. While the book also refers to it, there is also mention of RFC 3142 which describes something called TRT, or Transport Relay Translation. I now have a proper name for what I'm trying to do! That's why reading books is still important.

The solution described in the RFC is pretty much exactly what I've been thinking of, except for the following differences:

Name Resolution

Or the way the DNS is configured for the service. The approach I've been thinking of is pretty simple - assign an IPv6 address to the service you want to offer, add an AAAA record to DNS for that service, run STFL on that IPv6 address and forward the requests to the IPv4 address and port where the application server actually runs. While RFC 3142 does allude to doing it this way, it also talks about using a custom resolver library or DNS server to automatically convert the IPv4 address into an IPv6 address (the don't mention it specifically, but I guess they're talking about 6to4 which is described in RFC 3056).

Service Granularity

My philosophy is simple. You have one application (in my personal case it's Apache 1.3 on OpenBSD) that is not IPv6 compatible but you want to serve IPv6 clients with. So all you do is spark up an application on an equivalent port on an IPv6 address and just ferry the TCP packets back and forth. If you have more than one application you want to do this for, then you simply fire up additional STFL instances. The RFC seems to suggest making an entire IPv4 address and all its TCP and UDP services available on the same IPv6 address (hence the need for mangling resolver). I guess this is why the reference implementation need a kernel level component, and is probably why it never seemed to get off the ground - that's some pretty complicated stuff you need to do!

Introducing STFL - the Six to Four Layer

It's been a long time since I last posted my ramblings on a simple way to allow legacy IPv4 services to serve IPv6 clients, but at last I have something to show for it! After playing around a bit more with my Python "proof of concept" code, I realized that while the idea was sound, implimenting it in Python may not be the best solution. The main problem I had was with the Python global interpreter lock. Even though I'd written the code using threads, it would not scale under heavy load. So, I decided to chip the layers of rust off my C skills. The result is the STFL project. It's functional, but needs polish and a bit of effort to get it working all the major Unix flavours. Currently it's only fully functional (and tested) on Linux and OpenBSD.

The easy way to IPv6 support for TCP apps

When I initially got my static IPv6 address range from my ISP, I was running Linux as my firewall and Apache 2 on Solaris x86 as my web server. This meant that getting my site available over IPv6 was pretty straight forward. All I had to do was add new A6 and AAAA records to my DNS entries, configure the static IP address on the Solaris box and add an additional Listen directive to Apache. Life was good. Not that I ever got more than 10 hits a month on my site from IPv6 addresses, but that was not the point!

Then I switched the firewall and web server over to OpenBSD. One of the main factors in me deciding to do this was the great "Tinfoil Hat" approach the OpenBSD guys have to security. Sure, you may not be able to run the latest greatest version of your favourite app, but the stuff they do ship with the core distribution has been fairly well nit-picked by some pretty bright people. This means I don't have to worry so much about the script kiddies getting in...

However, this does mean that the Apache they ship and support and have tweaked to have run in its own little chrooted sandbox is pretty old - 1.3.29 at the time of writing this. Yes, all the security patches that come from the Apache group have been applied. But it does not do IPv6. There are patches out there from the Kame guys to enable this in the 1.3 branch, but it's old, experimental, and does not do SSL. I did for a few brief minutes contemplate seeing if I could at least try crafting my own patch to get mod_ssl to work, but then sanity kicked in. I am not a hard core developer. I am a Sys Admin who knows how to code.

I then decided to step back and look at the picture from another angle. All that's different really is the IP stack. The actual TCP protocol used to do all the chatting is the same. What I really needed was something to mess with the inbound IPv6 packets, send them to the required IPv4 host, and do the opposite on replies. Trying to write some code to do this somewhere in the network stack is more scary and presents more security bugs than trying to write a mod_ssl patch. So I decided to go for the quick and easy method - write a socket app that listens on an IPv6 port, and pumps all the TCP packets down a new IPv4 connection, and do the opposite with the replies.

A few hours later I had a small (about 200 lines at the moment) Python app to do this all for me. It's also fast handles multiple ports, and is protocol indepentant. I've tested HTTP, SSL, SSH, IMAP, POP3 and SMTP with it.

I'm busy working on the final touches before releasing it, but I will anounce it here when it's ready.

Xen and the Art of Virtualization

I've installed Fedora Core 4 on one of my tinkering machines, and since it now ships with prebuilt Xen kernels I decided it was high time to give it a try. Having played with all kinds of machine virtualization from VMWare to Solaris 10 Zones to the Hypervisors on IBM pSeries servers (I'm still waiting for someone to give me time on a mainframe so I can tinker with z/VM though) I'd say I'm pretty familiar with the technology as a whole and the different approaches people take to it all.

So far I'm pretty impressed. Installation of the host (Domain0 in Xen speak) is easy as expected. Just install the supplied xen0 kernel, disable SELinux (and IPTables if you want to network it) and reboot. However, that's pretty much where the simple stuff ends. Unfortunately most of the pain and suffering I've had getting this to work has been caused by Red Hat, not Xen...

The Fedora guys have a Virtualization Quick Start page which describes what you need to do. It's pretty much accurate, except for when it comes to getting a working OS installation on your virtual disk image. The only thing I can think is that Yum has changed a bit since that document was written. After a bit of hacking I did manage to get a Fedora image booting under a virtual machine, but it was not pretty. So I decided to try a "build from almost scratch" distro I was familiar with - Gentoo.

I've run Gentoo on various machines of mine for almost 3 years now. It's fast, gives you a lot of control, but ultimately is a royal pain to maintain, especially for server environments. Installing it onto a Xen image is a dream though. It's quick, to the point, and let's you do what you want. All was going swimmingly until I tried to boot the virtual machine. It loaded the kernel (the supplied xenU kernel from Fedora) just fine, but when it came to mounting the file system, fsck.ext3 bombed with errors that there were unknown options in the filesystem metadata. It turns out that Red Hat have added an option to their e2fsprogs that allows online filesystem resizing, but this is not reflected in the version numbers they display. Luckily they are all statically linked, so I just copied the FC4 binaries over to my Gentoo partition and all is funky!

I now have a nice little playpen to install a new honeypot on. I've even got full IPv6 connectivity to it, so let's see what nastiness is spreading around the IPv6 side of the net these days...