URL > Average

802.11n - URL > Average

2009-12-27T22:13:47Z

802.11n is one of those things I've been meaning to get going for a while now. My laptop has a 100mbit ethernet port, but it also has an 802.11n wifi card, which means that my wireless is (potentially) faster than wired connection. One of the primary things stopping me from going N is a proper router for it all. I've owned a Soekris net4521 for several years now, and it has served me well. However, it is getting quite old quite fast, and after hearing that the net6501 will be available "soon" I decided to start purchasing the bits of hardware that I would need to get it up and running.

I purchased a D-Link DWA-556 PCI-Express card. This is a pretty standard draft-N wireless device. Once it showed up, I threw it in a computer and tried to get it to function as an access point.

It turns out that 802.11n is a bit more complicated than "standard wireless" (802.11a/b/g). Two of the biggest changes from previous wifi standards would be the addition of multiple input/output streams and the ability to operate with channels 40MHz wide, as opposed to the current 20MHz.

Now, 802.11n runs over the exact same frequencies as 802.11a/b/g. This has some pretty obvious implications on existing access points when you both double the channel width and starting using multiplexing streams on the same channel.

Probably the biggest impact to existing networks is the addition of the 40MHz wide channels. Existing 802.11b/g has 11, 13, or 14 channels depending on your region. Each channel is 22Hz wide, but are only 5MHz apart from each other. This means in every country but Japan, there are a grand total of three channels that don't overlap (1, 6, and 11 -- Japan also has 14 that does not interfere with 11). Now, strictly speaking, 802.11n doesn't have to use a 40MHz wide channel. It can sit perfectly content with a 20MHz wide channel. The obvious advantage to running in the 40MHz mode is double the bandwidth as compared to 20MHz. Twice the channel width, twice the bandwidth. The obvious disadvantage is that instead of bleeding over into 4 other channels (channel 1 bleeds over to channels 2-5) you're munching on 8 channels minimum.

To be precise, the 40MHz mode of operation uses two distinct 20MHz channels of operation in order to provide backwards compatibility with clients that are not 802.11n aware/capable. The second channel is used for clients who can use the 40MHz features only, and is placed +/- 20MHz away from the main channel. If you instructed your card to operate on channel 1 in 40MHz mode, it would also allocate channel 5 for use as well. If you selected channel 11, it would use channel 7 as well.

The obvious problem here is that we can't have any more than one 40MHz 802.11n access point in b/g spectrum without overlapping channels. If you're living in an apartment complex that is already covered with wifi, one single individual is going to be able to take up to 82% of the total spectrum by running one single access point on "one" channel.

Further, 802.11n gets a fair bit more range than 802.11b/g. While existing wireless gets about 150 feet/45 meters indoors and 300 feet/90 meters outdoors from the AP, 802.11n gets about 300/70 meters feet indoors and 250 meters/820 feet outdoors. Not only can an 802.11n signal in the b/g spectrum take 80%+ of the available spectrum, it's going to "pollute" twice the distance at a minimum.

The other big impact on existing networks is the addition of MIMO streams over a single channel. While this has less of an impact than 40MHz channels, it will still be felt, and even more so in 40MHz mode.

Multiple input/multiple output, or MIMO, multiplexes multiple streams over the same channel. This is the primary change from 802.11a/b/g, and it manifests itself as increased noise on existing connections. Much in the way that having 6 access points on the same channel in the same corner of a room degrades your ability to use even one, MIMO throws more data over the same frequency resulting in more noise -- lots more noise -- for anyone that isn't you (or is you, if you're not the one running the 802.11n access point).

Now, 802.11n supports up to four streams being multiplexed over one channel. The most advanced 802.11n hardware I can currently find maxes out at 2, which means roughly double the noise for anyone who isn't you.

Stream count is adjusted largely by the MCS index. The MCS index is a number, 0 through 31, which tells the hardware primarily ultimately what bitrate it is going to be capable of. MCS 0 has a rate of 6.5Mbit on a 20MHz channel, on up to 15Mbit with a 40MHz channel. Two streams starts at MCS 8, which provides 13Mbit at 20Mhz up through 30Mbit at 40MHz. it should be noted, however, that MCS 7 provides 65Mbit at 20Mhz and 150Mbit at 40MHz, which is still more than our aging 54Mbit, even using the standard 20MHz channels. MCS 12 is where two streams will beat out single streams, providing 78Mbit/180Mbit.

Most of the (current) higher end hardware supports MCS 0 through MCS 15. MCS 15 provides 130Mbit at 20MHz and 300Mbit at 40MHz. The maximum that 802.11n provides is MCS 31, which provides 4 streams at 260Mbit/600Mbit.

As usual, wikipedia has a great table with all of the stream count/channel width/bitrate possibilities and the relevant MCS index.

That is a lot of noise for other clients and a lot of spectrum taken. That's also a lot of potential speed, given the right circumstances.

