| Each device on an IP network will need at least one unique IP address. Until you run your own network, you may not think very hard about how this works. You or someone from the IT staff most likely configured your computer at work to use a specified IP address or to use the company DHCP server, but the days when networks existed only at a few large universities and companies are behind us. Nowadays, there are small networks popping up everywhere. Computers and devices need to communicate. Your home may have a computer or two, a printer, a scanner, a digital camera, and a phone. You do not want to learn to be a network administrator just to get these devices to play nicely together, and there's no reason you should have tojust like there's no reason you should have to learn to be a car mechanic before you can drive a car. You will see even more of these small local networks connecting various devices pop up at homes, coffee shops, or while on a walk. If we are to standardize on IP for communication among devices, it needs to be easier for them to obtain IP addresses. Suppose you take a bunch of pictures with your digital camera and wish to print them, save them to your computer, or transfer them to a friend's. When you cable that digital camera to a printer or a hard drive, or you connect your computer to your friend's wirelessly, you don't really want to have to depend on a DHCP server being present, and you don't really want to have to configure each device manually with an IP address. You would like there to be an automatic configuration of IP addresses that provides each device with a unique address. In this chapter, we present three different ways in which a device may obtain an IP address: manual, DHCP, or self-assigned. As a motivating analogy, imagine that you want to enter a 65,000-seat auditorium to attend a networking lecture. At the moment, several seats are occupied. There are a variety of strategies that could be used: We could require that every student attending the lecture obtain a seat assignment in advance from an auditorium administrator. Each student arrives at the auditorium with a preprinted ticket and will refuse to sit in any seat other than his assigned one. If, by mistake, two students have been assigned to the same seat, then one of two things will happen. The first possibility is that if either of the two students behaves like Mac OS or Windows, one of the two students will leave the auditorium and complain to the administrator about the mistake. The administrator is expected to correct the mistake. The second possibility is that if both of the students behave like some other operating systems, a violent fistfight will ensue, not stopping until either at least one participant is dead or the human administrator intervenes and forcibly drags one or the other combatant (or both) from the auditorium against their will. This is analogous to manual address assignment. It is heavily dependent on the auditorium administrator never making a mistake. We could provide a ticket window. When each student arrives at the auditorium, she goes to the ticket window and requests a ticket. The ticket seller hands her a ticket for a seat that is supposed to be (as far as the seller knows) unoccupied. If the student finds some antisocial person already sitting in her seat, then rather than getting into a fight, she simply returns to the ticket window and requests a different ticket. This is analogous to using a DHCP server. This has some advantages over manual assignment but does require that we provide a ticket window and staff it. We could expect the students to find vacant seats for themselves. In this case each student arrives equipped with some kind of personal random-number generator, and each seat is equipped with a load sensor that can determine if someone is sitting there. Before entering the auditorium, each student uses the personal random-number generator to select some seat number at random. They then enter that number on a keypad outside the auditorium door. If the seat is occupied, a red light above the keypad illuminates and the student picks another random number and tries again. If, after a second or two, the red light has not illuminated, the student enters the auditorium and takes his seat. This is analogous to self-assigned link-local address assignment. Analogies between computers and day-to-day life generally should not be taken too literally, and this one is no exception. In this last analogy, it would seem that a student might have to try many times before finding a vacant seat. In reality, the density of usage of self-assigned link-local addresses is intentionally kept very low, for precisely this reason. Even though 65,000 addresses are available, it would be rare to have a single Zeroconf network with more than 1,000 hosts on it. In fact, 10 might be a more typical number, and the network could be as small as just two devices. Even in the extreme case of 1000 devices on a single Ethernet, still less than 2% of the available addresses would be in use, so a new device joining the network would have a 98% chance of finding a free address on the first try. This example is given for IPv4 link-local addresses, but IPv6 also has link-local addresses, and even more are available. With IPv6, there are 2118 link-local addresses (RFC 2462), which is more than 1035, so the chance of an address conflict is tiny.
As described in Chapter 1, the Zeroconf technique for obtaining a unique IP address is as simple as practically possible. Choose an IP address and check that no one else has already claimed it. If someone has, then choose another address. If the address has not yet been claimed, then claim and defend it. In this chapter, you will look at some of the details glossed over in this simplified description. |
