A network can be as simple as a PPP dialup to an ISP, or as grandiose and baroque as a multinational corporate MegaNet. But every node on a multimillion dollar network in Silicon Valley needs to address the same fundamental questions that a dialup computer must answer: who am I, where am I going, and how do I get there from here? In order for wireless clients to easily access a network, the following basic services must be provided.
The days of static IP addresses and user-specified network parameters are thankfully far behind us. Using DHCP (Dynamic Host Configuration Protocol), it is possible (and even trivial) to set up a server that responds to client requests for network information. Typically, a DHCP server provides all of the information that a client needs to begin routing packets on the network, including the client's own IP address, the default Internet gateway, and the IP addresses of the local DNS servers. The client configuration is ridiculously easy and is, in fact, configured out of the box for DHCP in all modern operating systems.
 See http://rfc.net/rfc1533.html for an overview.
While a thorough dissection of DHCP is beyond the scope of this book, a typical DHCP session goes something like this: a client boots up, knowing nothing about the network it is attached to except its own hardware MAC address. It broadcasts a packet saying effectively, "I am here, and this is my MAC address. What is my IP address?" A DHCP server on the same network segment is listening for these requests, and responds with "Hello MAC address, here is your IP address, and by the way here is the IP address to route outgoing packets to, and some DNS servers are over there. Come back in a little while and I'll give you more information." The client, now armed with a little bit of knowledge, goes about its merry way. Figure 3-3 shows how this conversation takes place.
In a wireless environment, DHCP is an absolute necessity. There isn't much point in being able to wander around without a cable if you need to manually set the network parameters for whatever network you happen to be in range of. It's much more convenient to let the computers work it out on their own (and let you get back to more important things, such as IRC or "Quake III Arena"). Since DHCP lets a node discover information about its network, it's easy to get "online" without any prior knowledge about that particular network's layout. This service demonstrates a condition that network administrators have known for years: users just want to get online without knowing (or even caring) about the underlying network. From their perspective, it should just work. DHCP makes this kind of magic possible.
From a network administrator's perspective, the magic isn't terribly difficult to bring about. As long as you have exactly one DHCP server running on your network segment, your clients can all pull from a pool of available IP addresses. The DHCP server will manage the pool on its own, reclaiming addresses that are no longer in use and reassigning them to new clients.
In many cases, a wired network's existing DHCP server serves wireless users with no trouble. It will see the wireless node's DHCP request just as it would any other and responds accordingly. If your wired network isn't already providing DHCP, or if your access point isn't capable of Layer 2 bridging, then the access point itself will likely provide DHCP. I'll cover setting up DHCP services on a homebrew wireless gateway in more detail in Chapter 5.
My, how different the online world would be if we talked about sending mail to firstname.lastname@example.org, or got excited about having just been 188.8.131.52'd. DNS is the dynamic telephone directory of the Internet, mapping human friendly names (such as oreillynet.com or slashdot.org) to computer friendly numbers (such as the dotted quads mentioned previously). The Internet without DNS is about as much fun and convenient as referring to people by their Social Security Numbers.
Much like DHCP, your network's existing DNS servers should be more than adequate to provide name resolution services to your wireless clients. However, depending on your particular wireless application, you may want to get creative with providing additional DNS services. A caching DNS server might be appropriate, to reduce the load on your primary DNS servers (especially if you have a large number of wireless clients). You might even want to run dynamic DNS for your wireless hosts, so that wireless nodes can easily provide services for each other.
One handy use for DNS is to provide local top-level domains (TLDs) that don't normally resolve on the Internet, but direct people to local services. For example, the ad-hoc TLD of the NoCat network in Sebastopol is .cat, and the TLD for SeattleWireless is .swn. This allows for nifty names such as gateway.rob.cat or music.nodeone.swn. These addresses are not reachable by the Internet, but will resolve for anyone connected to the wireless network. I'll look at how various community network groups are extending TLD name service (and even connecting their networking projects via Internet tunnels) in Chapter 7.
In order for any machine to be reachable via the Internet, it must be possible to route traffic to it. A central authority, the IANA (Internet Assigned Numbers Authority, http://www.iana.org), holds the keys to the Internet. This international body controls how IP addresses are partitioned out to the various parts of the world, in an effort to keep every part of the Internet (theoretically) reachable from every other and to prevent the accidental reuse of IP addresses in different parts of the world. Unfortunately, due to the unexpected popularity of the Net, what was thought to be plenty of address space at design time has proven to be woefully inadequate in the real world. With thousands of new users coming online for the first time every day (and some large corporate users simply refusing to give up huge chunks of unused address space), the general consensus is that there simply aren't enough IP addresses to go around anymore. Most ISPs are increasingly paranoid about the shortage of homesteading space, and are loath to give out more than one per customer (and in many cases, they won't even do that anymore, thanks to the wonders of DHCP).
Now we see the inevitable problem: suppose you have a single IP address allocated to you by your ISP, but you want to allow Internet access to a bunch of machines, including your wireless nodes. You certainly don't want to pay exorbitant fees for more address space just to let your nephew get online when he brings his wireless laptop over once a month.
This is where NAT can help you. Truly a mixed blessing, NAT (referred to in some circles as "masquerading") provides a two-way forwarding service between the Internet and another network of computers. A computer providing NAT typically has two network interfaces. One interface is connected to the Internet (where it uses a real live IP address), and the other is attached to an internal network. Machines on the internal network use any of IANA's reserved IP addresses and route all of their outgoing traffic through the NAT box. When the NAT box receives a packet bound for the Internet, it makes a note of where the packet came from. It then rewrites the packet using its "real" IP address, and sends the modified packet out to your ISP (where it winds its way through the rest of the Internet, hopefully arriving at the requested destination). When the response (if any) comes back, the NAT box looks up who made the original request, rewrites the inbound packet, and returns it to the original sender. As far as the rest of the Net is concerned, only the NAT machine is visible. And as far as the internal clients can tell, they're directly connected to the Internet. Figure 3-4 shows a NAT configuration.
The IANA has reserved the following sets of IP addresses for private use (as outlined in RFC 1918, http://rfc.net/rfc1918.html):
These addresses will never be used on the Internet. As long as your internal machines use IP addresses in any of these three ranges, your traffic will not interfere with any other host on the Net.
NAT is handy, but isn't without its drawbacks. For example, some services may not work properly with some implementations of NAT. Most notably, active FTP sessions and some online games fail when running behind many NAT boxes. Another big disadvantage to NAT is that it effectively makes the Internet a read-only medium, much like television. If you can have only outbound traffic (to web servers, for example) but traffic from the Internet can't reach your machine directly, then you have no way of serving data and contributing back to the Net! This doesn't prevent you from using two-way services such as IRC and email, but it does preclude you from easily running on-demand services where Internet users connect to you directly (for example, running your own web server from behind a NAT isn't trivial, unless you're the one who controls the NAT).
Despite these drawbacks, NAT is an invaluable tool for allowing throngs of people to access Internet resources. In Chapter 5, I'll build a Linux gateway that will do NAT for you and handle almost every popular form of Internet traffic you care to throw at it (including active FTP). In Chapter 7, I will extend it even further, to try to get around some of the potentially antisocial aspects of NAT.
Of course, if you're lucky enough to have a ton of live IP address space, feel free to flaunt it and assign live IPs to your wireless clients! Naturally, most people (and, indeed, their laptops) are unprepared for the unbridled adrenal rush of using a live IP address without a firewall. But if you have that many real IPs to throw around, you must be used to living large. Just don't worry when you find your clients spontaneously rebooting or suddenly serving 0-dAy W@r3z. It's all part of the beautiful online experience.