The Internet continues to grow at a frenetic pace. Each new machine increases the load on the Internet Protocol (IP) and DNS (Domain Name Service) infrastructure. Fortunately, both systems are holding up under the strain.

This column provides an overview of the goals and structure of these systems. (For more detailed information, see Steven Baker's "Net Worth" columns.) Next month, we will look at the registration process itself.

Internet Addressing

The Internet can be defined as a worldwide set of machines that are able to exchange packets of information on a (roughly) real-time basis. Two hierarchical addressing schemes, working in concert, provide unambiguous ways to specify recipients for packets.

Internet Protocol (IP) addresses provide unique addressing for every machine on the Internet, while providing the topological information needed to route packets to destination machines. DNS (Domain Name Service) host names provide mnemonic, location-independent names that are well-suited to use by humans.

Both of these schemes are administered in a distributed, hierarchical manner. This spreads out the administrative load, while retaining accountability and control.

Addressing and Routing

Before a machine can join the Internet, even temporarily, it must have an IP address. Currently, this is an unsigned 32-bit number, ranging from 0 to a little over 4 billion. This would seem to be a great plenty, but it is not.

Because IP addresses are used in the packet routing process, they cannot be allocated in a random fashion. Instead, they are divided up in a hierarchical fashion, much like telephone numbers. In the telephone system, country codes, area codes, and prefixes are used to route calls to limited sets of recipients. The remaining digits are then used to select a single line.

IP addresses are used in a similar fashion. Any address starting with 140.174, for instance, belongs to The Little Garden (TLG), my service provider. Any address starting with 140.174.42 lies within my local domain. If a packet can be routed successfully to TLG, local routers can get it to the correct machine.

Routing isn't much of a problem for leaf sites such as mine. Incoming packets get routed to the local network or possibly to a dial-in client machine. Any outgoing packet that isn't addressed to a local machine gets bounced up to the Internet.

The burden on TLG's routers is quite a bit more substantial. TLG has several interconnected links, each serving some number of client networks. In addition, TLG has multiple connections to the Internet as a whole.

When one of TLG's routers receives a packet, it must determine not only where to send it, but also the optimal route to use. Each router maintains a set of routing tables, showing the cost (in hops) to domains around the Internet, using assorted routes.

There are lots of Internet domains and a huge number of interconnections. Consequently, the routing tables are starting to get very large. This isn't an urgent problem, as yet, but the net.gods are keeping an eye on the situation.

Address Allocation

The hierarchical nature of IP allocation distributes the administrative load. Because TLG "owns" the 140.174 domain, it is free to give me the 140.174.42 sub-domain. Similarly, I am free to give out any numbers I like, as long as I stay within my sub-domain.

To allow room for expansion, IP addresses are allocated in blocks. My block, at 256 addresses, is larger than I'm ever likely to need. This keeps me from having to ask for additional allocations, reducing everyone's administrative overhead.

The name space is getting a bit crowded, however, and some large, sparsely used allocations are being asked to give up some territory. This helps for the moment, but eventually we'll have to move to larger IP addresses. If the net.gods do their magic right, most of this change will be invisible to ordinary net.citizens.

DNS Addressing

However well IP addresses work for machines, they are not well suited to use by humans. They are difficult to remember and their use in routing makes them inflexible and ill-suited for use in geographically dispersed organizations.

The DNS host name hierarchy was invented to solve this problem. My local network "owns" the DNS domains "cfcl.com" and "ptf.com", allowing me to allocate any desired names ending with these extensions. I can call any desired machine foo.cfcl.com, regardless of its IP address or geographic location.

I can also shuffle the topology of my local net, adjusting IP addresses as needed. Remote sites need not care what IP addresses I'm using, as long as the host names remain constant.

When a machine needs to resolve a host name, it first checks its own DNS information. If it cannot resolve the name locally, it asks another server for help. Conceptually, it's something like going up and then back down in an organizational chain of command.

Let's say an Australian machine needs to find foo.cfcl.com. First, it finds a server that knows about the "com" domain. Next, it finds a server that handles "cfcl.com". Finally, it gets an address for "foo.cfcl.com". Several machines may be involved, but no single machine needs to know about the entire name space.

Peculiarly, it's not always necessary that a DNS address be resolvable to an IP address. It is quite possible to set up a domain for mail forwarding only, letting some cooperative machine cache received mail until it can be forwarded appropriately.

This technique works well for machines that get their email via UUCP. It can also be used in situations where a machine only connects to the Internet on an occasional basis.