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.
3.2.1 DHCPThe 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 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.
While a thorough dissection of DHCP is beyond the scope of this book, a brief overview is useful. A typical DHCP session begins when 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 listens for these requests and responds: "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." And the client, now armed with a little bit of knowledge, goes about its merry way. This model is shown in Figure 3-3.
Figure 3-3. DHCP lets a node get its network settings dynamically and easily
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, like IRC or "Quake III Arena"). Since DHCP lets a node discover information about its network, one can 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 admin's perspective, the magic isn't even 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 manages 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 sees 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 wireless gateway isn't capable of L2 bridging, don't worry. We'll cover setting up the ISC's dhcpd server in Linux in Chapter 5.
3.2.2 DNSMy, how different the online world would be if we talked about sending mail to rob@208.201.239.36 or got excited about having just been 64.28.67.150'd. DNS is the dynamic telephone directory of the Internet, mapping human friendly names (like oreillynet.com or slashdot.org) to computer friendly numbers (like the dotted quads above). 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 separate DNS for your wireless hosts, so that wireless nodes can easily provide services for each other.
3.2.3 NATIn 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 parceled 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 unexpectedly tremendous 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, 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 they 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 thoughtfully assigned, 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 model of a NAT configuration.
Figure 3-4. Using NAT, several computers can share a single "real" IP address
The IANA has reserved the following sets of IP addresses for private use (as outlined in RFC 1918, http://rfc.net/rfc1918.html): 10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
These are addresses that are guaranteed never to 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. As an added bonus, since the reserved IP address traffic isn't even routed over the Internet, you effectively get a free firewall for all of your NAT'd hosts.
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 fail on some NAT boxes. Another big disadvantage to NAT is that it effectively makes the Internet a readonly medium, much like television. If you can have only outbound traffic (to web servers, for example) and 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 like IRC and email, but it does preclude you from easily running services where Internet users connect to you directly (for example, running your own web server from behind a NAT isn't trivial).
Despite these drawbacks, NAT is an invaluable tool for allowing throngs of people to access Internet resources. In Chapter 5, we'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).
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 adrenaline 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.