How ARP Works & Why Duplicate Addresses Shouldn't Be Used

ID: Q93558

The information in this article applies to:

Microsoft LAN Manager, versions 2.1, 2.1a, 2.2

SUMMARY

This article describes the Address Resolution Protocol (ARP) described by RFC 826 and implemented in Microsoft LAN Manager's TCP/IP stack.

MORE INFORMATION

ARP, implemented as part of the IP layer in the network model, resolves IP addresses to physical network addresses. For instance, if machine "A" knows that machine "B" has an IP address of 11.1.9.223, and A wants to speak with B, the ARP mechanism is used to determine the physical address of B. The process works as follows.

Machine A casts a broadcast packet out onto the net as an ARP, with a question enclosed:

For IP address 11.1.9.223, what is the physical address?

Because an ARP is a broadcast, all machines on the net that are running IP receive this question into their software, then examine themselves to see if this IP address is their own. If so, they reply directly to the machine that posed the question:

My IP address is 11.1.9.223, and my physical address is 00DD01OF7AB5.

Machine A, hoping to save time and effort in the future, adds machine B to its ARPCACHE, which is a memory resident list of known mappings. In this manner, the actual ARP broadcast may be avoided the next time. Machine B adds machine A to its cache as well.

The ARPCACHE of machine A would appear similar to the following:


IP address          Physical address

11.1.9.223          00:DD:01:OF:7A:B5 <- The address just resolved
11.1.9.220          00:DD:01:07:57:15 <- Machine A's own address
11.1.255.255        FF:FF:FF:FF:FF:FF
11.255.255.255      FF:FF:FF:FF:FF:FF
255.255.255.255     FF:FF:FF:FF:FF:FF

The entry for 11.1.9.220 belongs to machine A, and in most implementations is considered a "static" entry that won't change dynamically. This is true for Microsoft LAN Manager as of version 2.2.

Don't Use Duplicate Addresses

Assume that machines A and B are holding a conversation. During that time, machine "C" boots up, using the same address as B. Here's what happens:

Machine C casts out an ARP when TCP/IP loads. The ARP says to all:

My IP address is 11.1.9.223, and my physical address is 080009123456.

At that time, what normally happens is that all hosts on the net put that mapping into their ARP cache, replacing the entry that was already there. They assume that machine B may have had the network adapter changed to one with a new address. The ARPCACHE on A now shows:


IP address          Physical address

11.1.9.223          08:00:09:12:34:56 <- Now points to machine C
11.1.9.220          00:DD:01:07:57:15
11.1.255.255        FF:FF:FF:FF:FF:FF
11.255.255.255      FF:FF:FF:FF:FF:FF
255.255.255.255     FF:FF:FF:FF:FF:FF

At this point, any frames sent from A to B goes instead to C, causing a rude disruption of the earlier conversation. Machine B usually hangs as a result, and machine C cannot deal with the incoming stream of session packets for which there is no session.

When administering an IP network, it is IMPERATIVE that IP addresses are assigned in such a way as to guarantee they are unique. Serious network disruption can result otherwise. One of the most reliable methods for assigning unique addresses is to print a range of addresses on stickers, then dole out the stickers to departments or individuals to use as they add machines to the net. This is the method used at Microsoft.

Additional query words: 2.10 2.1 2.10a 2.1a 2.20 2.2

Keywords : kbnetwork
Version : :2.1,2.1a,2.2
Platform :
Issue type :