Section 2.2. Claiming a Link-Local IP Address


2.2. Claiming a Link-Local IP Address

You do not have the right to use the address you have selected until you test that no one else on the network is already using it. In Figure 2-9, you see the output captured by Ethereal as the machines foo and dimsumthinking try to build a local network.

Figure 2-9. ARP probes on generating Zeroconf addresses


Each machine first picks an address it thinks it would like to use. The machine dimsumthinking has chosen 169.254.187.245. It then sends some Address Resolution Protocol (ARP) requests asking for the MAC address that goes with 169.254.187.245. ARP is the protocol that's used when a computer wants to talk to another machine on the local network. The computer knows the IP address it wants to talk to but not the Ethernet/MAC address of the machine with that IP address, so it broadcasts an ARP request asking for that information. In this case, we're using ARP slightly differently: we're sending an ARP request for our own address and hoping that we actually don't witness anyone else respond to that request. If someone answers, that means they already have the address, so we can't.

Note that, in the Tell section, the address is 0.0.0.0 because dimsumthinking is not yet asserting that it owns that address. These are ARP probes. After a couple of seconds without receiving any reply, dimsumthinking concludes that no one is using the address, so it may proceed to use it. dimsumthinking then sends out a couple of ARP announcements. Ethereal displays these in the "Who has" format, but in reality they are statements, not questions. The "Tell 169.254.187.245" section is saying, "I am 169.254.187.245."

Later in the trace, around the 26-second mark, dimsumthinking wants to communicate with foo.local. It sends an ARP request, saying "Who has 169.254.186.86? Tell 169.254.187.245," and foo replies with an ARP reply, saying "IP address 169.254.186.86 is at MAC address 00:03:93:ef:c4:8c."

We cover this process in more depth next.

2.2.1. Probing for Address Availability

Once a host has selected a candidate address, the next task is to check that no other host is either currently at that address or seeking to occupy that address. The mechanism for exchanging information about IP addresses and the devices using them is the ARP, which is is described in the IETF RFC 826. In this section, you will take a quick look at those parts of ARP that are needed for link-local addressing and see how ARP is used to probe for an available address.

2.2.1.1. Address Resolution Protocol

You saw that each device (normally) has a unique MAC address. A single device may have more than one IP address and may also have addresses that change over time. When you send an IP packet to another device on the same Ethernet, you send it directly, in an Ethernet-level packet addressed directly to the recipient, but Ethernet packets need Ethernet addresses, and you don't yet know the Ethernet address of the recipient. The ARP protocol exists to solve that problem. You broadcast an ARP request asking what Ethernet address to use to reach your desired IP address, and the device that knows the answer sends an ARP reply telling you. The format of an ARP packet is shown in Figure 2-10. ARP requests and ARP replies use the same packet format; the Opcode field indicates if it is a request or a response.

Figure 2-10. Probing for address availability


The Sender MAC and IP addresses serve as an assertion: this is my MAC address; this is my current IP address.

The Target MAC and IP addresses serve as a question: who has this IP address? The Target IP address is specified, but the Target MAC is always all zeros in an ARP request because the sender doesn't yet know it.

When you broadcast an ARP request and get an ARP reply back, you store the Sender MAC and IP addresses in your ARP cache, so the next time you need to know what MAC address goes with that IP address, you'll already have that information at hand.

2.2.1.2. How to probe

Because ARP is used to look up IP addresses anyway, it's the natural way to tell if an address is in use. If the machine foo wishes to probe the address 169.254.186.86, it broadcasts a series of ARP requests such as the one represented in Figure 2-10. RFC 3927 recommends that the host send three probe packets spaced one to two seconds apart, though other numbers and intervals could work, too.

As you can see in Figure 2-10, the Sender MAC address information is included in the ARP probe while the Target Mac address is set to all zeros. The Target IP address contains the dotted decimal of the address the host is inquiring about while the Sender IP address is all zeros. An ARP request with all zeros for the Sender IP address is known as an ARP probe. You must not fill out the Sender IP address with the address you are hoping to claim, because some other device may already have legitimately claimed it. If you put your desired IP address as the Sender IP, then other hosts on the network will update their ARP caches and send those packets to you instead of to the legitimate holder of that IP address.

