Sunday, March 19, 2006

Missing Pieces of the IPv6 Puzzle

Next week my new DSL line will be installed. Speekeasy.net is a great company, I've used them in the past and I'm happy to be moving away from the Comtastic (not) Comcast.net cable internet service to something that a) provides a consistent high speed connection and b) has people who care about their customers and know a thing or two about networking. But this post isn't about DSL vs Cable internet service, it's about my continuing IPv6 saga. The reason I mention the DSL install at all is because now I'll have four (count 'em 4) static IPv4 addresses us use. This means that I can finally use an IPv6 tunnel broker rather than trying to use STUN and virtual network interfaces to tunnel out of my DHCP/NAT/IPv4 connection. I can't wait.

I've given up trying to find a IPv6 internet service provider in Boston. I don't think there is one. I'd imagine that Speakeasy will someday soon be the pioneer and offer that service, as they are the most network savvy full service ISP in my area. As I said, with the static IPv4 addresses they will allocate to me I'll be able to use a IPv6 tunnel broker to create a fully IPv6 network behind my router. That's as close to fully IPv6 as I can hope to have right now.

So, with that in mind I started to evaluate the devices on my network and understand how they will participate in this IPv6 nirvana. Here is the short list:

  • Mac PowerBook laptop - OS/X 10.4 - built in Airport Extreme WiFi 802.11b/g
  • Mac Mini - OS/X 10.4 - built in Airport Extreme WiFi 802.11b/g
  • PC Laptop - Windows XP 64bit SP2 - built in WiFi 802.11/b/g
  • HP LaserJet 5Si - an older printer with built in ethernet
  • Call-in-One - an analog telephone adapter for VoIP/SIP service
  • ZyXEL P-2000w_v2 - WiFi 802.11b/g VoIP/SIP portable phone
  • Random guests with their laptops

Okay, that's not too complex so this conversion should be easy. First let me describe my connection, then I'll describe each device's participation in that network.

DSL - WiFi Router:
The connection to my ISP's IPv4 based network is fairly straight forward. Tomorrow Covad, on behalf of Speakeasy, will finish the install of a local loop for DSL service. That will give me 6Mbit down and 768Kbit up, that's good enough for my purposes and better than the shaky 1-2Mbit service I'm seeing with Comcast. That will go from the wall to a simple DSL modem. Ethernet (IEEE 802.3) will connect the DSL modem to a Linksys WRT54GL WiFi router/switch box, a favorite among hackers. The Linksys will be running OpenWRT's White Russian RC4 release of Linux based firmware, not the default Linksys firmware. I can do this because Linksys (a part of Cisco Systems) has graciously built a version of the WRT line based on Linux (hence the 'L') after briefly pissing everyone off by switching to VxWorks in their WRT54G v5 model. I'm sure sales dropped precipitously when they made that switch and that the 'L' model was as much motivated by money as it was altruism. More companies should realize that today's maker-culture (aka the remix or mash-up cultures) wants to have the option to tinker and customize things they own.
Using OpenWRT allows me to gain full control of the device and the networks it creates in ways that the commercial supplied firmware from Linksys did not allow. Specifically, I'll be able to setup IPv6. To be fair, I'm in the minority so it's understandable that Linksys doesn't support IPv6 out of the box. My issue is that no one does, and if we have any hope of transitioning to IPv6 in the near future someone will have to step up to the plate.
With the ability to setup IPv6 thanks to custom firmware I can use one of the static IPv4 addresses and 6to4 with an IPv6 tunnel broker (from ipv6.he.net for instance). At that point my network will be solely IPv6 based.
I looked for a WiFi router designed for home use (read: reasonably priced or available cheap on eBay) that supported IPv6 out of the box. I found none. This is where I started to realize that finding an IPv6 ISP was only the first missing piece to the IPv6 puzzle.

Summary:

• Setup requires expert knowledge of networking, routers, and internet protocols
• No commercial WiFi router exists to enable an IPv6 in the house
• The only way to connect to the IPv6 networks is via a tunnel broker using 6to4

Printers:
Let's start off with one of the more interesting items on the net, a basic networked printer. I have an old HP LaserJet 5Si printer. When this was manufactured IPv6 was still being ironed out and no one was using it or even planning to someday use it. So, clearly HP was not going to try to include support for IPv6 and that was the right decision at that time. Before I find a way to bridge that printer into the IPv6 world I wonder if there is a printer that supports IPv6 out of the box?
To be fair, most printers are designed to connect to some form of printing host via some serial (or parallel) direct connection. Today the cheaper printers out there offer USB as the only connection choice. There are a dozen or so WiFi print servers available, here's one from Linksys. It plugs into the printer's USB port and joins some WiFi network. In so doing it can advertise the printer's presents and spool printing requests. Perfect, except for the fact that it doesn't support IPv6. I did some looking around, I couldn't find a single similar device that did.
The second option is to find a printer that has an ethernet connection and supports IPv6. I didn't even bother to search for one of those. I'm fairly sure that it doesn't exist in the market today, if you know of one email me. We're left with my ancient (but capable) printer with an ethernet jack and a knowledge of IPv4, but not IPv6.
The simplest way to bring this printer onto the IPv6 network at this point would be a nice WiFi bridge. Bridges work at OSI layer 2, the Data Link layer, in this case wireless ethernet (IEEE 802.11 a/b/g etc). That is the layer below things like the Internet Protocol (IP), which sits at layer 3, the Network layer. Perfect, because the supporting layers know nothing about the layers that use them. Layer 2 should know nothing about layer 3, in this case IPv4 or IPv6, and so life should be good. But there is a problem.
With wired connections at layer 2 there is no doubt where the signal goes or who is participating in that network. On a wired ethernet LAN simply plugging in a device is all that is needed for it to begin interacting with other connected devices. With wireless LANs things are less obvious. Wireless LANs simply emit a radio signal on some frequency, and listen for a response. The device needs to be told which signals are important and which ones to ignore because chances are that your not the only one running a wireless LAN. This is why you have to setup a service set identifier (SSID) for your WiFi LAN and configure every device on that LAN to filter radio traffic based on that SSID. When you ask your computer to do a "site survey" it listens for radio signals on various frequencies and picks out the names (the SSIDs) of the networks operating within range. You then pick your SSID you associated with your wireless network and the computer (or other networked device) can negotiate a connection with that specific wireless access point. Sometimes you need to configure a WEP key before the access point will let you join because the network is not public. So these wireless access points are not plug-and-play, they require some amount of configuration, and that's where we get into trouble.
The most common way to configure these devices is through a web based interface you access using HTTP. Manufactures of wireless network devices simply configure the device to startup with a well known IP address (say 192.168.0.1/16 or 10.0.1.1/8 which are special private address not routable on the internet at large, but perfect for at-home LANs running NAT, more on that later) and then let you connect via HTTP and voila, you have a way to set things up. One problem, the configuration interface is IPv4 based.
"So what?", you say, "simply use IPv4 to configure the device then run IPv6 over it." Wrong. At that point the printer (or other legacy IPv4-only device) is connected on layer 2, and IPv6 is available to it on layer 3, but it doesn't understand IPv6 remember?
With a device like that Linksys wireless print server things are even worse. Sure, you can connect to it and configure it to join the proper wireless network using a temporary IPv4 network, but once you've done that the device has to understand IPv6, which it doesn't. To my knowledge, there is no device on the market that does. Worse, there is no device on the market that has been hacked (like the OpenWRT hack) to run some other firmware that does understand IPv6.
In the case of a printer with ethernet built in and an understanding of IPv4 you need a something in the middle that can on one side join the wireless network, then the IPv6 network, and finally advertise the printer's presence. On the other side it has to speak ethernet (IEEE 802.3) and IPv4 so that it can talk to the printer. In the middle it has to translate between IPv6 and IPv4 bi-directionally and we'd like it to spool print jobs too. As you might already guess, no such device exists. Well, that's not entirely true. I could take another Linksys WRT54GL (for another ~$69) and once again flash the OpenWRT firmware onto it and configure it to do exactly what I describe. But that is the only way today, that I know of, to get my HP LaserJet 5Si onto an IPv6 network.

