Section 2.1. Obtaining an IP Address

2.1. Obtaining an IP Address

There are two components to choosing an IP address for a given network. You need to find a legitimate address and you need to confirm that you are the only one using this particular address on this network. A network administrator can manually assign your IP address. In this case, the administrator is responsible for ensuring the assigned address is available and unique. If there is a DHCP server configured for your network, you can use it to obtain a unique IP address. Zeroconf allows you to automatically select an IP address in the absence of a DHCP server or network administrator.

2.1.1. Manual Assignment

Whatever your platform of choice, there is usually some way to configure your network settings by hand. Often, there is a GUI that makes it easy for you to enter your IP address, subnet mask , and gateway/router information. In Mac OS X 10.4, you either select Network after choosing Apple Menu System Preferences...or by selecting the Apple Menu Location Network Preferences...item.

2.1.1.1. Entering an IP address

In the example shown in Figure 2-1, the IP address 192.168.1.123 has been selected. For now, this discussion is limited to IPv4 addresses. These are 32-bit values that are usually written as four positive integers, each between 0 and 255, separated by dots. This familiar format is known as dotted decimal.

Figure 2-1. Assigning an IP address manually

The second number that you enter is the subnet mask. This is also a 32-bit number and is used to indicate which portion of the IP address contains information about the network and which portion contains information about the host. The network information corresponds to those bits that are turned on in the subnet mask. In the example shown in Figure 2-1, the first 24 bits are on and the last 8 bits are off. You can also represent the information contained in the IP address and subnet mask fields together by writing 192.168.1.123/24. The forward slash and the 24 at the end indicate that the first 24 bits are reserved for the network information, so the remaining 8 bits are for the host information. The host uses this information to determine how to deliver IP packets. When sending a packet, the host checks the network number (the first 24 bits, in this example) in the destination address, and if that exactly matches the network number in its own address, that means that the destination is on the same subnet and the packet is sent directly to the destination machine. Otherwise, the destination is not on the same subnet, so the packet is sent to the default gateway for forwarding on to its eventual destination.

The third number you enter is your local router or gateway. This is the router's address within your subnet. In other words, within the 256 possible 32-bit addresses that begin with 192.168.1, the router has host address 1 and the machine currently being configured will have host address 123. The router also has an IP address on its upstream interface connecting to the rest of the Internet. Whenever your machine wants to communicate with a host that it can't reach directly (see the sidebar "Link or Subnet?"), it needs to send the packet to the router, which will forward the packet on to its eventual destination. A certain kind of router, called a Network Address Translation (NAT) router, will also rewrite the packet header while forwarding it, to make it appear that all packets actually originate from its single external IP address. This allows several hosts to appear to share a single public IP address, but header rewriting is not a perfect technology, and hosts that are stuck behind a NAT router are limited in the things they can do. Web browsing, email, and a few other things work, but there are many less well-known IP applications that do not survive header rewriting and cannot be used by hosts stuck behind a NAT router. Technology to overcome this limitation is described in Chapter 5, in which we discuss service discovery beyond the local link.

There are other numbers not shown in Figure 2-1 that you may also need to enter. For example, if you want to resolve URLssuch as http://www.oreilly.comto their corresponding IP addresses, you will need to have the address of one or more DNS servers. You will learn more about DNS in Chapter 3.

2.1.1.2. Choosing an IP address

If an IP address is to be entered by hand, this address should be obtained from a network administrator. The administrator will know which subnets have been set up and which IP addresses are currently available on each. A central authority is responsible for assigning the addresses and avoiding conflicts. The example shown in Figure 2-1 is fairly typical for a home or otherwise small network with a single, external (and possibly dynamic) IP address. Some operating systems will display a message if you try to assign an address that is already in use. Figure 2-2 shows an example of an address conflict message.

Link or Subnet?

Computer networking professionals often use the terms link and subnet interchangeably, which is not always accurate.

A link is a physical-layer concept. Using Ethernet as an example, when you send an Ethernet broadcast, all the devices that receive that broadcast are on the same link.

A subnet is a network-layer concept. A subnet is a range of IP addresses that are all mutually reachable from one another, directly, without going through a router.

