Training
Certifications
Books
Special Offers
Community




 
Microsoft® Windows® 2000 TCP/IP Protocols and Services Technical Reference
Author Thomas Lee and Joseph Davies
Pages 576
Disk 1 Companion CD(s)
Level Int/Adv
Published 01/05/2000
ISBN 9780735605565
ISBN-10 0-7356-0556-4
Price(USD) $49.99
To see this book's discounted price, select a reseller below.
 

More Information

About the Book
Table of Contents
Sample Chapter
Index
Related Series
Related Books
About the Author

Support: Book & CD

Rate this book
Barnes Noble Amazon Quantum Books

 


Chapter 3: Address Resolution Protocol (ARP)



Chapter 3 Address Resolution Protocol (ARP)

To successfully troubleshoot problems forwarding IP datagrams on a local area network (LAN) link, it is important to understand how ARP is used to resolve a node’s IP address to its corresponding Network Interface Layer address. Microsoft Windows 2000 TCP/IP supports ARP for address resolution and duplicate IP address detection. The Windows 2000 Routing and Remote service uses a variation of ARP called proxy ARP to forward IP datagrams between remote access clients and the network attached to the remote access server.

Overview of ARP

ARP is the protocol used by shared access, broadcast-based networking technologies such as Ethernet and Token Ring. This protocol is used to resolve the forwarding IP address of a node to its corresponding media access control (MAC) address. The MAC address also is known as the physical, hardware, or network adapter address. The resolved MAC address becomes the destination MAC address in the Ethernet or Token Ring header to which an IP datagram is addressed when it’s sent on the medium. ARP resolves an Internet Layer address (an Internet Protocol (IP) address) to a Network Interface Layer address (MAC address).


MORE INFO:
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:

  • The forwarding node uses the ARP Request message to request the MAC address for a specific forwarding IP address. The ARP Request is a MAC-level broadcast frame intended to reach all the nodes on the physical network segment to which the interface sending the ARP Request is attached. The node sending the ARP Request is known as the ARP requester.
  • The ARP Reply message is used to reply to the ARP requester. The node whose IP address matches the requested IP address in the ARP Request message sends the ARP Reply. The ARP Reply is a unicast MAC frame sent to the destination MAC address of the ARP requester. The node sending the ARP Reply is known as the ARP responder.

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.

The ARP Cache

As is common in many TCP/IP implementations, Windows 2000 TCP/IP maintains a RAM-based table of IP and MAC address mappings known as the ARP cache. When an ARP exchange is complete (both the ARP Request and the ARP Reply are sent and received), both the ARP requester and the ARP responder have each other’s IP address to MAC address mappings in their ARP caches. Subsequent packets forwarded to the previously resolved IP addresses use the ARP cache entry’s MAC address. The ARP cache is always checked before an ARP Request is sent. There is a separate ARP cache for each IP interface.

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.

ArpCacheLife

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–0xFFFFFFFF
Default value: 120
Present by default: No
ArpCacheLife 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).

ArpCacheMinReferencedLife

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–0xFFFFFFFF
Default value: 600
Present by default: No
ArpCacheMinReferencedLife 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:

  • If ArpCacheLife is greater than or equal to ArpCacheMinReferencedLife, both used and unused ARP cache entries persist for ArpCacheLife seconds.
  • If ArpCacheLife is less than ArpCacheMinReferencedLife, unused ARP cache entries expire in ArpCacheLife seconds, and used entries expire in ArpCacheMinReferencedLife seconds.

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.

Updating the MAC Address

The default behavior of Windows 2000 TCP/IP is to update the ARP cache entry with additional time, in 2-minute increments, while it’s in use. Another way of updating the ARP cache entry is through the receipt of an ARP Request sent by the node with the ARP cache entry’s IP address. When an ARP Request that was sent by an IP node corresponding to an existing entry in the ARP cache is received, update the ARP cache entry with the received ARP Request’s MAC address.

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.

Windows 2000 ARP Registry Settings

By default, Windows 2000 uses the Ethernet II encapsulation described in Chapter 1, "Local Area Network (LAN) Technologies," when sending both IP and ARP frames. Windows 2000 will receive both Ethernet II and IEEE 802.3 SubNetwork Access Protocol (SNAP)-encapsulated frames, but, by default, it will respond only with Ethernet II-encapsulated frames. To send IEEE 802.3 SNAP-encapsulated IP and ARP frames, use the ArpUseEtherSNAP registry setting.

ArpUseEtherSNAP

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–1
Default value: 0
Present by default: No
ArpUseEtherSNAP 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.

ArpTRSingleRoute

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–1
Default value: 0
Present by default: No
ArpTRSingleRoute 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.

ArpAlwaysSourceRoute

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 0–1 or not present
Default value: Not present
Present by default: No
ArpAlwaysSourceRoute 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.