Summary:

  • There is no commercially available wireless bridge for use on IPv6 networks
  • There is no commercially available wireless print server (USB, Parallel, or Ethernet) for IPv6 networks
  • The only option for supporting any legacy IPv4 device such as a printer with an ethernet port is by building a custom setup using yet another relatively expensive device, the WRT54GL in this case, running custom firmware with a complex configuration

Analog Telephone Adapters (ATAs) for VoIP/SIP IP Telephony Networks:
I don't pay for normal POTS phone service at my place of residence. I've used my cell phone for years as my primary phone line and it's served me well. But cell phone minutes are expensive, overages even more so. So, recently I've tried to use some pre-paid VoIP based services that seem to be more economic and, due to the pre-paid nature and no concept of overages, the total out of pocket cost is known in advance which I like. I also like the fact that I'm using the internet for communications, it just feels right to me. VoIP, in my experience to date, has generally good sound quality and most of the basic features of POTS and cellphone services. There are still some kinks to work out (caller ID doesn't work on the callee's side on the connection, but that's almost a bonus), but the good news is that today it is functional and ready for general use. Traffic shaping is important to maintain call quality (quality of service or QoS) on busy networks, but outside of that there is nothing you need to manage on your side for this to work. I'll put in a good word here for my service provider, SIPPhone and the GizmoProject which can use area774 to tie my cell phone and VoIP/SIP phones together behind a single (755) area code phone number. Trust me, this is cool stuff.
One quick note, SIP is a standard protocol for IP telephony (voice over IP, VoIP) session initiation. That means that it is responsible for connecting to some VoIP service provider on the net somewhere and asking it to make a call to a specific number or end point; it sets up the call then the voice traffic flows over the internet using the VoIP protocol. If you ask me, standards are a good thing. Skype, the most popular VoIP service today, does not use SIP. It has a proprietary protocol for session initiation. This is a bad thing. Stop using Skype, please. Switch to the GizmoProject, use your feet to protest proprietary solutions. They cause vendor lock-in and are generally a bad thing. Here is an interesting blog article about how bridges are between SIP and Skype are beginning to show up and fix this incompatibility. This is reminiscent of many open vs. closed fights in the past such as the AOL/AIM proprietary IM standard verses the Jabber open standard. Open standards technology create open markets and we all benefit from the competition.
Back to the heart of this issue, can I find a commercial ATA that understands IPv6? I'm sure by now you already know the answer. I did some research on the web and as you would suspect, there is no commercially available ATA device that understands IPv6 on the market today. Worse yet, there is no ATA that is wireless (IEEE 802.11). If I want to plug in an existing phone to the new world of VoIP services I have to run a wired ethernet connection (IEEE 802.3) from the ATA to some ethernet hub or use a wireless bridge. If I build that print server using a Linksys WRT54GL as the bridge I could use it for my VoIP phone too, if they are physically next to each other. Here again though the ATA will be speaking IPv4 to the Linksys which, in turn, will be translating that into IPv6 packets. A workable solution, but ultimately not ideal as it is really not IPv6.

Summary:

  • There is no commercially available ATA for use on IPv6 networks
  • There is no wireless ATA
  • I have to reuse my second hacked Linksys WRT54GL and a wired ethernet connection to get my Call-in-One onto my new IPv6 based network
WiFi VoIP/SIP based Portable Phones:

