Chapter 3: Address Resolution Protocol (ARP)
ARP is described in RFC 826, which can be found in the \RFC folder on the companion CD-ROM.
The forwarding IP address isn’t necessarily the same as the destination IP address of the IP datagram. As is discussed in detail in Chapter 6, "Internet Protocol (IP) Routing," the result of the route determination process for every outgoing IP datagram is an interface and a forwarding IP address. For direct deliveries to destinations on the same subnet, the forwarding IP address is the datagram’s destination IP address. For indirect deliveries to remote destinations, the forwarding IP address is the IP address of a router on the same subnet as the forwarding host.
IP was designed to be independent of any specific Network Interface Layer technology. Therefore, there’s no way to determine the destination Network Interface Layer address from the forwarding IP address. For example, Ethernet and Token Ring MAC addresses are 6 bytes long, and IP addresses are 4 bytes long. During the manufacturing process, the MAC address is assigned to the adapter. A network administrator assigns the IP address. Because there’s no correlation between the assignment of these two addresses for a given IP node, it’s impossible to derive one address from the other. ARP is a broadcast-based, request-reply protocol that provides a dynamic-resolution facility to map forwarding IP addresses to their corresponding MAC addresses.
ARP consists of the following two messages:
Because the ARP Request is a MAC-level broadcast packet, all forwarding IP addresses to be resolved must be directly reachable (on the same subnet) from the interface used to send the ARP Request. For proper routing table entries, this is always the case. If a routing table entry contains an invalid forwarding IP address where that address isn’t directly reachable for the interface, ARP will fail to resolve the forwarding IP address.
All nodes within the same broadcast domain receive the ARP Request. A broadcast domain is a portion of a network over which a broadcast frame is propagated. Hubs, bridges, and, more recently, Layer 2 switches propagate the ARP Request. However, IP routers or Layer 3 switches don’t propagate ARP frames.
After the MAC address for a forwarding IP address is determined using an ARP Request-ARP Reply exchange, the resolved MAC address is used as the destination MAC address for subsequent packets. If the node whose IP address has been resolved fails, the ARP requester node will continue to use its ARP cache entry and send packets on the medium to the resolved MAC address. Because the resolved MAC address corresponds to a network adapter that’s no longer present on the network, all of the network segment’s nodes ignore the frame. Because the forwarding IP address was mapped to a MAC address with the ARP cache entry, and the frame was sent on the medium, IP and ARP on the sending node consider the IP datagram to be successfully delivered.
This condition is known as a network black hole; packets sent on the network are dropped and the sender or forwarder is unaware of the condition. The user at the ARP requester computer won’t notice this condition until TCP connections or other types of session-oriented traffic begin to time out. This particular type of network black hole will persist as long as the entry for the mapping remains in the ARP cache. After the entry is removed, an ARP Request-ARP Reply exchange is attempted again. Because the failed node won’t respond to the ARP Request, the lack of an ARP Reply can be used to indicate an unsuccessful delivery of IP packets using the forwarding IP address.
By default, ARP cache entries in Windows 2000 persist for only 2 minutes. If the ARP cache entry is used within 2 minutes, it’s given additional time in 2-minute increments, up to a maximum lifetime of 10 minutes. After a maximum time of 10 minutes, the ARP cache entry is removed and must be resolved through another ARP Request-ARP Reply exchange. The time-out of ARP cache entries is configurable with the ArpCacheLife and ArpCacheMinReferencedLife registry settings.
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersArpCacheLife sets the number of seconds that an unused ARP cache entry is kept in the ARP cache. The default value of ArpCacheLife is 120 seconds (2 minutes).
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersArpCacheMinReferencedLife sets the number of seconds that a used ARP cache entry persists in the ARP cache. The default value of ArpCacheMinReferencedLife is 600 seconds (10 minutes). The ArpCacheMinReferencedLife and ArpCacheLife registry settings are used in the following ways:
In addition, Microsoft Windows 2000 TCP/IP allows the use of static ARP cache entries. Static ARP cache entries can be added through the use of the ARP utility using the "-s" command-line option. Static ARP cache entries don’t time out of the ARP cache. However, static ARP cache entries are stored in RAM and must be added each time TCP/IP is initialized.
While a forwarding IP address is being resolved with ARP, Microsoft Windows 2000 ARP will store only one IP datagram for that forwarding IP address. If multiple datagrams are sent to the same forwarding IP address without pause, it’s possible that some datagrams might be dropped before the ARP exchange completes. This isn’t a problem for TCP connection data, but User Datagram Protocol (UDP) messages might experience packet loss because of this behavior. In this case, use the SendArp() function to create the ARP cache entry prior to sending packets.
When a network black hole is caused by a failed interface, and when the interface is replaced, the first ARP Request frame sent on that interface will contain the interface’s new MAC address. Upon receipt of that ARP Request, all of the network segment’s nodes that have an ARP cache entry for that node’s IP address will update the ARP cache entry with the new MAC address. The network black hole is removed by the resetting of ARP cache entries when the ARP Request is sent.
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersArpUseEtherSNAP either enables (=1) or disables (=0) the use of the IEEE 802.3 SNAP frame format when sending IP and ARP frames. ArpUseEtherSNAP is disabled by default, meaning that IP and ARP frames are sent with Ethernet II encapsulation. Regardless of the ArpUseEtherSNAP setting, both types of frame formats are received.
For Token Ring, the ArpTRSingleRoute and ArpAlwaysSourceRoute provide control over broadcast ARP Requests in a Token Ring source-routed environment.
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersArpTRSingleRoute either disables (=0) or enables (=1) the sending of ARP Requests as single-route broadcasts. When disabled, the default ARP Requests are sent as all-routes broadcasts.
A Token Ring source-routed environment is a series of rings connected by source-routing bridges. The rings can be connected so that there are multiple paths to any given node. While this creates fault tolerance for the source-routing bridges, it also causes a problem for all-routes broadcast frames. An all-routes broadcast frame travels all possible paths. If there are five different paths between a node sending an all-routes broadcast frame and a ring, five copies of that all-routes broadcast frame appear on that ring.
To prevent this problem, nodes are configured to send single-route broadcast frames, and source-routing bridges are configured to either propagate single-route or all-routes broadcast frames. With proper design, a network administrator can define a single path over which single-route broadcast traffic travels even though multiple paths exist for all-routes broadcast traffic. Using single-route broadcasts, a Token Ring environment can maintain its fault tolerance while avoiding the duplication of broadcast traffic.
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersArpAlwaysSourceRoute either disables (=0) or enables (=1) the use of source routing on broadcast ARP Requests. When the ArpAlwaysSourceRoute setting isn’t present in the registry, the default setting causes the ARP to send the ARP Request without source-routing first. If no reply is received, ARP sends the ARP Request with source routing.
As RFC 826 describes, an ARP frame’s structure suggests that ARP could be used for MAC address resolution for protocols other than IP. However, in practice, IP is the only protocol that uses the ARP frame format. Figure 3-1 shows the structure of the ARP frame.
ARP as a potential MAC address resolution for non-IP protocols is discussed in RFC 826, which can be found in the \RFC folder on the companion CD-ROM.
The fields in the ARP header are defined as follows:
Table 3-1. ARP Hardware Type Values
Table 3-2. ARP Operation Values
Node 1, with the IP address of 10.0.0.99 and the MAC address of 0x00-60-08-52-F9-D8, needs to forward an IP datagram to Node 2 at the IP address of 10.0.0.1. Based on information in Node 1’s routing table, the forwarding IP address to reach Node 2 is 10.0.0.1, using the Ethernet interface. Node 1 constructs an ARP Request frame and sends it as a MAC-level broadcast using the Ethernet interface.
The following Network Monitor trace (Capture 03-01 in the \Captures folder on the companion CD-ROM) is for the ARP Request frame sent by Node 1.
+ Frame: Base frame propertiesThe known quantitythe IP address of 10.0.01is set to the Target Protocol Address field. The unknown quantitythe hardware address of 10.0.0.1is the Target Hardware Address field in the ARP Request frame, which is set to 000000000000. Included in the ARP Request are the IP and MAC addresses of Node 1 so that Node 2 can add an entry for Node 1 to its own ARP cache.
Upon receipt of the ARP Request frame at Node 2, the node checks the values of the ARP Hardware Type and Protocol Type fields. Node 2 then examines its own ARP cache for an entry matching the SPA. If an entry exists, Node 2 updates the MAC address of the ARP cache entry with the value stored in the SHA. For our example purposes, no entry for 10.0.0.99 exists.
Node 2 then examines the value of the TPA. Because the TPA is the same as Node 2’s IP address, Node 2 adds an ARP cache entry consisting of [SPA, SHA] to its ARP cache. It then checks the ARP Operation field. Because the received ARP frame is an ARP Request, Node 2 constructs an ARP Reply to send back to Node 1.
The following Network Monitor trace (Capture 03-01 in the \Captures folder on the companion CD-ROM) is for the ARP Reply frame sent by Node 2.
+ Frame: Base frame propertiesIn the ARP Reply, all quantities are known and the frame is addressed at the MAC level using Node 1’s unicast MAC address. The quantity that Node 1 needsNode 2’s MAC addressis the SHA field’s value.
Upon receipt of the ARP Reply frame, Node 1 checks the values of the ARP Hardware Type and Protocol Type fields. Node 1 then examines its own ARP cache for an entry matching the SPA. No entry exists; otherwise, an ARP Request would not have been sent. Node 1 then examines the TPA’s value. Because the TPA is the same as Node 1’s IP address, Node 1 adds an ARP cache entry consisting of [SPA, SHA] to its ARP cache. Node 1 then checks the ARP Operation field. Because the received ARP frame is an ARP Reply, the ARP frame is discarded.
Frame Padding and Ethernet
Notice that the ARP frames of Network Monitor trace contain a Frame Padding field. This Frame Padding field isn’t an ARP field, but the consequence of sending an ARP frame on an Ethernet network. As discussed in Chapter 1, "Local Area Network (LAN) Technologies," Ethernet payloads using the Ethernet II encapsulation must be a minimum length of 46 bytes to adhere to the minimum Ethernet frame size. The ARP frame is only 28 bytes long. Therefore, to send the ARP frame on an Ethernet network, the ARP frame must be padded with 18 padding bytes.
When using Network Monitor, you might notice that sometimes the Frame Padding field doesn’t appear on either the ARP Request or the ARP Reply frames. Does this mean that the ARP frame was sent as a runtan Ethernet frame with a length below the minimum frame size? No. The answer to the mystery lies in the implementation of Network Monitor within Windows 2000. Network Monitor receives frames by acting as a Network Driver Interface Specification (NDIS) protocol. When any frame is sent or received, Network Monitor receives a copy. However, when frames are sent, Network Monitor receives a copy of the frame before the frame padding is added. When the frame is received, Network Monitor receives a full copy of the frame. Therefore, you won’t see a Frame Padding field on an ARP frame if it was captured on the node sending the ARP frame. The example Network Monitor trace given in this chapter was taken on Node 1. Therefore, the frame padding is only seen on the ARP Reply frame.
If a node sends an ARP Request for its own IP address and no ARP Reply frames are received, the node can assume that its assigned IP address isn’t being used by other nodes. If a node sends an ARP Request for its own IP address and an ARP Reply frame is received, the node can determine that its assigned IP address is already being used by another node.
The ArpRetryCount registry setting controls the number of gratuitous ARPs that are sent.
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersArpRetryCount sets the number of times that a gratuitous ARP is sent when initializing IP for a specific IP address. If no ARP Reply is received after sending ArpRetryCount gratuitous ARPs, IP assumes the IP address is unique on the network segment.
The gratuitous ARP attempts to detect the use of a duplicate IP address by a node on the same network segment. Because ARP frames aren’t propagated by routers, a gratuitous ARP won’t detect an IP address conflict between two nodes that are located on different network segments.
On the Offending Node
If the offending node is a Windows 2000 computer manually configured with a conflicting IP address, the receipt of the ARP Reply to the gratuitous ARP will prevent TCP/IP from initializing using the conflicting address. An error message is displayed and an event is logged in the System Event log.
If the offending node is a Windows 2000 computer using Dynamic Host Configuration Protocol (DHCP), gratuitous ARPs are sent for the IP address received in the DHCPOFFER message. If an ARP Reply is received in response to the gratuitous ARPs, the DHCP client sends a DHCPDECLINE message to the DHCP server. If the DHCP server is a Windows 2000 DHCP server, the IP address sent in the DHCPOFFER is flagged as a bad IP address and isn’t allocated to any other DHCP clients. The DHCP client starts the DHCP lease allocation process by sending a new DHCPDISCOVER message. For more information on Windows 2000 DHCP, see Chapter 15, "Dynamic Host Configuration Protocol (DHCP) Service."
On the Defending Node
The defending node detects an address conflict whenever the SPA of the incoming ARP Request is the same as an IP address configured on the defending node. For gratuitous ARPs from an offending node, both the SPA and TPA are set to the conflicting address. However, gratuitous ARPs aren’t the only ARP Requests that can have the SPA set to the conflicting address.
For example, if a node using a conflicting address is started without being connected to its network segment, no replies to the gratuitous ARPs are received and the node will initialize TCP/IP using the conflicting address. If the node is then placed on the same network segment as the defending node, no additional gratuitous ARPs are sent. However, each time either node using the conflicting address sends an ARP Request, the SPA is set to the conflicting address. In this case, an error message is displayed and an event is logged in the System Event log. Both nodes continue to use the conflicting IP address, but display an error message and log an event every time the other node sends an ARP Request.
When the gratuitous ARP is sent, the SPA is set to a conflicting IP address and the SHA is set to the offending node’s MAC address. Nodes on the network segment that have an ARP cache entry for [conflicting IP address, defending node’s MAC address] will have their ARP cache entries updated to [conflicting IP address, offending node’s MAC address]. The gratuitous ARP sent by the offending node updates all the ARP cache entries for the nodes communicating with the defending node; this causes future IP datagrams to be sent to the offending node’s MAC address. A worst-case scenario is when the defending node is the default gateway for the network segment. Sending the gratuitous ARP Request causes all nodes on that network segment, with an entry in their ARP cache for the default gateway IP address, to forward all traffic off the subnet to the offending node’s MAC address.
When the ARP Reply is sent, it’s sent to the defending node’s MAC address. The unicast ARP Reply doesn’t correct the improper ARP cache entries. Therefore, to reset the ARP cache entries that were improperly updated by the offending nodes’ sending of the gratuitous ARP Request, the defending node sends another broadcast ARP Request. The defending node’s ARP Request is a gratuitous ARP as if the defending node were doing its own conflict detection. The defending node’s ARP Request contains the SHA set to the offending node’s MAC address. Network segment nodes that have had their ARP cache entries improperly set to [conflicting IP address, offending node’s MAC address] are reset to the proper mapping of [conflicting IP address, defending node’s MAC address].
Network Monitor trace 3-2 (Capture 03-02 in the \Captures folder on the companion CD-ROM) shows the gratuitous ARP and address conflict exchange. Frame 1 is the offending node’s gratuitous ARP. Frame 2 is the defending node’s ARP Reply. Frame 3 is the defending node’s gratuitous ARP. At the end of frame 3, all network segment nodes that have the IP address 192.168.0.1 in their ARP caches have been reset to the proper MAC address of 0x00-60-97-02-6D-3D.
InARP is used to resolve the IP address on the other end of a virtual circuit based on a known Frame Relay DLCI. As RFC 2390 describes, InARP was designed specifically for Frame Relay virtual circuits. Frame Relay link management protocols such as Local Management Interface (LMI) determine which virtual circuits are in use over the physical connection to the Frame Relay service provider. Once the DLCIs are determined, InARP is used to query each virtual circuit to determine the IP address of the interface on the other end. The response to the InARP is used to build a table of entries consisting of [DLCI, forwarding IP address].
InARP , as designed for Frame Relay virtual circuits, is described in RFC 2390, which can be found in the \RFC folder on the companion CD-ROM.
Because the DLCI values are only locally significant, the SHA and THA are irrelevant. In both the InARP Request and InARP Reply, the SHA field is typically set to 0 and the TPA field is set to the local DLCI value. The relevant information is the value of the SPA field in the InARP Request and the InARP Reply. The InARP responder uses the InARP Request’s SPA to add an entry to its table consisting of [local DLCI, SPA of InARP Request]. The InARP requester uses the InARP Reply’s SPA to add an entry to its table consisting of [local DLCI, SPA of InARP Reply].
The InARP Request and Reply have the same structure as the ARP Request and Reply, except 2-byte hardware adresses are used. The ARP Operation field is set to 0x0008 for an InARP Request and 0x0009 for an InARP Reply.
Use of Proxy ARP in divided subnet situations is described in RFC 925, which can be found in the \RFC folder on the companion CD-ROM.
When Node 1 wants to send an IP datagram to Node 2 on the other side of the proxy ARP device, because Node 1 and Node 2 are on the same logical IP subnet, Node 1 sends an ARP Request with Node 2’s IP address as the TPA. The proxy ARP device receives the ARP Request and, even though the TPA isn’t its own address, the proxy ARP device sends an ARP Reply to Node 1 with the proxy ARP device’s MAC address as the SHA. Node 1 then sends the IP datagram to the proxy ARP device’s MAC address. As far as Node 1 is concerned, it has resolved Node 2’s MAC address and delivered the IP datagram to Node 2. The proxy ARP device next delivers the IP datagram to Node 2, using ARP if necessary to resolve Node 2’s MAC address.
The Windows 2000 Routing and Remote Access service uses proxy ARP to facilitate communications between remote access clients and nodes on the network segment to which the remote access server is attached. When IP-based remote access clients connect, the remote access server assigns them an IP address. The IP address assigned can either be from the address range of a subnet to which the remote access server is attached, an on-subnet address, or from the address range of a separate subnet, an off-subnet address. Proxy ARP is used when the remote access server assigns an on-subnet address. An on-subnet address range is used when either the Routing and Remote Access service is configured to use DHCP to obtain addresses, or a range of addresses from a directly attached subnet is manually configured. Figure 3-4 shows an example of a remote access server manually configured with an on-subnet address range.
The subnet to which the remote access server is attached is 10.1.1.0/24, implying a range of usable addresses from 10.1.1.1 through 10.1.1.254. In this case, the network administrator is using the high end of the range (10.1.1.200 through 10.1.1.254) for assignment to remote access clients.
When an IP-based remote access client successfully connects and is assigned an IP address, the Routing and Remote Access service tracks the assigned address in a connection table. When a host on the network to which the remote access server is attached sends an ARP Request for the remote access client’s assigned on-subnet IP address, the remote access server answers with an ARP Reply and receives the forwarded IP datagram. The Routing and Remote Access service then forwards the IP datagram addressed to the remote access client over the appropriate remote access connection.
If the remote access server is manually configured with a range of addresses that represents a different subnet (an off-subnet address range), the remote access server acts as an IP router forwarding IP datagrams between separate subnets.
Last Updated: Friday, July 6, 2001