Address Resolution Protocol (ARP)

Overview

To successfully troubleshoot problems forwarding IP datagrams on a local area network (LAN) link, it is important to understand how Address Resolution Protocol (ARP) is used to resolve a node's IP address to its corresponding Network Interface Layer address. TCP/IP for the Microsoft Windows Server 2003 family and Windows XP supports ARPfor address resolution and duplicate IP address detection. The Network Bridge for the Windows Server 2003 family and Windows XP and the Routing and Remote Access service for the Windows Server 2003 family uses a variation of ARP called proxy ARP to forward IP datagrams between nodes on separate segments of a subdivided subnet.

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 next-hop 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 is sent on the medium. ARP resolves an Internet Layer address (an IP address) to a Network Interface Layer address (a MAC address).

  More Info

ARP is described in RFC 826, which can be found in the Rfc folder on the companion CD-ROM.

The next-hop IP address is not necessarily the same as the destination IP address of the IP datagram. As is discussed in detail in Chapter 7, "Internet Protocol (IP) Routing," the result of the route determination process for every outgoing IP datagram is a next-hop interface and a next-hop IP address. For direct deliveries to destinations on the same subnet, the next- hop IP address is the datagram's destination IP address. For indirect deliveries to remote destinations, the next-hop 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 is no way to determine the destination Network Interface Layer address from the next-hop 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 (either directly through manual configuration or indirectly through the administration of a Dynamic Host Configuration Protocol [DHCP] server). Because there is no correlation between the assignments of these two addresses for a given IP node, it is impossible to derive oneaddress from the other. ARP is a broadcast-based, request-reply protocol that provides a dynamic address resolution facility to map next-hop IP addresses to their corresponding MAC addresses.

ARP consists of the following two messages:

Because the ARP Request message is a MAC-level broadcast, all next-hop 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 next-hop IP address and the address is not directly reachable for the interface, ARP fails to resolve the next-hop IP address.

All nodes within the same broadcast domain receive the ARP Request. A broadcastdomain 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 do not propagate ARP frames.

The ARP Cache

As is common in many TCP/IP implementations, TCP/IP for the Windows Server 2003 family and Windows XP 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 next-hop 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 already been resolved fails, the ARP requester node continues 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 is no longer present on the network, all of the network segment's nodes ignore the frame. Because the next-hop 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 does not notice this condition until TCP connections or other types of session-oriented traffic begin to time out. This particular type of network black hole persists 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 does not respond to the ARP Request, the lack of an ARP Reply can be used to indicate an unsuccessful delivery of IP packets using the next-hop IP address.

By default, ARP cache entries for the Windows Server 2003 family and Windows XP persist for only 2 minutes. If the ARP cache entry is used within 2 minutes, it is given additional time in 2-minute increments, up to a maximum lifetime of 10 minutes. After a maximum 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_MACHINESYSTEMCurrentControlSetServicesTcpipParameters 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. Ifthe ArpCacheLife entry is not present, the default value of ArpCacheLife is 120 seconds (2 minutes).

ArpCacheMinReferencedLife

Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters 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:

In addition, TCP/IP for the Windows Server 2003 family and Windows XP allows the use of static ARP cache entries, which can be added through the use of the Arp utility using the -s command-line option. Static ARP cache entries do not time out of the ARP cache. However, they are stored in RAM and must be added each time TCP/IP is initialized.

While a next-hop IP address is being resolved, ARP for the Windows Server 2003 family and Windows XP stores only one IP datagram for that next-hop IP address. If multiple datagrams are sent to the same next-hop IP address without pause, it is possible that some datagrams might be dropped before the ARP exchange completes. This is not 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 TCP/IP for the Windows Server 2003 family and Windows XP is to update the ARP cache entry with additional time, in 2-minute increments, while it is 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 isreceived, the ARP cache entry is updated 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 contains the interface's new MAC address. After receipt of that ARP Request, all of the network segment's nodes that have an ARP cache entry for that node's IP address 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.

ARP Registry Settings

By default, the Windows Server 2003 family and Windows XP use the Ethernet II encapsulation described in Chapter 1, "Local Area Network (LAN) Technologies," when sending both IP and ARP frames. The TCP/IP protocol for the Windows Server 2003 family and Windows XP receives both Ethernet II and IEEE 802.3 Sub-Network Access Protocol (SNAP)–encapsulated frames, but, by default, they 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_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid range: 0–1 Default value: 0 Present by default: No