There are a ton of these new devices being built. Some cell phone manufacturers are even building SIP/VoIP into their handsets. This seems to be a booming market in the VoIP/Telephony world. In case you can't picture what this gizmo is, imagine something similar in design and function to your cell phone (without the superfluous built in camera, PIM, and other crap cell phones have these days) but rather than operating on cell phone radio frequencies to nearby cell phone towers run by your favorite cell phone service provider they speak WiFi (IEEE 802.11) and connect to a VoIP service on the network using SIP. That's cool. Now I can walk around the house and use something akin to a portable phone while knowing that my voice traffic is traversing the internet. This to me makes much more sense than the use of soft phones. Things like the Skype and GizmoProject's software based phones that you run on your computer. With those your computer "rings" and you click a button to connect and then you use your computers underwhealming speaker and microphone to converse. The most glaring issue with this, other than the fact that you look silly doing it, is echo cancelation. As you hear someone speak to you over your computer's speakers that sound is picked up by your computer's microphone and retransmitted to the speaker. It's really annoying and most people resort to headsets so they look even more silly, like tele-marketers (oh, the humanity). The echo cancelation software is getting better and this will go away, but you'll still look silly talking at your computer. But I digress.
I own such a phone made by ZyXEL. I wrote about it in an earlier post. It works, for the most part, but it has some glaring issues (battery life and maintaining connection with the VoIP server when off the hook are huge problems right now). The problem with this device is that it speaks IPv4. It uses DHCP to get an address, and STUN to burrow out of the NAT'ed Comcast provided DHCP/IPv4 network I currently run.
The obvious issue here is that the phone knows nothing about IPv6. There is no way to bridge it onto a IPv6 network either because it is an integrated device. I can't do the printer/ATA trick. I have no choice but to run an IPv4 network for this device to work.
As you might expect, I've looked for a portable battery powered VoIP/SIP/WiFi phone that can run on an IPv6 network. Once again, I've been disappointed. There is no such device. My only hope with this device is to hack it's firmware. I know I'm not good enough to do that, and I've found no one out there that has taken the time to do it themselves. So I'm stuck on this one. My choices are a) don't use the phone, b) use it on it's own IPv4 network. I don't know what I'm going to do right now, I think I'll sell it on eBay.
In the mean time I'm going to write a letter to ZyXEL asking them to pioneer the use of IPv6 on these devices (improve battery life, and fix the connection issues). Maybe they will be the first to make the leap.
By the way, VoIP and other real time streaming services (like on demand video) were made for Ipv6. IPv6 has built in QoS features so phone calls would be more reliable because their traffic would take priority on the net and as a result the conversation will clearer and won't have any noticeable lag. The other big advantage is that the phone would have a first class IP address and not have to use a work around protocol like STUN (which drills holes through NAT networks) to create a route to the SIP/VoIP server. Workarounds like NAT and STUN piss me off.

Summary:

  • There is no commercially available WiFi VoIP/SIP phone for use on IPv6 networks (despite the obvious advantage of using IPv6 for voice communications)
  • My ZyXEL phone is worthless to me in my IPv6 world, and is going on eBay
  • Protocols like NAT and STUN serve only to slow the adoption of IPv6, which is a bad thing people