The 5GHz frequency can solve a lot of the above issues. As mentioned, three channels is not a lot of channels, and 802.11n over the 2.4GHz band can take two of them at once. The 5GHz frequency, or 802.11a, provides 20 non-overlapping channels in the United States. This is enough for 10 802.11n access points in the same area with 0 signal overlap (11 total if you add one in the 2.4GHz range). This is much, much more acceptable. In addition, the increased transmission power that 802.11n provides alleviates the primary complaint about 802.11a: extremely limited range. While 802.11b/g provides up to 150 feet/45 meters indoors, 802.11a maxes out around 50 feet/15 meters indoors (and 100 feet/30 meters indoors, ouch!). This is primarily due to the different frequency -- 5GHz as opposed to 2.4GHz. However, the 5GHz spectrum is rarely used in general because of this.

This leaves a lot of people in a bad place with regards to 802.11n. On one hand, using any new features of 802.11n is going to muck up the 2.4GHz band very rapidly. On the other, the 5GHz band is pretty much perfect for 802.11n operation, but range limited.

The "recommended" course of action is to place standard 802.11b/g traffic in the 2.4GHz band and start operating 802.11n traffic in the 5GHz band. This provides the maximum amount of backwards compatibility with existing clients (by not changing a thing) while still using 802.11n features with newer clients in the clean part of the spectrum.

In the end, I'm not sure what I'll do. Unless the ath9k driver is buggy right now and the newegg page for the D-Link DWA-556 is lying to me, it does not support the 5GHz frequency, and hence is quite useless to me as far as 802.11n is concerned.

Oh well.

Google Chrome, and Things We Probably Should Not Do In A Browser - URL > Average

2009-07-20T05:20:42Z

While I am no huge fan of Google Chrome, at least one aspect of it has seriously impressed me - the JavaScript engine.

Over the summer, to help with the prevention of boredom, a friend and I sat down and decided to make a game. This game lives in the browser. He's writing the client (browser) side code, I'm writing the server side code.

And, like geeky college students, we are doing things that Probably Should Not Be Done In A Browser - 1024-bit RSA encryption (to the server) and signature verification (from the server). Used sparingly, this isn't a real issue... until you send status update requests to the server every second and a half, at which point it proves to be problematic. I'd imagine that this is at least partially because JavaScript has no native BigInteger implementation, which means that for a browser, you have to make one yourself... in JavaScript.

I've compared a few browsers side by side on my own machine with SunSpider, the javascript benchmarking suite. Firefox 3.5 with the JIT compiler enabled matches the Chrome engine in a lot of tests, beats it in others. Chrome, the same. It is generally a pretty equal test, with Chrome in general being a fair bit faster, but never to the point of me seeing it as a massive generational speed increase.

A bit of information:

We're using the pure JavaScript RSA and BigInteger library from ohdave.com/rsa. I make no claims to the speed of efficiency, and I have no real benchmarks of just this library, either. We searched "rsa javascript" and went with the first link we found on Google. We have not investigated optimizing this, though we probably should.
The actual requests and responses are pretty small - no more than 300 bytes after the initial data loading.
These requests occur every 1.5 seconds, but we'll likely increase that down the road.
The testing was done in a VM running a 64-bit copy Windows Vista. The VM host is an Intel i7 920 running qemu-kvm (or, it is a really fast VM, thanks to CPU virtualization extensions.).
Browsers: Firefox 3.5.1 with the JIT compiler enabled; Google Chrome 2.0.172.37; Safari 4.0.2; all under Windows Vista - all being the latest version available. (I wish I could have tested Opera too, but it has a very very strange bug involving the RSA.)
I'm going to say "99% CPU," "10% CPU," and so on. Task Manager splits the load percentage over every core on the machine, and the i7 has 8 that it detects. However, as stated, this was done in a VM, which I allocated a single CPU to. "99% CPU" is going to mean "hey this app just froze on me and took most of the OS with it."

As I said, we noticed... responsiveness issues. I went to investigate, when I realized that my copy of Firefox that wasn't within the VM was doing the same thing...

Firefox jumps from 99% CPU 'down' to 65% CPU as reported by Vista's task manager. On occasion it hit 0, but only for very brief periods of time. The RAM usage was also fun to watch: over a period of many requests, it would mostly remain stable - only to jump by 80MB or more for several seconds, and then back down. This resulted in every three out of four keystrokes being lost, on average, never mind the huge memory churn.
Safari sat there and looked at us funny.

Chrome shocked my friend and I. Sure, we had heard that it was fast, and I had done a bit of reading on it. However, I was quite surprised when I saw that it was using a maximum of 10% CPU and roughly 18MB of RAM without any spikes in either. Wow.

Talk about optimization.

While Chrome may not have another user (I quite enjoy Firefox, and having tabs on top of the URL bar really bugs me), at a bare minimum it has seriously impressed me.

A quick note on easy reverse DNS mapping - URL > Average

