Beware of using Linux's
hostname -s switch
hostname program has a common switch,
-s, which is documented
(in the Linux version) as:
- Display the short host name. This is the host name cut at the first dot.
Although you would not expect it from this description, running
hostname -s' will do a
gethostbyname() and thus often a DNS lookup
in most Linux versions of
hostname. This can of course fail if your
DNS is not working, which winds up with the very peculiar result of
hostname failing. And all of this because you innocently decided to
trim out any dots that might be present using the most obvious and
(Most scripts don't cope very well with this, partly because the Bourne
shell makes it annoyingly difficult to deal with programs failing in
command substitutions and partly because come on, who expects
Red Hat Enterprise 5, Fedora 8, Ubuntu 6.06 and Ubuntu 8.04 have
hostname that behave this way. Fedora 11 has a
version that does not, because someone filed a bug about it; unfortunately I
can't tell if this has been fixed upstream or if an upstream bug has
been filed (or if it would be useful to do so).
The sad conclusion is that for the next several years, if you need the local hostname without any dots on it you should write something like:
hostname | sed 's/\..*//'
instead of using the shorter, nicer
(We found this out the hard way last night, when we had some sort of network issue that made our DNS servers unreachable to some machines while some of our status check scripts were running.)
Some thoughts about 6to4
I've previously written about the problems with the IPv4 to IPv6 transition, and how the IPv6 people could have made it easier. Well, it turns out that I have to take back some of the grumpy things that I said back then because I just found out about 6to4, which makes IPv6 connectivity fairly trivial for machines with public IPv4 addresses (and generally it works), partly by embedding the IPv4 address space into IPv6.
6to4 is one of those things that strike me as a neat hack, in the classic sense; it is an elegant, clever trick to get something done. The simplicity of how things work is very nice and it avoids all sorts of annoyances with more complex VPN/tunnel systems. Unfortunately, I think that in the long term 6to4 is probably doomed; it's useful for easy experimentation, but not really as a way to get large numbers of people onto the IPv6 Internet. The problem is the issue of gateways.
(The remainder of this assumes that you understand how 6to4 works.)
Two 6to4 machines will talk directly to each other over the IPv4 Internet, but to talk to general IPv6 addresses they have to route through a 6to4-to-IPv6 gateway. Because the IPv6 people had no desire to import the IPv4 routing table into IPv6 routing tables, 6to4 gateways can only advertise the entire (IPv6 embedded) IPv4 address space, not subset routes for parts of it.
An ISP with top-level IPv6 connectivity can easily arrange for outgoing 6to4 traffic from its customers to go through its own 6to4 to IPv6 gateway; it just routes traffic for the magic 220.127.116.11 gateway IP address to its gateway. However, it has no way of causing the return traffic from pure IPv6 nodes to flow through its gateway; instead, the return packets will be routed through whichever 6to4 gateway is closest (in a network sense) to the IPv6 machine at the other end.
Any significant use of 6to4 thus necessarily starts shunting more and more traffic through public gateways, even under the best of circumstances. Many of these gateways will not be located on what are the natural network paths between the end nodes, where the traffic would have flowed regardless of where the gatewaying happened; instead, the traffic will be diverted out of line, resulting in extra volume transiting into and out of unrelated networks. This effect is magnified by ISPs who do not operate 6to4 gateways (whether public or private), because then even the outgoing 6to4 traffic is running off through another network.
For end users, this results in packet delays. For the ISPs involved, this causes issues with both link volumes and peering politics; you're spending money to carry other people's traffic out of the goodness of your heart, and your peers may not like that anyways. Something is likely to give sooner or later, and so the more popular 6to4 gets, the fewer truly public gateways I suspect we'll see and the higher the chance that you won't get full and reliable IPv6 connectivity with 6to4.
This doesn't make 6to4 useless; it's still a great way to start playing around with IPv6 without having to find a 6bone tunnel broker, registering, setting things up, and all of that. I just can't see it as a long-term compatibility solution for general interaction between IPv4 and IPv6 machines, unless there's something I'm missing.
(I looked into IPv6 tunnel brokers once upon a time and concluded that it was too much work. The great appeal of 6to4 is that all I have to do is run a few commands locally and bang, I have IPv6 connectivity and can start finding out all of the programs that now break.)
Note that even today this means that your 6to4-enabled machine may not have full IPv6 connectivity; what connectivity you get depends on the administrative policies and routing of the gateways involved. Possibly this means I should grit my teeth and get a connection through an IPv6 tunnel broker.
(I expect that these issues are already well known in the 6to4 and IPv6 community; I'm just new to all of this IPv6 stuff.)
Sidebar: why the 'no subset routes' thing hurts
If 6to4 gateways could advertise IPv6 routes for a subset of the IPv4 address space, your local ISP's 6to4 gateway could announce itself as the IPv6 gateway for only its IPv4 address space. This would cause traffic to flow the way it should; the returning IPv6 packets would transit over the 6bone until they reached your ISP, instead of flying off to some other 6to4 gateway to be turned into IPv4 packets.
This would have the additional effect of making the packet routes symmetrical. Right now, 6to4 connections are assymmetrically routed, where the outgoing packets take one path and incoming packets take another. In fact, incoming ones may take any number of paths depending on where they're coming from.