2.2.1.3. Results of probing

The purpose of the ARP probe is to determine whether or not a device can claim a particular address. Remember that, for small networks, there is a high probability that a randomly selected address will not collide with existing addresses. So what could go wrong?

  • Another host might be trying to claim the same address at the same time. What indicates this is an ARP probe for the same Target address from a different host. Determining whether or not this is the case is why it is necessary to include the Sender MAC address in the probe. Suppose, while probing, you receive an ARP probe for the same Target address. If the Sender MAC address is different, then someone else wants the same address that you want. If the Sender MAC address is your own, then there is no conflict. There are various reasons you might see your own probes. For example, you might have Ethernet and 802.11 wireless active, but (unknown to you) they are both bridged together, so every time you sent a broadcast on 802.11, you see that same packet arrive milliseconds later on the Ethernet interface.

  • Another host has already claimed the same address. In this case, the host will receive your ARP request asking about the specified Target IP address, and it will respond to you with an ARP reply asserting ownership of that IP address, exactly as specified in RFC 826 way back in 1982. Receiving any ARP packet (request or response) with your desired IP address specified as the Sender IP address indicates that someone else is already using that address.

If, after a few ARPs, no conflicting responses have been received, the host has claimed the address and can proceed to announce this fact. If a conflict is detected, then the host chooses another address and begins the probing process all over again.

2.2.1.4. When to probe

Notice that, when you probe, you are asking any device that can receive your message whether the address you want is available. This implies that any time you are not able to receive such a probe, you cannot be sure that someone else has not claimed your address. Any time your network interface becomes active after a period of inactivity, you need to go through the process of trying to claim the address again.

You certainly have to probe any time your device starts up or is rebooted. If your network interface does not remain active while your device is asleep, you must probe on waking up. You must also probe if you bring up an inactive network interface, either by attaching a cable, associating with a new wireless base station, or by changing your network settings to activate a particular interface.

2.2.2. Announcing

At this point, your host has finished probing and is ready to announce its claim of that IP address. The announcement is important because, moments before you arrived, some other (now departed) host may have been using that IP address. Other peers on the network could have that old IP address/MAC address mapping in their ARP caches, and when they try to communicate with you, they will send their IP packets (unsuccessfully) to the wrong MAC address. By broadcasting an ARP announcement, we ensure that all those old stale ARP cache entries are updated to point to your MAC address instead, since you are now the new legitimate holder of this IP address. You may observe that the chances are vanishingly small of there having been some other host using the same IP address just moments before you arrived. This is true, but the purpose of Zeroconf is to provide high reliability, so we want to make sure that even this rare case is handled correctly. We want a protocol that works correctly all the time, not just almost all the time.

2.2.2.1. Announcing your address

You have chosen your address and determined that no other device is probing for the same address or has already claimed it. You have claimed the address and must now broadcast this by sending two ARP requests two seconds apart. The requests are similar to those shown in Figure 2-11.

Figure 2-11. Claiming a link-local address


As before, the Sender MAC address is included along with the Target IP address. This time, to indicate that the address has been claimed, the Sender IP address is set to the value of the claimed address. The Target MAC address is still set to all zeros, as always for an ARP request, and the Target IP Address is the same as the Sender IP address. The two effects of sending this ARP announcement are that any hosts simultaneously probing for this same address will realize they need to choose a different address, and all the other hosts on this link will update any stale ARP cache entries to reflect this new information.

2.2.3. Defending Your Address

Devices can join and leave the network and try to claim addresses at any time, so the process of address conflict detection is ongoing. When a new host joins the network, if its randomly chosen address happens to be our address, when it sends its ARP probes, our host will answer them, informing the new host that its desired address is already in use and it should choose another. There's nothing special about answering ARP probes. An ARP probe is just a certain kind of ARP request, and hosts are answering ARP requests all the time anyway, as part of the normal process of IP networking.