2009-04-09T00:29:26Z

Reverse DNS is easy. You take the address, reverse the bit sets, and then append ".in-addr.arpa." to the domain. 10.0.0.1 maps to 1.0.0.10.in-addr.arpa.

Isn't that easy?

With IPv4, we can have up to three bytes per zone delimiter, or in regular speak, three numbers per dot.

With IPv6, every single hex digit is given a zone delimiter, instead of groups of three. This is really nice in terms of flexibility, but people whine enough about v6 address length enough as-is. This pretty effectively doubles it.

For example, 2001:470:d82b:ffff:217:31ff:fec4:919a becomes a.9.1.9.4.c.e.f.f.f.1.3.7.1.2.0. f.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. This is, to put it lightly, nasty. The slightly shortened suffix goes entirely unnoticed.

It's pretty easy to glance at a v4 address and type out the reverse DNS mapping. It is right next to impossible to do that with a full length v6 address. You mentally transpose a digit and suddenly you're trying to mess with an address billions upon billions of addresses away from the one you care about.

Quick note: dig rectifies this problem. "dig -x [ip-addr-goes-here]" will perform a reverse DNS lookup on the address (both v4 and v6), but more importantly, it prints out the address in the proper reverse DNS form.

Example:

dig -x 2001:470:d82b:ffff:217:31ff:fec4:919a

[...snip...]

;; QUESTION SECTION:
;a.9.1.9.4.c.e.f.f.f.1.3.7.1.2.0.f.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR

[...snip...]

No more pain!

v6 tunnels and v4 firewalls - URL > Average

2009-03-30T05:45:23Z

My home network has "native" IPv6 through a series of tunnels that I've set up. The setup is pretty basic. A v6-in-v4 tunnel comes in through HE to my server, giving my server control over... a lot of v6. From here I segment it off a bit, and then branch the connectivity out over several other tunnels. One of these tunnels, as you could guess, heads to my home router.

When I was initially setting up the server <--> home tunnel, my firewalling rules gave me a fair bit of crap. Staring at tcpdump for quite some time didn't give me any leads concerning the proper rule to create, and I wound up whitelisting my entire home IPv4 address (that sounds a bit silly - whitelisting an 'entire v4 address' - you know, all one of them).

I finally got sick of allowing this IP full access to everything, because there were quite a number of ports "open" on the server but that I didn't want anyone outside accessing. This also caused problems with creating proper rules in the first place, because my only test bed was... from an entirely whitelisted IP. Suffice it to say some things that I thought were open were in fact not open to anyone but me, and this caused me quite the headache before I figured it out.

So how did I fix this? The answer is actually pretty simple - 42.

Wait, no. I meant 41. Sorry. Really I did. 41 is the protocol number assigned to IPv6. If this was obvious to others, well, sorry that I'm so slow. I didn't know. If I had known that I should be picking random numbers and trying them in a not exactly often used iptables command, then maybe I would have done this earlier.

Fun fact: "TCP" is 6. Note how this is ambiguous in terms of which "IP" it means, but in this case, it means IPv4. Why TCP is "6" is evidently defined in RFC 793, and why IPv6 is "41" can be found in RFC 1883 (or 1112, not exactly sure).

Note how TCP is 6, and that UDP is 17. Both TCP and UDP are commonly known as "TCP/IP" and "UDP/IP." Both of these operate quite nicely over both IPv4 and IPv6. IPv6 has an assigned number - but IPv4 does not. How you would intermix this I'm not sure. I can block IPv6 quite nicely it seems, but IPv4 is strangely absent. Does 6 imply v4? Does 17 imply v4? How can you filter UDP over 41?

I have no idea. I'm confused too. If you can make sense of the why, I'd be very interested in finding out why these protocol number seem so convoluted and inconsistent. It is pretty obvious that the protocol number for v6 was tacked on long after the base numbers for TCP and UDP were established, but whatever.

Enough rambling.

So how did I fix this firewalling issue?

# iptables -I INPUT -s -p 41 -j ACCEPT

... from the tunnel server. I didn't have to create a matching rule on my home router, and of course, ymmv.

For those of you familiar with iptables, the "-p 41" may look somewhat familiar to you. It should:

# iptables -I INPUT -p tcp --dport 80 -j ACCEPT

It is just a simple protocol match. All we're doing is matching the v4 source address, the v6 data, and allowing it through. Despite the above example doing something quite different, the -p switch does the same thing: matches a protocol.

IPv6... months later - URL > Average

2009-01-30T06:25:00Z

So I wrote about IPv6 a few months back. Tunneling it over IPv4, general networking with it, and even ping6'ing Google.

Been using it ever since.

Whoa now, wait a minute! People use IPv6?

For the most part, I set it up and poked with it for vanity purposes. "Hey look at me! I'm speaking a protocol that your router has no idea what to do with!" I had little actual use for it. For the most part I never had any real problems, but no real benefit either.

