This is the first of a possibly long series of posts detailing some of the issues I’ve been having with a job task of mine, for a customer that paid me way less than they should have. I’m not going to deny that some of this can be just vague rants, and some of it might as well be incorrect. I mostly solved my trouble, but if you have corrections to make, feel free to comment on them.
So, a customer of mine has a small shop of two people (and a secretary), but a number of computer, devices and other amenities, with the result that they’d actually need a dedicated sysadmin; I helped them out for a while for just token prices, since one of them is a friend, and they are passing a rough patch, I just hope they’ll be able to pay me for my time properly at some point.
Unfortunately, there is one big trouble with one of the choices they made before I started helping them out: their ISP does not provide public IP addresses, but they rather provide just five IPs in a private NAT (actually using a non-assigned IP range, which is also bad on its own). This became first a problem because they have more than five computers, but now it’s a problem because I cannot just connect to the boxes on their premises to ensure that they run properly (what I’m working on mainly is a backup server to make sure that they won’t lose their data again, and that I need access to).
One relatively easy way to solve this problem, generally speaking, is to provide the boxes with IPv6 addresses; this works peachy when you have control of the NAT (like I do at home), but it’s a bit more complex when you have hostile NATs in front of you.
My first idea was to use Hurricane Electric’s Tunnel Broker since I remember they started providing, some time ago, VPN access to public IPv4 addresses that could be used to set up IPv6 tunnels behind NAT or dynamic IP connections. Unfortunately, they only provide the VPN through the Microsoft-originating PPTP protocol, which uses the (standard) GRE protocol for sending and receiving the packages. Unfortunately, PPTP does not work through that particular NAT, so I cannot use that option.
The Teredo protocol comes as a natural solution as it is designed for that specific purpose: avoiding special-protocol packets, such as 47 (GRE) or 41 (IPv6-in-IPv4). There are just two problems with this option: the first problem is that Teredo only works with one host/address and not a full network, so I have to proxy myself through that to be able to connect to the various boxes. The second is that the IP address the Teredo address is declared from depends on the outgoing NAT access which is not under my control at all.
Since my first direct option (using DynDNS), was out of reach, as it does not support IPv6 addresses, I went to look at a technique that I remember was designed just to solve this kind of trouble: mobility. The Mobile IP technique and technologies are supposed to provide stable addressing for nodes that may be roaming between different networks and network technologies. For instance for laptops that can switch between normal cable-based Ethernet and Wireless LAN, or for mobile phone that can switch cell or move from UMTS to Wireless network on ADSL. All in all, it seems a pretty cool idea.
Unfortunately there are a number of issues with that idea; while Linux nowadays has in-kernel support for Mobile IP, running a Home Agent (router/server for the Mobile IP system) requires some software stack that is not available in Gentoo and as far as I know is not even regularly released at all. Interestingly enough, thorough documentation on MIPv6 is available on the same site that helped me with my Dell laptop so I have to thank again Arnauld.
There are many reasons why I think it’s overkill to work on MIPv6 at this point in time, at least for external routing (I still wonder if it might solve the problem of laptops switching between the two interface within my home network); first of all, there is the encapsulation problem; to be able to use MIPv6 over Teredo, you end up with a very complex stack: IPv4 / UDP / IPv6 / ESP / IPv6 / TCP / data; but not just that, even if it was an acceptable stack, it requires you to run at least two daemons on the Home Agent system, and to use a custom Teredo server, as it requires a higher MTU than the protocol specifies as default.
It wouldn’t be very difficult to do (the miredo package available on Gentoo provides both client and server for miredo, although I guess I wouldn’t mind having a client-only install), if it wasn’t for one particular requirement: to run a miredo server you need two public IP addresses — for compatibility, you also need the two to be one IP from the other. I have the two IPs but I’m not sure if I want to use it for this kind of work. Also, it will make my customer’s access (and internal IPv6 network, which they don’t care about, but I do, when I’m there with my laptop) depend on the availability of my home network which is not a given.
All in all, MIPv6 is a nice thing, but until there will be enough providers to hand out either native, or near-native IPv6 connectivity (6to4, 6rd), it’s probably just going to be some kind of “technology preview”. Sigh, I wish more home routers configured themselves by default to provide at least 6to4 to home networks, that would make it much nicer a tool.
The next solution was obviously to go back to the original idea of using dynamic hosts, but that’ll be a rant for tomorrow.