In an ideal world, there would be an exact one-to-one correspondence between links and subnets. However, as new computers are added, sometimes all the available addresses in a subnet are exhausted. At this stage, the right thing to do might be to enlarge the subnet, but that would involve changing the subnet mask on all the existing machines, which could be something of a hassle. Because of this, network administrators will often just add a second IP subnet to the same Ethernet, so that there are two IP subnets on the same link. This means that when a computer in subnet A sends a packet to a computer in subnet B, it could, in principle, send it directly, but it doesn't know that. When it consults its routing table, it finds that the destination is not in its subnet and sends the packet to the router for forwarding. The router does know that both subnets are on the same link, so it turns the packet around and sends it back on the same Ethernet to its destination. This is obviously inefficient, in terms of both network bandwidth and utilization of router resources, but it is nonetheless more common than it should be. One solution to this problem is provided by RFC 3442, "The DHCPv4 Classless Static Route Option," which allows a DHCP server to tell the clients that they have more than one subnet that's directly reachable without going through the router, but it may be many years before RFC 3442 is widely implemented and deployed.

If a link can have more than one subnet, is the converse true? Can a subnet span more than one link? Generally, the answer is no. When a device wants to send an IP packet to a destination address on the same subnet, then instead of sending the packet to a router for forwarding, it broadcasts an IPv4 ARP (or IPv6 Neighbor Discovery) packet asking "Who has this address?" and waits for the response, then sends the IP packet directly to the recipient as the payload of a link-layer packet. The prerequisite for this to work is that both the link-layer broadcast and the subsequent link-layer unicast have to reach the relevant host, which means that for practical purposes, it has to be on the same logical link.

In addition to preventing you from accidentally entering an existing address, this also helps a network administrator identify a device causing a conflict. The hardware information can be used to lock this device off the network if it is being improperly configured.

In many cases, when you are running a small network, you will be happy to have IP addresses assigned by DHCP. There are, however, times when you will want to

Figure 2-2. In-use message

manually set an address. The best example of this is a DNS server. Normally, it is best to access hosts and services by name, using a name server. However, the one service you can't look up by name is the name server itself, since you can't send it DNS queries to map names to addresses unless you already know its IP address.

Another example is an old legacy printer. Strange as it may seem today, there was a time when printer vendors actually sold network printers that didn't have Bonjour/Zeroconf. These printers usually did include a DHCP client, so they could be configured to get an address from a DHCP server, but it's not clear why. If you set the printer to use DHCP, you would probably end up being unable to use it because you wouldn't know what IP address the DHCP server had assigned to it. For this reason, these printers were more commonly used with a fixed, manually assigned, static IP address. If you have one of these old pre-Bonjour IP printers, then to print on it you need to tell the computer what IP address you manually configured into the printer, as shown in Figure 2-3.

Figure 2-3. Manually configuring IP printing

Configuring the printer with a fixed, manually assigned, static IP address means that even after a power outage, when the printer powers back on, you know it will come back with the same IP address it had before.

Hardcoding an IP address is labor-intensive and error-prone. If you ever need to change the address of the printer, every computer has to be updated to use the printer's new IP address. Using Zeroconf, you can discover what printers are available on the network, pick one, and then subsequently access it by name, even if its IP address changes.

2.1.2. Using DHCP

You can obtain an IP address from a Dynamic Host Configuration Protocol (DHCP) server if one exists on your network. The basic idea is that there is a pool of addresses that can be assigned by the DHCP server. The server is responsible for allocating the addresses in its pool so that each active requestor has a unique and valid IP address.

2.1.2.1. DHCP-provided address

A DHCP server can be configured so that you specify the number of addresses available to be served, as well as the starting address for the block. In Figure 2-4, you see the web-based user interface to a typical low-host home gateway product that includes a DHCP server. In this case, the home gateway has been configured to be responsible for the 40 IP addresses beginning with 192.168.1.151.

Figure 2-4. DHCP server configuration

You can view the DHCP clients table to see a snapshot of the IP addresses currently managed by the DHCP server. Figure 2-5 shows light use by five devices. Note that the DHCP Server IP Address is the address we saw before for the router. For each device in the table with a name, the name is displayed.

The hardware address is also displayed in this table, in the column headed "MAC Address." In this case MAC, is not an abbreviation for Macintosh but rather an acronym standing for Medium Access Control. The Medium Access Control is the part of the software or firmware responsible for controlling access to the physical transmission medium. In the case of Ethernet, the MAC address is therefore the Ethernet