But it's been a few months, and I recently had my "IPv6 Epiphany." So here, have some random bits of info that I've picked up while playing with it.

The Problems
1. IPv6-in-IPv4 tunnels aren't really firewall friendly, nor are they the easiest thing to configure. I wound up whitelisting my home router's IPv4 address on my server, exempting it from all other iptables rules. This fixed a problem that cropped up when I rebooted my server, resetting my firewall rules to their saved state, and broke my ability to SSH into my server from home without specifying -4. Further, configuring a tunnel with iproute2 is pretty easy. Configuring a tunnel from CentOS to Debian using the "proper system-specific methods" really isn't. Debian I got working. CentOS I didn't, and wound up writing a pseudo-service to manage the tunnels and routes. All things considered, I probably would have wound up doing the same thing for my Debian router if it was as overloaded as my server in terms of IPv6 config.

Plus you have the increased latency. As a whole, this hasn't been a problem for me.

2. Not everyone who runs IPv6 maintains their v6 stack nearly as well as they do their v4 stack. This has proven to be a problem. For example, I was looking into H.323, and tried to open up the Open H.323 website.

The problem lies in the DNS. The OpenH323 project had a v6 DNS server. This server did not respond to queries coming over the v6 transport, breaking DNS resolution nicely for me. When I went poking with dig, it responded happily over v4. (It seems that their DNS is broken for both v4 and v6, so perhaps it was coming anyway. But the point stands. When your site works, you're content. You're not going to spend time checking that it works over both v4 and v6. This leads to problems.)

3. Application support.

From a sysadmin standpoint, nearly every computer out there has a DHCP client. Wait, sorry. Nearly every computer out there has a DHCPv4 client. This poses a problem when it comes to v6 connectivity. This is one area where Vista is quite a bit ahead of the *nix - they ship a DHCPv6 client and full stateless v6 autoconfig support by default. Their stateless autoconfig leaves a bit to be desired, as it ignores RDNSS data in the router advertisements, but they have documented how to get full DNS resolution on a stateless-only interface. It's pretty simple.

Linux, at a minimum, has a stateful DHCP client kicking around, but it isn't installed or even mentioned in most distro networking guides. It's not even available in several distros. The kernel has great stateless autoconfig, but RDNSS isn't exactly a kernel space setting either. There is a user space tool around that watches for the router adverts and adjusts /etc/resolv.conf as needed, but it's even less known than the stateful DHCP client.

There are also a couple really popular open source programs out there that don't speak v6 at all. There are two that bug me to this day: MySQL and Asterisk. MySQL is really not too huge of an issue right now, but to my knowledge they aren't even working on it. Maybe Drizzle could?

Asterisk is really the bigger issue. One of the largest roadblocks to getting VoIP with SIP to play nicely is NAT. To put it simply, it doesn't work with NAT. I can see (properly done) VoIP being a huge, monumental boost of support and a fantastic reason to get v6 working. Nearly the entire point of deploying v6 now is massively increased connectivity (with v4 connectivity dropping drastically in the near future). The current v4 (NAT) landscape is incredibly inhibiting to SIP, and while you can argue the relative merits of SIP to any other VoIP protocol, the value of having full connectivity from any one device to any other device really can't be understated.

