7.9 Fun with IP

Once your network project is in place, you may find that it will quickly grow beyond your expectations. What begins as a simple point-to-point link across the street might need to quickly expand to accommodate friends and neighbors, as they find out about "the network." As the network grows, the complexity of managing it grows as well. But then, this is the fun part. Here are some novel innovations that community groups are using to extend their projects into fun new areas. While they are not directly related to wireless networking, these ideas can enhance your wireless network.

7.9.1 Running Your Own Top-Level Domain in DNS

If you're using private address space for your wireless network and it grows to a respectable size, you will probably want to start offering local services (such as web servers and music streamers). But simply using IP addresses is no fun. Consider the ease of setting up your own top-level domain (TLD). Normally, zone entries in named.conf look something like this:

zone "oreillynet.com" {
        type master;
        file "data/oreillynet.com";
};

This is an entry appropriate for an authoritative DNS server for the oreillynet.com subdomain. The actual top-level domains (i.e., .com, .net, .org, .int, etc.) in use on the Internet are delegated only to the mysterious 13 known as the root DNS servers. Even though your DNS servers won't be consulted by the rest of the Internet, it can be handy to set up your very own TLD that works only on your wireless network.

For example, suppose your wireless network uses the private 10.42.5.0/24 network. These machines aren't reachable directly from the Internet, and you don't really want to advertise their DNS information to would-be network crackers. Try a non-standard TLD:

zone "cat" {
        type master;
        file "data/cat";
        allow-transfer { 10.42.5/24; };
        allow-query { 10.42.5/24; };
};

(We actually use .cat on the NoCat Network in Sebastopol. If you've ever wondered where the cat went, now you've found it.) With this added to your zone file, set up a master record for .cat just as you would any other domain:

$TTL 86400
@       IN SOA  ns.cat. root.homer.cat. (
                2002090100      ; Serial
                10800           ; Refresh after 3 hours
                3600            ; Retry after 1 hour
                604800          ; Expire (1 week)
                60              ; Negative expiry time
                )

		IN NS           ns.cat.

ns		IN A		10.42.5.1

homer	IN A		10.42.5.10
bart	IN A		10.42.5.11
lisa	IN A		10.42.5.12

Reload the name server, and you should be able to simply ping homer.cat. If you'd like other name servers to maintain slave copies of your TLD, just add them as usual:

zone "cat" {
        type slave;
        file "db.cat";
        masters { 10.42.5.1; };
};

In this way, you can extend your new TLD across your entire private network architecture. Various network groups are using their own top-level and subdomain schemes as they come online. For example, SeattleWireless uses .swn, and I have .rob.swn delegated to my machine at home (10.15.6.1). How did I arrive at this number? And why would people in Sebastopol care about what I'm doing in Seattle? (Considering that a wireless link between the two is, well, quite improbable? Read on.)

7.9.2 Tunnels, Tunnels Everywhere

As we have discussed many times in this book, good wireless communication critically depends on having clean line of sight between two points. If there's an obstacle that you just can't go over, around, or through, then you simply can't have radio communications between those two points. Extremely long range (more than 40 miles or so) just can't be bridged in a single hop using the techniques and equipment described in this book. But suppose you are building out a community project that has a couple of pockets of wireless infrastructure that simply can't see each other. How can you build a large network that has a consistent address space if all of the points aren't directly connected by radio? If there is already an Internet connection at both points, then there is hope. One way to connect the unconnectable is to use the power of IP tunneling.

If you have never worked with IP tunneling, you might want to take a look at the Advanced Router HOWTO (http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/) before continuing. Essentially, an IP tunnel is much like a VPN, except that not every IP tunnel involves encryption. A machine that is "tunneled" into another network has a virtual interface configured with an IP address that isn't local, but exists on a remote network. Usually, all (or most) network traffic is routed down this tunnel, so remote clients appear to exist on the network as if they were local. A tunnel can be used to allow clients from the Internet access to private network services, or more generally, to connect any two private networks by using the Internet to carry the tunnel traffic.

If you want to perform simple IP-within-IP tunneling between two machines, try IPIP. It is probably the simplest tunnel protocol available, and it works with *BSD, Solaris, and even Windows. Note that IPIP is simply a tunneling protocol, and does not involve any sort of encryption. Here is one method for establishing an IPIP tunnel in Linux.

Before we rush right into our first tunnel, you'll need a copy of the advanced routing tools (specifically the ip utility). You can get the latest authoritative copy from ftp://ftp.inr.ac.ru/ip-routing/. Be warned, the advanced routing tools aren't especially friendly, but they allow you to manipulate nearly any facet of the Linux networking engine.

In this example, I'll assume that you have two private networks (10.42.1.0/24 and 10.42.2.0/24) and that these networks both have direct Internet connectivity via a Linux router at each network. The "real" IP address of the first network router is 240.101.83.2, and the "real" IP address of the second router is 251.4.92.217. This isn't very difficult, so let's jump right in.

First, load the kernel module on both routers:

  # modprobe ipip

Next, on the first network's router (on the 10.42.1.0/24 network), do the following:

  # ip tunnel add mytun mode ipip remote 251.4.92.217 local 240.101.83.2
     ttl 255
  # ifconfig mytun 10.42.1.1
  # route add -net 10.42.2.0/24 dev tunl0

On the second network's router (on the 10.42.2.0/24), reciprocate:

  # ip tunnel add mytun mode ipip remote 240.101.83.2 local 251.4.92.217
     ttl 255
  # ifconfig tunl0 10.42.2.1
  # route add -net 10.42.1.0/24 dev tunl0

Naturally, you can give the interface a more meaningful name than mytun if you like. From the first network's router, you should now be able to ping 10.42.2.1, and from the second network's router, you should be able to ping 10.42.1.1. Likewise, every machine on the 10.42.1.0/24 network should be able to route to every machine on the 10.42.2.0/24 network, as if the Internet weren't even there.

If you're running a Linux 2.2.x kernel, you're in luck: here's a shortcut that makes the advanced routing tools package unnecessary. After loading the module, try these commands:

  # ifconfig tunl0 10.42.1.1 pointopoint 251.4.92.217
  # route add -net 10.42.2.0/24 dev tunl0

And on the second network's router (10.42.2.0/24):

  # ifconfig tunl0 10.42.2.1 pointopoint 240.101.83.2
  # route add -net 10.42.1.0/24 dev tunl0

That's all there is to it.

If you can ping the opposite router, but other machines on the network don't seem to be able to pass traffic beyond the router, make sure that both routers are configured to forward packets between interfaces:

  # echo "1" > /proc/sys/net/ipv4/ip_forward

If you need to reach networks beyond 10.42.1.0 and 10.42.2.0, simply add additional route add -net lines. There is no configuration needed on any of your network hosts, as long as they have a default route to their respective router (they definitely should; it is their router).

To close the tunnel, bring down the interface (and delete it, if you like) on both browsers:

  # ifconfig mytun down
  # ip tunnel del mytun

Or, in Linux 2.2:

  # ifconfig tunl0 down

The kernel will very politely clean up your routing table for you when the interface goes away.

I am currently using IP tunneling to connect the NoCatNet project with SeattleWireless. Since we are organizing the use of the reserved 10 net space (see http://freenetworks.org/ for the ad hoc IP allocation chart), we know that IP addresses won't be reused. To date, we have successfully made Voice-over-IP phone calls and shared web and streaming music data over multiple radio hops, through a couple of IP tunnels (spanning California to Washington), and again over several more radio hops. While radio links are always best (in terms of low latency, high bandwidth, and low cost), IP tunnels can help make the impossible a reality.