2.2.4. Late Conflicts and Misbehaving Peers

As described so far, the process works perfectly well. As long as all the hosts follow the rules, each will assign itself a unique address.

But what if some hosts don't follow the rules? What if some hosts have software or hardware bugs that mean they don't perform probing properly? What if two hosts do perform probing properly on two separate unconnected Ethernet segments (so, at the time, there's no harm in them both assigning themselves the same address), but then, without either host's knowledge, those two Ethernet segments are later connected together? What if a human user decides to manually assign a 169.254.x.x address on a device that doesn't implement address conflict detection for manual addresses? Or does it on a device that does implement address conflict detection for manual addresses, but the human user, for some reason, has disabled that address conflict detection?

The usual reaction to these issues is just to call them errors, out-of-scope for this protocol. If devices have bugs, the bugs should be fixed. If a human user is guilty of willful malice, then the human user should be dealt with. The Zeroconf philosophy goes beyond this typical response, though. Certainly, these situations should not arise, but if they do, is there anything we can do about them?

The answer is that when a device observes an ARP packet sent out from another machine claiming to have the same IP address, RFC 3927 specifies that the device may send, at most, a single ARP of its own, reasserting its claim on that address; if the other machine doesn't back down, then the device MUST give up its address and select another. Many people recoil against this notion. They feel that if they claimed the address, fair and square, then it's theirs and they shouldn't have to give it up, and it's the other machine that should change. The problem is that if both devices are programmed to behave this way, then neither will select a new address, and they will just continue to fight indefinitely. Meanwhile, until they get the address conflict resolved, neither device can do any useful networking.

Two devices fighting over the same IP address is like two people in a half-empty cinema fighting over the same seat. They can either sit in different seats and enjoy the film, or they can spend the entire time continuously punching each other, in which case, neither will get to see any of the film and they'll disrupt the people around them too.

The analogy of someone trying to make you move to another seat is the way many people think of the situation, and while it's accurate to an extent, such anthropomorphization of computer situations often leads people to incorrect conclusions. As a person, if you were sitting in a half-empty cinema enjoying a film and, halfway through, some thug came and hit you, then quietly moving to another seat might seem like a weak, cowardly response. The manly thing to do would be to stand your ground and refuse to move. Computers are not people, though. They have no feelings or ego. A computer programmed to meekly select a new address is not going to feel bad about it. If, instead, the computer were programmed to fight forever, then it would do just that. It would fight forever, without any regard for the consequences or benefits. Two computers programmed to fight forever over the same IP address would do just that. Neither could do anything to stop the other from trying to use the address; neither would give up trying to use the address itself. Neither would succeed in achieving anything except causing disruption on the network. They would just sit there shooting ARP packets at each other without limit, flooding the network and consuming CPU time on all the other hosts on the network, until some human intervened to stop them. This is where the human user would encounter the serious problem: if the only user interface to these devices is via a configuration page that you view via a web browser, and neither device was able to achieve stable networking, then that could make it very hard for a human to fix the misconfiguration.

The other mistake that anthropomorphization frequently encourages is the notion that a particular link-local IP address is something worth fighting over. What people don't realize is that after a few seconds of address conflict, there's nothing left worth saving. When another host broadcasts an ARP claiming your IP address, peers on the network update their ARP caches. Subsequent TCP packets go to the wrong host, which, having no record of that TCP connection, responds with a TCP RESET packet. After this point, continuing to fight over the address would be futile. The connections are all gone. It's too late to save them. It's a bad situation and it shouldn't happen, but if some thug does come and stomp on your IP address, the most productive thing for a computer to do is get a new, untainted address and get on with life, not waste time fighting over the old, dead one.

The way Zeroconf detects and handles this is by passive observation of the ARP broadcast packets it receives anyway. Every ARP packet includes the sender's MAC address and (claimed) IP address. Consider the case of your host, with IP address 169.254.187.245 and MAC address 00:03:93:ef:c4:8c, receiving the ARP packet shown in Figure 2-12. The sender of the ARP packet is seeking to communicate with IP address 169.254.186.86 and wants to know its MAC address. However, the sender of the ARP packet is also asserting that it owns IP address 169.254.187.245 (which is yours) with MAC address 00:03:65:15:e4:33 (which is not yours, so you know this probe didn't originate from your machine). This is a conflict and needs to be handled.