(A note to you "but I like NAT because it's a great firewall!" people: first off, no it isn't. Second, there is a very simple rule here that both mirrors what you "get" with NAT and is arguably more secure than NAT. It happens to be called "default deny." From there, if you want to support VoIP, you can add one single rule and have great VoIP support. Have a /48 that houses both users and servers? Great - subnetting is your friend. Just open :80 to the server subnet.)

4. IPSEC. Still sucks to configure, is only going to become more important with enhanced device to device communication. Isn't supported by any mobile phone I'm aware of. Have a mobile phone that can connect to a SIP server over wifi? Great! Can it do IPSEC? Nope. Sure, TLS exists for a reason, but full-blown IPSEC has numerous advantages over TLS and it really isn't supported anywhere but the router and desktop. (Plus it still sucks to configure.)

Does your (insert handheld gaming device here) support IPSEC? No? Well sure I wasn't expecting it to, but it'll be interesting to see how this plays out over the next couple years.

5. Reverse DNS. 3.d.3.7.0.0.e.f.f.f.b.3.f.1.2.0.d.f.f.f.b.2.8.d.0.7.4.0.1.0.0.2.ip6.arpa. Do I really need to say just how much configuring reverse DNS sucks? No? Good. Is there a better solution? Probably not. I'm just glad that dig and ipv6calc are of use here, so I don't have to manually type out every full-length DNS record.

Advantages
1. Pretty much every single application I've used on linux supports it very well. Everything from HTTP to IMAP to Kerberos to SSH is operating flawlessly for me over v6. Vista has v6 CIFS, rdesktop, and RPC. I could make a full list here of what is supported in terms of services and clients across different OSs, but really, the list of what isn't properly supported is shorter at this point. And yes, for the most part, that applies to Windows too.

2. It's supported, well, by every (very?) modern OS. Vista just works with it. Linux just works with it.
There are some "gotchas" with both, but they'll be resolved over time and as more and more sysadmins come to use it. Vista actually has a default 6to4 tunnel built in, that starts up if you have a public v4 address. Even if your ISP doesn't support v6 (not that any of them do), if you can plug your Vista box in straight to the internet, you'll get v6 without any configuration or hassle.

3. NAT really sucks. The simple connectivity provided by v6 rocks. Now this leads back to how I started this entire post. First, a bit of background.

I run CentOS on my server. SSH has all password-based authentication disabled, and only supports Kerberos (GSSAPI) and pubkey auth.

I have a few RPMs that I need to rebuild to support a few extra things (namely postfix to support mysql, and kerberos to support an LDAP backend). I'd rather not keep all of the needed -devel packages installed on my server, and I'd also prefer to keep gcc and the rest of the needed buildutils not installed. The obvious solution is to rebuild them on another CentOS box, create a mini RPM repo, and then just use yum to install them. The process is simple enough.

The trick comes in actually getting those rebuilt RPMs to my server. This is also where v6 happens to make my life incredibly easy.

My CentOS "build box" is a VM running on my Vista box. This is really the best solution for me. I don't need to have a dedicated CentOS box here, and as a result of that I can click "turn off" and forget about it entirely until I need it again. This is probably the only really good use of VMs that I've found so far, but I digress.

As mentioned, you can't login to my server over SSH without an SSH key or kerberos auth. This means that I can't just scp them up to my server without either copying my existing key(s) over, or generating new keys and adding them

It was at this point I realized that my v6 setup meant that my VMs had public v6 addresses. And then a light clicked on.

I fired up rsync on the VM, copied the v6 address, and then from the server used rsync to move them over.

And it just worked. No port forwarding. No key configuration. No advanced auth config for the VM. I could have used apache+wget just as easily. I was able to start a service (on a VM that sits on a host behind NAT) and use it without any hassle, without any VPN trickery - it just worked.

If you compare the effort it would take to setup v6 on your home network and an "external" network, and compare that to the port forwarding, NAT translation/incompatibility, "hey this port is already in use, by another NAT'd device, guess that means we get to start using extensive proxies or odd ports" mess that may be involved in something as simple just getting host A to talk to host B...

... I think v6 comes out ahead in terms of what you get and the time it takes to make it work.

IPv6 and... software! - URL > Average

2008-09-07T03:31:06Z

A protocol is nothing if never used. Well, okay, maybe it can be a joke. Maybe. Okay, so that's not really a protocol. Evil Bit jokes are still positive net karma, right?

Likewise, IPv6 is pretty much useless if it is never used. I can assign the addresses all I please but ultimately if all I do is ping my desktop that sits "behind NAT" with it then for the most part the effort was wasted.

My server runs CentOS 5.2, my desktop runs Gentoo, my laptop Debian, my router Debian, my windows desktop Vista (dual boot Server 2008), and the Vista box also has three instances of OpenBSD running within VMWare.

I've got a pretty good testbed to see just what does/doesn't support IPv6, in terms of everything general web browsing to random system daemons to whatever end user programs you have a desire to run. So, I put together a small bit of info concerning what handles IPv6 perfectly, what is kind of broken, and what just looks at it with a mystified look on its face.

So to start:

Operating Systems

Windows
As far as I know, the first IPv6 stack was available for Windows 2000 via a separate download. XP bundled it by default, but left it uninstalled. Vista has the IPv6 stack enabled by default.

Linux
Got a pretty new IPv6 stack with 2.6. Had a working stack in 2.4. I'm pretty sure 2.2 had a functional stack too, as did 2.0. Don't quote me on that.

OpenBSD
Has supported IPv6 since 2.7.

Services/Servers

Apache
Apache has support IPv6 ever since the 2.0 release. Every component of apache that I tested supported IPv6 just fine, from general web page serving to SSL to proxies. Considering how much of the web is still on 1.3, all of those hosts will have to be upgraded to 2.0+ before a much wider IPv6 web base is available.

IIS
IIS (the Microsoft webserver) has supported IPv6 from their 6.0 release, also known as Server 2003. Most places use at least 2003 on their servers, the era of Win2k webservers kind of died out with Code Red and all of those other worms.

MySQL
Just kind of sits and looks at IPv6 like it has no clue what it is. Which is actually entirely true. Boo.

PostgreSQL
Talks happily with IPv6. At least I think. I'm too lazy to start my local copy and check. Their page on the matter isn't what one would call descriptive. No clue when this support was added.

MSSQL
Supported since their 2005 release.

Oracle
Offically supported as of 2006.

Samba
Supported as of the 3.2 release, which was actually just on June 1st of this year.

Windows SMB/CIFS
Supported with XP and onward. Probably Win2000 too.

So the servers are looking pretty good. Unless you run MySQL, which is pretty much everyone. Boo.

At a minimum, we can serve any content over HTTP just fine, and we can access most database just fine too, unless your name starts with a "My" and ends with a "SQL."

End-user programs

Mozilla Suite (and Firefox, Thunderbird, Seamonkey and friends)
Native IPv6 support, ever since the year 2000. Still has some work to be done according to the meta bug, but pretty much all of those bugs are on random operating systems that don't adversely change your ability to connect to IPv6 enabled sites.

Internet Explorer
Supported IPv6 ever since 4.0, once you applied a patch from their research division. Likewise real native support was probably with 5.0, if not it was by 6.0.

Outlook
Supported as of Outlook 2007.

Kopete
Supported. The KDE project has traces of IPv6 development starting around 1999. As far as I can tell, IPv6 is natively supported in every program in 3.5.

Pidgin
Supported. Not clue as of when due to the GAIM --> Pidgin name change, and I'm far too lazy to figure that out.

MSN Messenger, AIM, ICQ and friends
Who cares? (Likely not supported, though I doubt the client is the blocker in these cases.)

PuTTY
Supported since '04.

OpenSSH(d)
Supported. Probably since forever. Go OpenSSH.

irssi
Supported!

mIRC
Not supported without loading a third-party DLL. mIRC sucks anyway.

X-Chat
Supported.... on Windows since '03, *nix and friends likely even earlier.

I could go on and on and on. I won't, because I have no desire to list hundreds of thousands of software packages and their relative IPv6 states. Plus I'm getting tired and this entire post was spontaneous. Not too bad for 30 minutes of google.

But for the most part, we've got a great picture. Every operating system, browser, and web server supports IPv6 and supports it fantastically well. Nearly every program on *nix supports IPv6 and has for quite some time, and most of the big name Windows programs support IPv6 as well.

Not mentioned here was DNS, but the protocol has had support for it since (just about) forever and now that we have AAAA records for the root servers in the public DNS, DNS is good to go with IPv6 from start to finish.

Now we just have to work on the ISPs and home grade routers...

Footnote: one of the comments I got on my initial IPv6 entry was someone reporting success in integrating their LAN with IPv6. While I'm glad to hear it, I'm even more glad that when I got the "unapproved comment has been posted" notification e-mail, the corresponding IP address was a v6 address. The second I had IPv6 up and running on my server, I threw in AAAA records for pretty much everything. If I had to guess, they didn't even know they were using IPv6 to view this blog and post the comment - which is exactly the goal.

IPv6 - URL > Average

2008-08-31T05:04:56Z

Not too long ago, after reading yet another "the internet is dying! We're running out of address space and it's all coming by November 2010 according to Cisco!" I realized that, "hey waitaminute - that's just about two years from now. That's... soon."

So I setup IPv6 for the machines I own. I still depend on IPv4 simply due to IPv6 not being available... well, most anywhere. At least not natively.

A big part of the reason that we don't have IPv6 in more places is because... well, circular dependency here, but because it isn't around. I can't plug my laptop into any other ISP's line and use IPv6 natively, and even if I could, the chances of the average home grade router working with it is about two.

Out of thousands.

So to get around this, IPv6 in IPv4 tunnels are used. They do exactly what their name implies: tunnels IPv6 data within IPv4 packets. The downsides to IPv6 tunneling are latency/overhead and... your ability to keep your IP addresses. If you don't have native IPv6, then your current hosting provider or ISP won't be the one giving it to you - meaning you get to get the IPs from a third party company. When your hosting provider or ISP turns IPv6 on, what are the chances that you'll be able to reassign entire blocks of IPv6 address space? Probably not too great. If you've got Comcast as your home ISP, I don't think that your tunnel broker is going to happily move your address blocks over to Comcast's control - at all.

While the latter point is generally a deal breaker for a lot of people, in the long run, I don't care. IP address reassignment happens all the time. There's no rule stating that you must drop your tunnels once you get native IPv6, and there's no reason why it would be overly problematic or painful either. Simply bring up the native IPv6, change the DNS records, and drop your tunnels a few days later.

With this knowledge in hand, I went poking around the vast area known as the Internet and selected Hurricane Electric's IPv6 Tunnel Broker. What really sold me (for free, that is) on using HE for my tunnel was really twofold: one, their views on IPv6 (which boil down to "we'd really like to be in business when IPv4 is exhausted, so we're going to deploy native IPv6 everywhere, provide a tunnel broker for free for anyone and everyone, and we're going to do it three years before crunch time") and two, the fact that it was free.

In selecting HE, I also got full reverse DNS control, selection of the closest HE router to my server, full control of a /64 subnet and a /48 subnet (by request, which I requested), the possibility of adding three more /64 subnets and three more /48 subnets to my account, and full operating system support (with instructions for setup with linux-net-tools, iproute2, *BSD, OSX, Solaris, Windows XP+, and Cisco).

Not bad for $0. I'm a happy customer (and a potential customer should I ever need colocation/dedicated servers).

I setup my account with HE, logged in, and was presented with simplistic instructions on how to setup my CentOS server.

ip tunnel add he-ipv6 mode sit remote 209.51.161.58 local 64.22.124.36 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:4:b2::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

I created a new 'sit' tunnel named 'he-ipv6', with remote endpoint 209.51.161.58 - coming from 64.22.124.36 - and then turned the link up. Easy enough. Then I added my /64 allocation to the newly created tunnel, and pointed the default route through that tunnel.

Wait a minute. That's it? I'm IPv6 enabled already?

[kyle@averageurl ~]$ ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:1001::68) 56 data bytes
64 bytes from 2001:4860:0:1001::68: icmp_seq=0 ttl=55 time=327 ms