ArpUseEtherSNAP either enables (when set to 1) or disables (when set to 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_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid range: 0–1 Default value: 0 Present by default: No

ArpTRSingleRoute either disables (when set to 0) or enables (when set to 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. Although 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 for all-routes broadcast traffic exist. Using single-route broadcasts, a Token Ring environment can maintain its fault tolerance and avoid the duplication of broadcast traffic.

ArpAlwaysSourceRoute

Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid range: 0–1 or not present Default value: Not present Present by default: No

ArpAlwaysSourceRoute either disables (when set to 0) or enables (when set to 1) the use of source routing on broadcast ARP Requests. When the ArpAlwaysSourceRoute setting is not 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.

To enable communication with a Network Load Balancing (NLB) cluster that is operating in multicast mode, use the EnableBcastArpReply setting.

EnableBcastArpReply

Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid range: 0–1 Default value: 1 Present by default: No

EnableBcastArpReply either enables (when set to 1) or disables (when set to 0) the use of a multicast MAC address in the Sender Hardware Address (SHA) field in an ARP Reply message. NLB clusters that are operating in multicast mode use a multicast MAC address for their hardware address. This multicast address is the value of the SHA field in an ARP Reply sent by a cluster member when responding to an ARP Request for the IP address of the cluster. If a host on the same subnet as the NLB cluster does not support the use of a multicast MAC address in the SHA field of an ARP Reply, communication with the cluster is not possible. EnableBcastArpReply is enabled by default.

ARP Frame Structure

ARP frames use the EtherType of 0x0806. ARP is not a client protocol of IP, and ARP frames do not 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 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: 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:

ARP Request and ARP Reply Example

The ARP Request and ARP Reply exchange contains all the information for the ARPrequester 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: 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 next-hop 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 (Frame 1 of 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.0.1—is set to the Target Protocol Address field. The unknown quantity—the hardware address of 10.0.0.1—is the Target HardwareAddress 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.

After 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 (Frame 2 of 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.

After 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 the Network Monitor trace contain a Frame Padding field. This is not an ARP field, but the consequence of sending an ARP frame on an Ethernet network. As discussed in Chapter 1, 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, it must be padded with 18 padding bytes.

  Tip

When using Network Monitor, you might notice that sometimes the Frame Padding field does not 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 the Windows Server 2003 family. 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 do not 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 displayed 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 determines that other nodes are not using its assigned IP address. If a node sends an ARP Request for its own IP address and an ARP Reply frame is received, the node determines that another node is using its assigned IP address.

The ArpRetryCount registry setting controls the number of gratuitous ARPs that are sent.

ArpRetryCount

Location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Data type: REG_DWORD Valid range: 0–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 routers do not propagate ARP frames, a gratuitous ARP does not 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 computer running a member of the Windows Server 2003 family or Windows XP that is manually configured with a conflicting IP address, the receipt of the ARP Reply to the gratuitous ARP prevents 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 computer running a member of the Windows Server 2003 family or Windows XP using 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 running a member of the Windows Server 2003 family, the IP address sent in the DHCPOFFER is flagged as a bad IP address and is not 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 DHCP, see Chapter 16, "Dynamic Host Configuration Protocol (DHCP) Server 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 are not the only ARP Requests that can have the SPA set to a 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 initializes 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 each displays an error message and logs 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 the Windows Server 2003 family is an exchange of three frames. The first two frames are the ARP Request–ARP Reply exchange 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] 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 is sent to the defending node's MAC address. The unicast ARP Reply does not correct the improper ARP cache entries. Therefore, to reset the ARP cache entries that were improperly updated by the offending node's 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 defending 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] arereset to the proper mapping of [conflicting IP address, defending node's MAC address].

The Network Monitor trace in Capture 03-02 (in the Captures folder on the companion CD-ROM) shows the gratuitous ARP and address conflict exchange. Frame 1 is theoffending 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 169.254.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 is not 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 is not.

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, next-hop IP address].

  More Info

InARP 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 addresses 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 in which 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 which 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.

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

  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.

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 is not 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.

For the Windows Server 2003 family and Windows XP, the Network Bridge fea-ture of the Network Connections folder acts as a proxy ARP device when performingLayer 3 bridging between segments for which the Network Bridge cannot perform Layer 2 transparent bridging.

For the Windows Server 2003 family, the Routing and Remote Access service also 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.

Figure 3-4: A remote access server running a member of the Windows Server 2003 family and configured with an on-subnet address range using Proxy ARP.

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 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 actsas an IP router forwarding IP datagrams between separate subnets and proxy ARP isnot used.

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 next-hop 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 an IP router.

Related

Категории