Figure 2-12. Conflicting ARP packet


RFC 3927 allows a machine to handle a conflict in one of two ways:

  • It can gracefully back down and let the other host have the address. It picks a new address and begins the probing process all over again.

  • If it has open TCP connections that it doesn't want to lose, then it can respond by broadcasting a single ARP announcement asserting its own ownership of that address. However, if this doesn't solve the problem, then it must back down and let the other host have the address. There's nothing to be gained by two hosts getting into a fistfight over an address. When two hosts think they have the same IP address, any open TCP connections are not likely to survive for long, so, pretty soon, the thing the hosts were each fighting to preserve will be gone anyway.

The first option, making an immediate change, ensures that the conflict is resolved as quickly as possible. The host issuing the conflicting ARP packet will most likely keep its IP address and your host will make a change. If your host has an active TCP connection, it may prefer the second option, as that gives it a chance of maintaining its IP address and forcing the other host to change.

If your host decides to defend the IP address, then the ARP announcement it broadcasts is received by the other host as a conflicting ARP packet. The other host then has the same two options: choose another address or try to defend the current one. But what if the other host will not yield? Then the other host sends out its single ARP request defending its address and now your host receives a second conflicting ARP packet. Now you've received two conflicting ARP packets in a row, in a short window of time, and the protocol specification leaves your host no choice: it must relinquish that address and pick another.

Another case mentioned before occurs when two previously separate networks are bridged together. In this case, neither host is really to blamethe network environment just changed around them. This is harder to detect because the individual hosts generally do not even know that the bridging has occurred. One solution that's occasionally suggested is to have all hosts periodically broadcast ARP packets giving their IP addresses, so that each host can detect when some other host thinks it has the same IP address. This is not a good idea because it would be a huge, ongoing waste of bandwidth, even when hosts are otherwise quiet and not communicating, to solve a problem that, in fact, occurs so rarely that many network protocol designers would be content simply to ignore it. The more lightweight solution adopted by RFC 3927 is simply to have hosts send ARP replies by broadcast instead of unicast, so that the hosts all get to see what one another are saying and can passively observe if another host asserts ownership of the same IP address. Since every unicast ARP reply would normally be sent in response to a broadcast ARP request, this can be viewed as just a little more broadcast traffic at a time when there was broadcast traffic anyway. Periodic announcements would be additional broadcast traffic at times when there was, in fact, no need for any broadcast traffic at all.

When considering these issues, it is important to remember three things:

  • The problems of late conflicts, network topology changes, and buggy or misbehaving hosts are exceedingly uncommon. AppleTalk had no mechanism to detect these kinds of problems and was used successfully for two decades. Zeroconf is simply being held to an even higher standard, where even these obscure situations should be handled gracefully, too.

  • With 65,000 addresses available, the chance of conflict is small. Even if two large 100-host networks are joined, there's still a better than 75% chance that not a single host on either network will suffer a conflict.

  • Link-local addressing is designed for the case where no alternative is available, or the alternative has failed. In some sense, even if link-local addressing were to be unreliable or not work very well in all cases, that is still better than the alternative, which is no functional networking at all. Often, all that is required is that link-local addressing work long enough for the network administrator to communicate with the DHCP server to fix it.




Zero Configuration Networking. The Definitive Guide
Zero Configuration Networking: The Definitive Guide
ISBN: 0596101007
EAN: 2147483647
Year: 2004
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net