Yup...

From there, I requested a /48 subnet so I could allocate a few full /64 subnets to my house (a /64 for my LAN, wifi, and secondary wifi), brought some more tunnels up, and then from my desktop...

kyle@ksb ~ $ ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes
64 bytes from 2001:4860:0:2001::68: icmp_seq=1 ttl=54 time=325 ms

And now my desktop is IPv6 enabled. Go ahead, ping6 2001:470:d82b:ffff::2! You'll hit my home desktop. Then ping ::3 - my Vista box. Yup, that's right! My windows box is also on the IPv6 network. :fffe::2 would be my laptop on the wifi. The entire :fffd::0/64 subnet (and corresponding wifi AP) is unused currently, but perhaps once I decide to upgrade my router's software and play with wpa_supplicant that will change.

But why did I do this? What did I gain? Well, for starters, it was really fun to use HE's Looking Glass to run a traceroute to my desktop...

Tracing the route to IPv6 node 2001:470:d82b:ffff::2 from 1 to 30 hops

  1     2 ms   <1 ms   <1 ms 2001:470:0:32::2 
  2    76 ms   75 ms   75 ms 2001:470:0:35::2 
  3   103 ms  103 ms  103 ms 2001:470:0:4b::2 
  4   103 ms  103 ms  103 ms 2001:470:0:8c::2 
  5   148 ms  148 ms  148 ms 2001:470:4:b2::1 
  6   234 ms  236 ms  238 ms 2001:470:d82b:ffff::1 
  7   234 ms  233 ms  233 ms 2001:470:d82b:ffff::2