Figure 2-5. DHCP Active IP Table

address, and with Ethernet being the predominant networking medium in use today, many people use the terms MAC address and Ethernet address almost interchangeably or the generic term "hardware address." In the warning message illustrated in Figure 2-2, it is the MAC (or Ethernet) address that is shown to help identify the device currently occupying the desired address.

The Dynamic Host Configuration Protocol is specified in RFC 2131. Broadly speaking, it can treat clients in two ways. One way is to treat clients anonymously, handing out available IP addresses on a first-come, first-served basis to any client that asks for one. This is the easiest and most common way of using DHCP. A DHCP server can also be configured to hand out a specific IP address and other per-client specific configuration parameters to clients it has been programmed to know about in advance. The DHCP server can identify clients by their MAC address or by the Client ID supplied by the client. Note that there is usually no security associated with thisany impostor can impersonate a known client simply by putting that client's hardware address and/or Client ID in the DHCP request packet.

A client requests the use of an IP address for a specific length of time. The client can renew and extend the lease at any time. If the lease is not renewed before it expires, then the DHCP server returns that address to the pool of available addresses. RFC 2131 explains how DHCP allocates addresses to hosts for some period of time:

The basic mechanism for the dynamic allocation of network addresses is simple: a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a lease. The client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the client has been retired.

Most DHCP servers allocate addresses sequentially, as can be seen in Figure 2-5, though RFC 2131 allows servers to allocate addresses in any order they choose. When a server has been running for a while and all addresses have been used at least once, it is common for the server to allocate a new client whichever address has been unused for the longest time.

Figure 2-6 shows a Macintosh configured to use DHCP. Note the text field for the user to enter the DHCP Client ID. Most of the time, there's no need to enter anything here. Also note the button Renew DHCP Lease. There is almost no occasion when clicking this button has any effect. Whenever your DHCP lease is close to expiring, the computer renews it for you, automatically. Any time your computer wakes from sleep, it automatically checks that its lease is still valid and gets a new one, if necessary. Any time you connect an Ethernet cable or join an AirPort network (if the interface is set to use DHCP), it automatically does everything necessary to get a valid lease for that network. If there's a working DHCP server on the network, then you'll already have a valid lease; if there isn't, then clicking the Renew DHCP Lease button won't help. However, Microsoft Windows 98 didn't do things like this automatically and, instead, made the user click a button. Because Windows had a button to click, customers insisted that Mac OS X have one too, even though on the Mac it isn't necessary and doesn't really do anything.

Figure 2-6. Dynamic allocation of an IP address with DHCP

2.1.2.2. DHCP with manual addresses

Another mode that DHCP supports is where the host has a manually configured IP address, but other networking parameters (subnet mask, router address, DNS server address, etc.) are obtained from the DHCP server. Most operating systems support this mode, though it is not widely used. Figure 2-7 shows a Macintosh configured to use DHCP with a manual address.

Figure 2-7. Using DHCP with a manual IP address

As before, you are responsible for managing any address that you manually assign. If appropriate, you should check with a network administrator before handing out an address.

Private IP Addresses

If you run a router at home, the address 192.168.1.1 may be familiar. This is often the default for the local area network (LAN) IP address for such a device. If you run a wireless network using Apple's AirPort, the default address is 10.0.0.1. These are popular choices because these addresses should never be used by any host on the "public" Internet. These addresses are reserved for private , internal network use. Thousands or even millions of hosts and devices may all use the IP address 192.168.1.1, but since they never try to communicate with one another, it doesn't matter that they all have the same address. Some of the IP addresses listed in RFC 3330 as being reserved for local private use are:

• 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

• 169.254.0.0 to 169. 254.255.255

This last set of numbers is the range that Zeroconf uses when no DHCP server is available.

2.1.3. Zeroconf Selection of IP Address

In the case of DHCP or manual selection, there is assumed to be some sort of central authority for policing the allocation of IP addresses. With DHCP, there is a pool of available addresses, which that authority is allowed to manage. With manual configuration of IP addresses, it is assumed that the person performing the assignment is authorized and competent to do so. With Zeroconf, the selection of addresses is done in a distributed manner. Each device is responsible for choosing its own address and then verifying that it can use the selected address.

