Vital Services
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.3.1 DHCP
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.
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.
3.3.2 DNS
My,
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 (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.
3.3.3 NAT
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):
- 10.0.0.0 to 10.255.255.255
- 172.16.0.0 to 172.31.255.255
- 192.168.0.0 to 192.168.255.255
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.
Sections