... while it sits behind my IPv4 NAT router. And then my Vista computer, and then my laptop connected to the wifi. Then I got to go take a look at The KAME project and check out the dancing turtle. It turns out that Google's IPv6 site also has an animated logo.

But in the end, I can now access all of my computers from behind NAT, without actually using any NAT - at all. I could drop the IPv4 addresses from some computers and still retain access to them, full access. This may prove to be both a blessing and a curse, but given time, we'll see..

(And yes, I know I shouldn't be using ::1 for my routers, that'll change soon enough.)

Well, hello there! - URL > Average

2008-05-27T18:00:00Z

Clicking back over to my blog, I read some of the things that I had posted earlier. To be honest, reading those posts now scares me to a degree. Reading this, a year later, it is plainly obvious where I had no clue what so ever what I was talking about.

That's always a fun feeling. "Oh, hey, look at all of this stuff I wrote about a year and a half ago. It's... it is... so.. entirely wrong. And to think I took my time to write that, scanned it once for typos (missed many), and then attached my name to it by clicking the big 'Save' button."

I was sorely tempted to remove my existing content (content! ha!) and start over with this post, but that feeling quickly subsided when I remembered that no matter how hard I try, and no matter how little people may care, somewhere it was archived. Saved as organized bits on a disk somewhere in the world, indexed by multiple bots, and easily found by anyone looking for my name. Kinda creepy when you think about it.

The other reason that I quickly gave that up, is equally simple. Some of it, I actually like. I've outlined in the past in great detail things which I still believe, and a lot of my philosophies. Sure, the ratio of posts I like is still nearly three to one, but hey, I'll live with it.

After just over a year of not touching this blog, for reasons many, I think I'll be.. well, I don't want to say "back to blogging." There's too much cliche involved with that line. I can think of no quicker way to blog deletion than by announcing my triumphant return of posting random things that no one cares about on a website that no one subscribes to (let alone visits to post comments).

Except of course, for the bots (feed aggregators included).

But who knows what will happen!

Deploying Jabber and Miranda IM: thoughts and comments - URL > Average

2006-09-21T18:52:16Z

I recently installed a jabber server for my small office(s). We recently expanded to three separate buildings, one in Sandy, one in Salt Lake City, and another in Bountiful. Likewise, suddenly the ability to communicate was limited by phones and e-mail, and for the large majority (80%) of the needed communication, both of those options were either overkill (one-line e-mail?) or impractical (staying on hold for 30 minutes, tieing up a phone line, to ask a single six-word question).

