IPv6: here already?

With the phenomenal recent growth of the internet, the 32-bit IP address space (IPv4) is starting to run out. There are efforts to address this, like subdividing or repossessing large blocks already in use, or the ubiquitous use of NATs, but they're only slowing the inevitable. The IPv6 standard has been around since circa 1996, and it has recently started to get more visible traction: all major operating systems (Windows XP/Vista, Linux, and OSX) support IPv6 natively, there exist IPv6 networks that you can access via dedicated tunnels ("tunnel brokers"), and there are rumors that some companies use IPv6 internally. Some ISPs (like Sonic.net) even provide such dedicated IPv6 tunnels for free, in an effort to encourage experimentation. Although no major ISP has yet migrated to IPv6, I believe it's only a matter of time.

Discussing the in-depth technical aspects of IPv6 is much beyond the scope of this blog post, though I do encourage the adventurous reader to take a look at some of the resources linked above. Instead, this is more of a high-level overview for how to get IPv6 up and running on your home LAN. I recommend using the excellent DD-WRT firmware's IPv6 support, upon which this post is roughly based.

IPv4 addresses are 32 bit in size, which gives us a total of 4 billion different addresses. The effective number of machines that can be accessed in practice is smaller (since many addresses were given out in "blocks" to institutions that don't use the entire block), but it still gives an idea about the upper-bound. In contrast, IPv6 addresses are 128 bit in size. This is an enormously large number, and it's hard to provide a good metaphor for how large it really is. IPv6 would allocate a trillion IPv6 addresses for each square centimeter of our planet, or over 1 trillion trillion addresses for each of the 6.5 billion people currently on the planet. Hopefully, this should be enough for the foreseeable future.

The internet at large is still IPv4, but you can configure your internal LAN (behind your NAT'ed router) to run over IPv6. All the machines on the LAN would talk amongst themselves using IPv6. However, the router is still connected to an IPv4 network (your ISP). Therefore, the LAN traffic must have a way to travel across IPv4 to its destination, regardless if the destination is an IPv4 or an IPv6 network. This is done in one of two major ways:

1. Use 6to4

This is a protocol which assigns each IPv4 address a special IPv6 equivalent (which, by convention, always starts with the prefix "2002:"). Your router would package all IPv6 packets, regardless of destination, into IPv4 equivalents, and send them to a relay gateway. This relay gateway is a machine that sits at the edge between an IPv4 and an IPv6 network, and looks at the destination address of incoming traffic:

• If the address is an IPv6 address on the relay's IPv6 network, it routes it using IPv6 routing.
• If the address is an IPv6 address on another IPv6 network, it packages it into an IPv4 packet, sends it over IPv4 to the relay gateway of the destination IPv6 network, which unpacks it, and routes it.
• If the address is a 6to4 IPv6 address (corresponding to an IPv4 address), it unpacks it, sends the traffic over the IPv4 network, collects the response, and sends it back to your router.
  

Confused? Here's a diagram:

One risk with the 6to4 protocol is that the nearest relay gateway may be far away, which negatively impacts performance. If you're careful, you can select a 6to4 relay that's reasonably close to you, and you should be fine.

2. Use a tunnel broker

A tunnel broker is a dedicated link from your router's gateway to an IPv6 gateway. This makes life a lot simpler for your router: all it has to do is take IPv6 packets from the LAN, package them as IPv4, and push them into the tunnel. Provided that the tunnel isn't too slow (that is, too far away), the tunnel 's end-point will do all the hard work of routing IPv6 and IPv4 packets correctly. Here is a diagram that describes the process visually (note that the Tunnel Server can either directly route over IPv6, or ask the Tunnel Broker to route over IPv4; your LAN uses only a single IPv6 tunnel to connect to the Tunnel Server).

Some tunnels require that your router have a static address, while others can handle dynamic addresses (via the AICCU utility). The two big IPv6 tunnel providers in the US are SixXS and Hurricane Electric.

If you succeed in setting up IPv6 on your LAN, you can connect to this site, and watch the turtle dance!

"All this work to see a silly turtle dance on the screen?" I hear you ask?

Although the IPv6 internet is significantly smaller than the IPv4 at this point, this might be a good exercise for you to learn how IPv6 works. All indications are that we will migrate to IPv6 before too long, so consider this a way to get your feet wet. There is no downside to running your LAN over IPv6, your operating system, as well as most modern browsers (Firefox, IE, etc.) and network applications (Thunderbird, etc.) natively support IPv6. The performance penalty for running using tunnels should not be prohibitive, and most DNS servers know to serve both IPv4 and IPv6 addresses for multi-homed servers, to make the accessible from both networks. IPv6 is, in some ways, much simpler and more elegant than IPv4, so for those curious to learn more, this is a great opportunity to look under the covers.

QuickCam Pro 9000: Skype in HD

Many friends and family members live abroad or just plain far away. In order to keep in touch, I frequently use Skype, and in the past few years or so, Skype Video. I was initially hooked by Skype's amazing voice quality (and the fact that it was free!), but Skype Video adds a whole new dimension to everything. Bandwidth speeds have gotten good enough (even across entire oceans and continents) that it's now feasible to have a full-screen Skype Video conference call and literally "hang out". For me personally, this must be one of the biggest and most profound changes that technology brought about in the past few years.

Up until recently, I've been using a Creative WebCam Live! for video calls. The camera does a pretty decent job, but it has two important shortcomings: the images are a bit darker than I'd like, and its field of view is narrow enough that it has difficulty fitting more than one person, or even capturing what I'm doing unless I sit pretty still. So I decided a few weeks ago to look for a webcam with a wide-angle lens. The two main contenders appear to be Creative Live! Cam Optia Pro and Logitech's QuickCam Pro 9000.

The reviews for the Optia are pretty mixed, and echoed some of the same issues I'd had with the current Live! model. In contrast, the QuickCam model not only has a wider field of view, but it also has an exceptional Zeiss lens, and a very good reputation in on-line reviews. Both cameras are labeled as "HD-quality" (probably to capitalize on the HD buzz that's going around). Off the bat, I'd actually consider this a bad thing since it puts considerably more strain on internet bandwidth, but I figured that there might be a software setting to dial it down if the video conference starts to stutter. The QuickCam is a bit more expensive than the Optia, but with some luck (a timely Amazon rebate), it came out cheaper, so I went for it.

Upon installation, the camera behaves very well. The image quality is very crisp (Zeiss never disappoints), the angle is nice and wide (it's able to easily fit 2 or 3 people in the picture). But the most amazing feature is Logitech's "RightLight 2" technology, which makes images far brighter and easier on the eye. In almost all light conditions (natural, halogen, evening, etc.) the camera delivers stunning, well-balanced images automatically. If you've ever had problems with webcams in low-light conditions before, you really owe it to yourself to try this camera, it "just works". The built-in microphone is a nice touch, it removed one more wire and device off my desk, and the noise and echo-canceling technology is very good as well.

When it comes to Skype, the camera's drivers auto-detect Skype and auto-configure it to use the webcam as its video and audio source (a nice touch). Unfortunately, the default software that comes on the CD is incredibly buggy, it crashes Skype reliably, and is very hard to get right. After an hour of frustration, I found an updated version of the software on-line that is far more stable and works as intended with Skype. One remaining mildly annoying tid-bit is that right after you start a video call, the camera occasionally "resets" a few seconds into the call (which really means that it skips about a second's worth of video), but after that it's solid.

Although the camera is HD, Skype doesn't miss a beat: the video calls are crisp, clear, and clearly feel more like "high-definition" than with the previous webcam. I imagine that Skype probably automatically dials down the video quality to keep up with network traffic, but if the bandwidth is there, it will use it, and what a difference it makes!

All in all, I'm very happy with this camera, and I highly recommend it, it will make video calls feel that much more real and enjoyable.

QoS with DD-WRT

More and more of my life has been going digital, anywhere from pictures, to e-mail, music, etc. A large chunk of this content is stored on my PC, so there is a very real risk of losing it all in a serious crash. To mitigate this, I recently decided to go with an on-line backup service. Besides convenience, this has the essential advantage that it's located in a different state, so if our house were to fall in the ocean, the data has a better chance of surviving.

A downside of on-line backup services is that they want to suck-up all available bandwidth, so they slow down the entire home network. There are some settings for throttling bandwidth in the backup client itself, but they're primitive and plain don't work that well. It'd be a lot nicer if the router simply did the throttling for me, depending on what the other machines on the LAN are doing. This is what QoS is all-about.

Some time ago I read an excellent article on hacking open-source routers, so I decided to buy a WRT54GL. It turns out that flashing this router with the DD-WRT firmware gives it excellent QoS facilities, far better than what the native firmware can do. Installing the DD-WRT firmware requires some care, but is not difficult. There's something very satisfying about rebooting the router and getting a detailed status page with CPU load averages, and being able to SSH into the router to poke around the file system.

Setting up QoS correctly turns out to be trickier than it seems. First, you have to estimate the uplink and downlink bandwidth that your ISP provides, and tell the router 85% of each. The underlying assumption is that your bandwidth is fairly constant, but the router has to be able to handle spikes, so the 85% gives it a cushion. Since I use DSL, my bandwidth is pretty stable, but for cable customers (where bandwidth is shared by all people in your neighborhood), I imagine that's less likely to be true, so your mileage may vary here.

After this, you have the option to boost the priority of certain traffic sources, and lower the priority of other sources. A traffic source can be:

• A particular application, communicating on a particular port
• One or more specific IPs (or IP masks) on the LAN
• One or more specific MACs on the LAN
• One or more specific ethernet ports on the router

I decided to go for the first option, which in my opinion is the most flexible given my network setup. My on-line backup client uses a well-known fixed port, so it was easy to tell the router to downgrade all traffic on that port to "Bulk" status. This means that if any other traffic source wants to use the network, the "Bulk" sources are throttled all the way down to zero. This by itself works pretty well, but we can do better by marking other traffic sources as "Standard" or "Express" in order to boost their priority. Natural candidates for boosting are HTTP, Skype, IMAP, etc.

At first sight, it might seem that HTTP traffic can be simply identified as all traffic on port 80. This isn't quite true, given that many websites decide to serve static content off other ports, and it also doesn't handle HTTPS traffic. Fortunately, DD-WRT supports the L7 filter, which attempts to classify the type of traffic by inspecting the packets themselves (for example, this is the L7 pattern that classifies HTTP traffic). This does take a performance penalty since all packets have to be inspected, but is easy, reliable, and headache-free, so I gave it a shot.

Once everything was configured and running, I was pleased to see that it works well: when the network was quiet, my backup software was running at close to full-speed. As soon as I started to use the network (for example, watch an on-line video), the router magically throttled the backup traffic down to almost zero, and my browsing was unimpaired. When I stopped browsing, the backup traffic came back to using almost all the bandwidth.

The only downside is that, between estimating the maximum bandwidth above, and the performance toll of the L7 filter, this does exact around 15-20% penalty on the overall traffic coming in and out of the network. My DSL service currently has about 2.5 MB up, and 450 KB down. With QoS enabled, I'm seeing around 2.1 MB up and around 360 KB down. This is enough for my needs for now, but I will have to see how it holds up over time.