Operating Systems:
So, in this world we have a bunch of computers that need internet connections. Linux, OS/X, Windows XP, BSD, whatever they all have to join the internet. When my computer is disconnected it's really just a brick with seriously limited value. The network is the computer. Scott you got it right (too bad you didn't fully capitalize it).
In my case I have all those operating systems running at home. I have three computers, two Macs and one PC. I need them all to use IPv6. By now you should be ready for some good news and here it comes. All of the listed operating systems have IPv6 support. Huzzah! Finally, and with my most valuable networked devices, I can breathe a sigh of relief and step into the future of networking. IPv6, here I come.
But, life is not entirely rosy. This, if you couldn't tell by now, is a post to help me vent my frustration with vendors. No one is guiltless in this non-starter transition to IPv6. Let me explain.
Apple's OS/X is a nice operating system, my favorite at this time. It has built in support for IPv6 that just works. In the configuration panel you can enable IPv6 and bingo, if you have IPv6 routers up and running the communication begins without issues (or so I believe, my net isn't up yet but others report this to be the case). My gripe with OS/X is that IPv6 is that the implementation makes it feel like a second class citizen and in the default configuration it causes IPv4 users some pain. Both of these are socially bad things as they hinder the transition to IPv6. IPv6 in the Network preferences panel is an afterthought even though at the OS level it is a peer with IPv4. This leaves the impression that IPv6 isn't what you really want to use, that IPv4 is good enough and only the experimental crowd should venture into IPv6-land. Come on Apple, lead the way here. Don't let Microsoft get the jump on you. Secondly, out of the box IPv6 is enabled but seems to slow things down. The problem is this, DNS lookups (the step that changes www.google.com into an IP address) on Mac OS/X first try to find IPv6 addresses (good) but 99.99% of the time there isn't one so they have to timeout and try an IPv4 based DNS lookup. This is bad because the net result is an impression that OS/X networking is slowed down by IPv6. That's the last thing we want people believing. Clearly this kind of first experience with IPv6 will only serve to slow its adoption. Figure out a way around this Apple, don't make it well known that disabling IPv6 support will speed up your network connections.
Next Microsoft's Windows XP and their forthcoming Vista (in 2010, maybe...). XP has support for IPv6, but to configure it you have to resort to a the DOS shell first. You have to tell the operating system, "Please enable IPv6 on all my network interfaces." Supposedly in Vista IPv6 will be a first class citizen. That'll be nice, the Chinese and EU have mandated IPv6 conversions and so that'll give Microsoft a leg up when negotiating more monopolistic licenses. Just what we need. I'll give Microsoft points for saying that they are going to push IPv6 into the front seat, lets wait and see if they deliver.
Linux and BSD both have excellent support for IPv6 at the operating system level. This is great. In fact, it was the open source communities that built the first, best, and most popular implementations. I'm not surprised one bit by that. Kudos to those people. My gripe, and remember I'm griping here today, is that once again at the GUI level IPv6 is a second class citizen. KDE, GNOME, you name it all do a poor job of presenting IPv6 as an option and making it easy to configure IPv6 while disabling IPv4.

Summary:

  • The major commercial and open source operating systems all support IPv6, gold stars for everyone
  • They all fall short of making IPv6 feel like a first class citizen to the end user and none are good at making IPv6 intuitive or easy to configure
  • It's in the commercial best interest of all OS providers to make this a priority, China and the EU are big markets, wake up and smell the cash

Conclusions
I've tried to build an IPv6 network and to some small extent I've succeeded. When I finish this setup I'll have a few devices participating in an IPv6 wireless LAN. But my victory is bitter sweet. The only real IPv6 devices will be my three computers. Everything else will be bridged somehow. The disgusting thing is that all that IPv6 traffic I've worked so hard to create is destined to be translated back to IPv4 at my router before exiting into the internet at large. Basically, I'll be slowing down everything on my network just to be an IPv6 pioneer. Worse yet, 99.99% of services I'll use on a daily basis will be IPv4. Right now the most exciting thing on the IPv6 internet is a dancing turtle.
The most depressing conclusion is that even if someone wanted to build a fully functional IPv6 network for use at home (or in the office for that matter) they would quickly discover that the hardware manufacturers are woefully behind on the transition, and for good reason there is no demand for IPv6 today. But thankfully the chicken is about to hatch and bust the egg open. As China, the EU, and other forward thinking governments of the world push for IPv6 these devices will have to be built to support them. Sure the manuals will all be in Chinese, but hell who reads manuals anyway?


Technorati Tags: , , , , , , ,