ARP Frame Structure

ARP frames use the EtherType of 0x08-06. ARP isn’t a client protocol of IP, and ARP frames don’t contain an IP header. Thus, ARP is useful only for resolving MAC addresses for IP addresses that are on the same physical network segment, the boundaries of which are defined by IP routers. IP routers will never forward an ARP Request or ARP Reply frame.

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.

Figure 3-1


Figure 3-1.
 The structure of an ARP frame for LAN technologies.


MORE INFO:
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:

  • Hardware Type  A 2-byte field that indicates the type of hardware being used at the Data Link Layer. Table 3-1 lists some commonly used ARP Hardware Type values. Upon receipt of an ARP frame, an IP node verifies that the Hardware Type of the ARP frame matches the Hardware Type of the interface on which the ARP frame was received. If it doesn’t match, the frame is silently discarded. For a complete list of ARP Hardware Type values, see http://www.isi.edu/in-notes/iana/assignments/arp-parameters.
  • Table 3-1.  ARP Hardware Type Values

    Hardware Type ValueData Link Layer Technology
    1 (0x00-01)Ethernet (10 Mbps)
    6 (0x00-06)IEEE 802 Networks (Token Ring)
    15 (0x00-0F)Frame Relay
    16 (0x00-10)Asynchronous Transfer Mode

  • Protocol Type  A 2-byte field that indicates the protocol for which ARP is providing address resolution. The ARP Protocol Type field uses the same values as the Ethernet II EtherType field. For IP address resolution, the Protocol Type field is set to the EtherType for IP, 0x0800. Upon receipt of an ARP frame, an IP node verifies that the ARP Protocol Type is set to 0x0800. If it’s not set to 0x0800, the frame is silently discarded.
  • Hardware Address Length  A 1-byte field that indicates the length in bytes of the hardware address in the Sender Hardware Address and Target Hardware Address fields. For Ethernet and Token Ring, the Hardware Address Length field is set to 6. For Frame Relay, the Hardware Address Length typically is set to 2 (for the commonly used 2-byte Frame Relay Address field).
  • Protocol Address Length  A 1-byte field that indicates the length in bytes of the protocol address in the Sender Protocol Address and Target Protocol Address fields. For the IP protocol, the length of IP addresses is 4 bytes.
  • Operation (Opcode)  A 2-byte field that indicates the type of ARP frame. Table 3-2 lists the commonly used ARP Operation values. For a complete list of ARP Operation values, see http://www.isi.edu/in-notes/iana/assignments/arp-parameters.
  • Table 3-2.  ARP Operation Values

    Operation ValueType of ARP Frame
    1ARP Request
    2ARP Reply
    8Inverse ARP Request
    9Inverse ARP Reply

  • Sender Hardware Address (SHA)  A field that is the length of the value of the Hardware Address Length field and contains the hardware or Data Link Layer address of the ARP frame’s sender. For Ethernet and Token Ring, the SHA field contains the MAC address of the node sending the ARP frame.
  • Sender Protocol Address (SPA)  A field that is the length of the value of the Protocol Address Length field and contains the protocol address of the ARP frame’s sender. For IP, the SPA field contains the IP address of the node sending the ARP frame.
  • Target Hardware Address (THA)  A field that is the length of the value of the Hardware Address Length field and contains the hardware or Data Link Layer address of the ARP frame’s target (destination). For Ethernet and Token Ring, the THA field is set to 0x00-00-00-00-00-00 for ARP Request frames, and it’s set to the MAC address of the ARP requester for ARP Reply frames.
  • Target Protocol Address (TPA)  A field that is the length of the value of the Protocol Address Length field and contains the protocol address of the ARP frame’s target (destination). For IP, the TPA field is set to the IP address being resolved in the ARP Request frame, and it’s set to the IP address of the ARP requester in the ARP Reply frame.

ARP Request and ARP Reply Example

The ARP Request and ARP Reply exchange contains all the information for the ARP requester to determine the IP address and MAC address of the ARP responder, and for the ARP responder to determine the IP address and MAC address of the ARP requester. Figure 3-2 shows an ARP Request and ARP Reply exchange.