2.1.3.1. Link-local range

In the sidebar "Private IP Addresses," you saw the four ranges of IP addresses that are officially reserved for use on local networks not connected (or not fully connected) to the worldwide public Internet. The first three ranges, described in IETF RFC 1918, are known as the private use IP address ranges, and the fourth, described in RFC 3927, is known as the link-local address range.

You may have had the experience of thinking you have a working connection to the global Internet when, in fact, you don't. You are configured to use DHCP to obtain an IP address, but what you get is something like what is pictured in Figure 2-8, an address that starts with 169.254. In the early 1990s, if your computer got no response from the DHCP server, you would fail to get any working networking at all. Since 1998, though, Macs and Windows machines have at least configured a link-local address if they couldn't get anything better. Although this address is no use for global communication, it is good enough for local communicationsay, to print a document. Perhaps more importantly, this address is good enough for local communication with a faulty DHCP server, so you can connect to it with your web browser and correct whatever misconfiguration or other error was preventing it from handing out IP addresses. Without the ability to do at least local network communication, you can end up in a Catch-22 situation: you need to connect to your home gateway to correct its DHCP server configuration error, but you can't because it hasn't assigned you an address. Automatic self-assigned link-local addresses, which are guaranteed to work even when everything else has failed, provide the solution to that dilemma.

Figure 2-8. Self-assigned IP address

In fact, not all of the range of 169.254.0.0 to 169.254.255.255 is available for general use today. The first 256 and last 256 addresses have been reserved for future use and what is left are the 65,024 addresses in the range from 169.254.1.0 to 169.254.254.255. Link-local addressing is not designed for cases in which you need all 65,000 addresses. If you have 65,000 computers and other network devices, then you really need a paid (or unpaid) network administrator who knows how to run a network that large. Link-local addressing is intended for two main scenarios: for tiny ad-hoc local networks where communication is desired without the overhead of setting up a DHCP server, and to provide a minimum safety-net level of service on networks where there's supposed to be a DHCP server but it's failed. Because no central authority is maintaining a list of available addresses, a device joining the network must handle possible conflicts with all of the existing hosts. Link-local addressing is primarily intended for networks of 2 devices, 10 devices, or perhaps even 100 devices, though analysis in RFC 3927 shows that even on a network with over 1,000 devices, it still works reasonably well:

A host connecting to a link that already has 1,300 hosts, selecting an IPv4 link-local address at random, has a 98% chance of selecting an unused IPv4 link-local address on the first try. A host has a 99.96% chance of selecting an unused IPv4 link-local address within two tries. The probability that it will have to try more than 10 times is about 1 in 10¹⁷.

However, just because it works reasonably well for networks with over a thousand devices doesn't mean that it's recommended to have a network that large without any kind of administration.

2.1.3.2. Choosing a link-local address

You now know the range of numbers in which you are allowed to choose your address. With possibly many independent devices choosing their own IP addresses independently, a strategy should be devised to minimize the number of tries each device will have to make, on average, to obtain a locally unique address. If you have already been connected to a particular network with a link-local address, then a good strategy is to try to use that address again. This depends first on the ability to retain this information while shut down, asleep, or otherwise off the network.

There is, of course, no guarantee that the previously used address will still be available. In situations where the same devices tend to be present on the same local network and this strategy is adopted by all devices, the process of obtaining unique IP addresses for all should go quickly and smoothly. As a human analogy, students in university classes tend to sit in roughly the same location class after class, even in cases where their seat location is not assigned. If, midway through the term, someone sits in another student's accustomed place, then that student has to find somewhere else to sit. It's not a major problemnormally the only effect is that the start of the class could be delayed by a few seconds while the student selects a new place to sit. In the auditorium example at the beginning of the chapter, there would be fewer conflicts if attendees agreed that, next time, they would request the same seats that they occupied at the previous event.

If the previously used address is now found to be in use on this network, then the host chooses a new one at random. Computers use pseudorandom-number generators, which means that the numbers they produce seem random but really they are quite deterministic. Because of this, it's important that the algorithm is chosen so that different machines each start with different initial values, so they don't proceed through the exact same sequence of pseudorandom numbers, conflicting with their neighbors on every single try. Deriving the initial value from the computer's Ethernet address is a good idea, since all computers (are supposed to) have different Ethernet addresses.