It's funny how little we value the ability to easily communicate until it's suddenly not so easy.

I started out trying to install ejabberd, but failed miserably. In both the Sandy and Salt Lake offices, I have a modest linux router installed, doing all routing/firewalling/networking in general. Likewise, throw in the DNS SRV records on a per-site basis, in theory I would have been able to point all clients to the same host, but end result have them all wind up connecting to their local instance of ejabberd.

For those of you who don't know, ejabberd is famous for it's ability to cluster and fail/fault-over abilities. It uses a database that is essentially distributed by default. Further, it has a very nice web interface for management, along with a shared roster (list of people on the service) built-in. Sadly, I never was able to get the distributed part of it (the reason to use it) working. I would add a user on one side, and magically, that user would never appear on the other. Huh, oh well.

I wound up reverting back to the tried and true method (for me, anyways) of getting a jabber server up and running: jabberd2. Jabberd2 is not distributed like ejabberd, but it also typically uses MySQL as the backend (granted, ejabberd can also, and I've never tried to do so either, but I also know how to make jabberd2 work, and that's what I wanted here), which I'm rather familiar with.

So, about twenty minutes after I gave up on ejabberd, I had a functional jabberd2 server, up and ready to go. (For those of you curious, I have a 1.2TB RAID5 array, on which the database server is running. Overkill, yes, but I don't want to burden the router down with a database server.) Now for the fun part: the client, the program that everyone will actually be using.

All of the clients are running Windows XP, along with two or three Windows 2000 boxes. jabber.org has an impressive list of jabber clients, for pretty much any OS under the sun. In the end, I chose Miranda IM, for several reasons:

Final distributed file size: I wound up with a 556kb .msi installer that I built for it (more on that later).
Runtime size: I'm pretty sure that everyone lost maybe a megabyte of RAM from running this, if that. Small, light, and fast are all words that I'd use to describe this.
Ability to customize: at it's core, it's a small executable with a large army of plugins (DLLs), providing additional functions. Likewise, I just cut out everything except the jabber components, and hey, I have a perfect IM client for jabber and jabber only.
mirandaboot.ini: A little-known feature of Miranda. Drop this file into the install directory, and you can change program defaults. In this case, it's set to automatically create a user profile in their own user's directory, named after their domain logon name.
Looks for DNS SRV records and uses them (Hey, gaim, where are you? Oh, right, you're STILL LACKING THIS HORRIBLY SIMPLE FEATURE. What's so hard about a DNS lookup, really?).
Easy to use, simplistic.

All in all, this is pretty much a perfect client for people. It's simple enough to use, effective, small, and to top it all off, free. The only thing it was missing was a .msi installer package (it is being installed on a windows domain after all), and the official stance from the Miranda devs consists of, "you have a .zip and a .exe installer, and what we provide works. If you want a .msi package, feel free to build it yourself." As a result, I did, and I used Wix to do it. Yay for open source and free Microsoft programs that get the job done, and get it done well. The posts I saw on the Miranda forums included a lot of users wanting a .msi installer, so once I polish it off, I'll post both the Wix .xml file, along with the final .msi for people to abuse. For now, I'll link to the .msi which I'm using here. This includes jabber components only, and installs without prompting to Program Files. This file is suitable for usage anywhere, as it saves all settings in places where anyone can write to, and it is multi-user sane (in the sense that user A can't see user B's settings and contacts).

Earlier, I mentioned that ejabberd has shared rosters, where basically everyone can see the same group of people. Sadly, jabberd2 lacks this feature, but makes up for it in another way: it has MySQL as it's backend. This makes is horribly easy to write a small script which clears the existing roster table, and re-populates it with everyone else who is registered with the service. This makes it pretty easy to accomplish a similar "shared roster", and it bypasses the semi-complicated process to add a user, consisting of:

Finding the person to talk to,
Adding the person to talk to,
Waiting for the the person on the other end to both sign in, and click allow,
Waiting for the person on the other end to add you themselves,
Finally allowing that user access to talk to you.

For people who only know how to use computers as far as clicking File, Print goes, the automatic addition of new users to their lists saves time and effort all the way around. Not to mention the new person doesn't have to go and add thirty other people, and then wait for all thirty people to add and authorize the new person.

In the end, I wound up with a setup that's as close to perfect as it can get. Shared rosters, easy to use client, and a client that works perfectly and easily.

I'm rather liking this whole "run your own IM server" idea now that I'm using it on a scale larger than two users. And hey, so are all of the employees.
Links:

miranda-0.5.1-1st.msi (.msi installer, jabber components only)
miranda-1st.xml (Wix .xml file, used to create your own .msi, jabber components only)
miranda.xml (Wix .xml file used to create your own .msi, all Miranda IM components)

Once again, these files do not include a GUI installer of any sort, but rather will install the program automatically without prompting. There's your warning.