Figure 3-2
Figure 3-2. The resolution of Node 2’s MAC address by Node 1, using an exchange of ARP Request and ARP Reply frames.

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 properties
ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol
+ ETHERNET: Destination address : FFFFFFFFFFFF
+ ETHERNET: Source address : 00600852F9D8
ETHERNET: Frame Length : 42 (0x002A)
ETHERNET: Ethernet Type : 0x0806 (ARP: Address Resolution Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 28 (0x001C)
ARP_RARP: ARP: Request, Target IP: 10.0.0.1
ARP_RARP: Hardware Type = Ethernet (10Mb)
ARP_RARP: Protocol Type = 2048 (0x800)
ARP_RARP: Hardware Address Length = 6 (0x6)
ARP_RARP: Protocol Address Length = 4 (0x4)
ARP_RARP: Opcode = Request
ARP_RARP: Sender’s Hardware Address = 00600852F9D8
ARP_RARP: Sender’s Protocol Address = 10.0.0.99
ARP_RARP: Target’s Hardware Address = 000000000000
ARP_RARP: Target’s Protocol Address = 10.0.0.1
The known quantity—the IP address of 10.0.01—is set to the Target Protocol Address field. The unknown quantity—the hardware address of 10.0.0.1—is 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 properties
ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol
+ ETHERNET: Destination address : 00600852F9D8
+ ETHERNET: Source address : 001054CAE140
ETHERNET: Frame Length : 60 (0x003C)
ETHERNET: Ethernet Type : 0x0806 (ARP: Address Resolution Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E)
ARP_RARP: ARP: Reply, Target IP: 10.0.0.99 Target Hdwr Addr: 00600852F9D8
ARP_RARP: Hardware Type = Ethernet (10Mb)
ARP_RARP: Protocol Type = 2048 (0x800)
ARP_RARP: Hardware Address Length = 6 (0x6)
ARP_RARP: Protocol Address Length = 4 (0x4)
ARP_RARP: Opcode = Reply
ARP_RARP: Sender’s Hardware Address = 001054CAE140
ARP_RARP: Sender’s Protocol Address = 10.0.0.1
ARP_RARP: Target’s Hardware Address = 00600852F9D8
ARP_RARP: Target’s Protocol Address = 10.0.0.99
ARP_RARP: Frame Padding
In 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 needs—Node 2’s MAC address—is 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.


TIP:
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 runt—an 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.

Gratuitous ARP and Duplicate IP Address Detection

ARP also is used to provide duplicate IP address detection through the transmission of ARP Requests known as gratuitous ARPs. A gratuitous ARP is an ARP Request for a node’s own IP address. In the gratuitous ARP, the SPA and the TPA are set to the same IP address.

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.

ArpRetryCount

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type: REG_DWORD
Valid range: 1–3
Default value: 3
Present by default: No
ArpRetryCount 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.


NOTE:
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.

IP Address Conflict Detection

In an IP address conflict, the node that is already successfully configured with the IP address is known as the defending node. The node that is sending the gratuitous ARP is known as the offending node. Based on the ARP Reply, the offending node can determine the defending node’s MAC address.

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.

The Gratuitous ARP and Address Conflict Exchange

The gratuitous ARP and address conflict detection for Windows 2000 is an exchange of three frames. The first two frames, as noted below, are the ARP Request-ARP Reply for the conflicting address.

  1. The offending node attempting to detect another node on the same network segment using the same IP address sends the gratuitous ARP Request.
  2. The defending node sends the ARP Reply to the offending node.

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.

Inverse ARP (InARP)

For Non-Broadcast Multiple Access (NBMA)-based WAN technologies such as X.25, Frame Relay, and ATM, the Network Interface Layer address isn’t a MAC address but a virtual-circuit identifier. For example, for Frame Relay, the virtual-circuit identifier is the Frame Relay Data Link Connection Identifier (DLCI). To address frames for a given destination, the Frame Relay header’s DLCI is set to the value that corresponds to the virtual circuit over which the frame is traveling. With NMBA technologies, the virtual-circuit identifier is known but the IP address of the interface on the other end of the virtual-circuit isn’t.

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].


MORE INFO:
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.

Proxy ARP

Proxy ARP is the answering of ARP Requests on behalf of another node. As RFC 925 describes, Proxy ARP is used in situations where a subnet is divided without the use of a router. A proxy ARP device is placed between nodes on the same subnet. The proxy ARP device is aware of what nodes are available on which segment. The proxy ARP device also answers ARP Requests and facilitates the forwarding of unicast IP packets for communication between nodes on separate segments. The existence of the proxy ARP device is transparent to the nodes on the subnet. A proxy ARP device is often physically a router device; however, it is not acting as an IP router, forwarding IP datagrams between two IP subnets. Figure 3-3 shows an example of a proxy ARP configuration.


MORE INFO:
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.

Figure 3-3
Figure 3-3. A single subnet configuration, using a Proxy ARP device.

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.

Figure 3-4
Figure 3-4. A Windows 2000 remote access server, configured with an on-subnet address range using proxy ARP.

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.

Summary

ARP is used as a translation layer between Internet Layer addresses and Network Interface Layer addresses. ARP on LAN links is used to resolve the forwarding IP address of a node to its corresponding MAC address and to detect IP address conflicts. InARP on NBMA links is used to map a DLCI value to the IP address of the node on the other end of the virtual circuit. Proxy ARP is used to subdivide an IP subnet and provide transparent communication without using a IP router.




Top of Page


Last Updated: Friday, July 6, 2001