Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

This basic operation is supplemented by methods to improve performance. Since it was

known from the start that having to perform a resolution using broadcast for each datagram

was ridiculously inefficient, ARP has always used a cache, where it keeps bindings

between IP addresses and data link layer addresses on the local network. Over time,

various techniques have been developed to improve the methods used for maintaining

cache entries. Refinements and additional features, such as support for cross-resolution by

pairs of devices as well as proxy ARP, have also been defined over the years and added to

the basic ARP feature set.

ARP Address Specification and General Operation

An Address Resolution Protocol transaction begins when a source device on an IP network

has an IP datagram to send. It must first decide whether the destination device is on the

local network or a distant network. If the former, it will send directly to the destination; if the

latter, it will send the datagram to one of the routers on the physical network for forwarding.

Either way, it will determine the IP address of the device that needs to be the immediate

destination of its IP datagram on the local network. After packaging the datagram it will pass

it to its ARP software for address resolution.

Basic operation of ARP is a request/response pair of transmissions on the local network.

The source (the one that needs to send the IP datagram) transmits a broadcast containing

information about the destination (the intended recipient of the datagram). The destination

then responds unicast back to the source, telling the source the hardware address of the

destination.

ARP Message Types and Address Designations

The terms source and destination apply to the same devices throughout the transaction.

However, there are two different messages sent in ARP, one from the source to the desti-

nation and one from the destination to the source. For each ARP message, the sender is

the one that is transmitting the message and the target is the one receiving it. Thus, the

identity of the sender and target change for each message:

☯ Request: For the initial request, the sender is the source, the device with the IP

datagram to send, and the target is the destination.

☯ Reply: For the reply to the ARP request, the sender is the destination; it replies to the

source, which becomes the target.

It’s a bit confusing, but you’ll get used to it. ☺ Each of the two parties in any message has

two addresses (layer two and layer three) to be concerned with, so four different addresses

are involved in each message:

☯ Sender Hardware Address: The layer two address of the sender of the ARP

message.

☯ Sender Protocol Address: The layer three (IP) address of the sender of the ARP

message.

☯ Target Hardware Address: The layer two address of the target of the ARP message.

☯ Target Protocol Address: The layer three (IP) address of the target.

These addresses each have a position in the ARP message format.

ARP General Operation

With that background in place, let's look at the steps followed in an ARP transaction (which

are also shown graphically in the illustration in Figure 48):

1. Source Device Checks Cache: The source device will first check its cache to

determine if it already has a resolution of the destination device. If so, it can skip to the

last step of this process, step #9.

Figure 48: Address Resolution Protocol (ARP) Transaction Process

This diagram shows the sequence of steps followed in a typical ARP transaction, as well as the message

exchanges between a source and destination device, and cache checking and update functions. (Those little

columns are supposed to be hard disks, not cans of soup! ☺)

Source

ARP Request

1. Check ARP Cache for

Destination Device

Hardware Address

2. Generate ARP

Request Frame

4. Process ARP

Request Frame

5. Generate ARP

Reply Frame

6. Update ARP Cache

Destination

7. Send ARP Reply Frame

8. Process ARP

Reply Frame

3. Broadcast ARP

Request Frame

9. Update ARP Cache

ARP Reply

2. Source Device Generates ARP Request Message: The source device generates an

ARP Request message. It puts its own data link layer address as the Sender

Hardware Address and its own IP address as the Sender Protocol Address. It fills in

the IP address of the destination as the Target Protocol Address. (It must leave the

Target Hardware Address blank, since that it is what it is trying to determine!)

3. Source Device Broadcasts ARP Request Message: The source broadcasts the

ARP Request message on the local network.

4. Local Devices Process ARP Request Message: The message is received by each

device on the local network. It is processed, with each device looking for a match on

the Target Protocol Address. Those that do not match will drop the message and take

no further action.

5. Destination Device Generates ARP Reply Message: The one device whose IP

address matches the contents of the Target Protocol Address of the message will

generate an ARP Reply message. It takes the Sender Hardware Address and Sender

Protocol Address fields from the ARP Request message and uses these as the values

for the Target Hardware Address and Target Protocol Address of the reply. It then fills

in its own layer two address as the Sender Hardware Address and its IP address as

the Sender Protocol Address. Other fields are filled in as explained in the topic

describing the ARP message format.

6. Destination Device Updates ARP Cache: If the source needs to send an IP

datagram to the destination now, it makes sense that the destination will probably

need to send a response to the source at some point soon. (After all, most communi-

cation on a network is bidirectional.) As an optimization, then, the destination device

will add an entry to its own ARP cache containing the hardware and IP addresses of

the source that sent the ARP Request. This saves the destination from needing to do

an unnecessary resolution cycle later on.

7. Destination Device Sends ARP Reply Message: The destination device sends the

ARP reply message. This reply is, however, sent unicast to the source device, as there

is no need to broadcast it.

8. Source Device Processes ARP Reply Message: The source device processes the

reply from the destination. It stores the Sender Hardware Address as the layer two

address of the destination, to use for sending its IP datagram.

9. Source Device Updates ARP Cache: The source device uses the Sender Protocol

Address and Sender Hardware Address to update its ARP cache for use in the future

when transmitting to this device.

Key Concept: ARP is a relatively simple request/reply protocol. The source device

broadcasts an ARP Request looking for a particular device based on its IP address.

That device responds with its hardware address in an ARP Reply message.

Note that this description goes a bit beyond the basic steps in address resolution, because

two enhancements are mentioned. One is caching, which is described in its own topic but

had to be mentioned here because it is the first step in the process, for obvious reasons.

The other is cross-resolution (described in the overview of caching issues in dynamic

resolution), which is step #6 of the process. This is why the source device includes its IP

address in the request. It isn't really needed for any other reason, so you can see that this

feature was built into ARP from the start.

ARP Message Format

Address resolution using ARP is accomplished through the exchange of messages

between the source device seeking to perform the resolution, and the destination device

that responds to it. As with other protocols, a special message format is used containing the

information required for each step of the resolution process.

ARP messages use a relatively simple format. It includes a field describing the type of

message (its operational code or opcode) and information on both layer two and layer three

addresses. In order to support addresses that may be of varying length, the format specifies

the type of protocol used at both layer two and layer three and the length of addresses used

at each of these layers. It then includes space for all four of the address combinations we

saw in the previous topic.

The format used for ARP messages is described fully in Table 43, and illustrated in Figure

49.

Table 43: Address Resolution Protocol (ARP) Message Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

HRD 2

PRO 2

Protocol Type: This field is the complement of the Hardware Type field,

specifying the type of layer three addresses used in the message. For IPv4

addresses, this value is 2048 (0800 hex), which corresponds to the

EtherType code for the Internet Protocol.

ware

ype:

Thi

spec

ifi

ype o

ware use

oca

network transmitting the ARP message; thus, it also identifies the type of

addressing used. Some of the most common values for this field:

HRD Value Hardware Type

1 Ethernet (10 Mb)

6 IEEE 802 Networks

7 ARCNET

15 Frame Relay

16 Asynchronous Transfer Mode (ATM)

17 HDLC

18 Fibre Channel

19 Asynchronous Transfer Mode (ATM)

20 Serial Line

HLN 1

Hardware Address Length: Specifies how long hardware addresses are

in this message. For Ethernet or other networks using IEEE 802 MAC

addresses, the value is 6.

PLN 1

Protocol Address Length: Again, the complement of the preceding field;

specifies how long protocol (layer three) addresses are in this message.

For IP(v4) addresses this value is of course 4.

OP 2

SHA

(Variable,

equals

value in

HLN field)

Sender Hardware Address: The hardware (layer two) address of the

device sending this message (which is the IP datagram source device on a

request, and the IP datagram destination on a reply, as discussed in the

topic on ARP operation).

SPA

(Variable,

equals

value in

PLN field)

Sender Protocol Address: The IP address of the device sending this

message.

THA

(Variable,

equals

value in

HLN field)

Target Hardware Address: The hardware (layer two) address of the

device this message is being sent to. This is the IP datagram destination

device on a request, and the IP datagram source on a reply)

TPA

(Variable,

equals

value in

PLN field)

Target Protocol Address: The IP address of the device this message is

being sent to.

Table 43: Address Resolution Protocol (ARP) Message Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

pco

Thi

spec

ifi

e na

ure o

ARP

message

ng sen

The first two values (1 and 2) are used for regular ARP. Numerous other

values are also defined to support other protocols that use the ARP frame

format, such as RARP, some of which are more widely used than others:

Opcode ARP Message Type

1 ARP Request

2 ARP Reply

3 RARP Request

4 RARP Reply

5 DRARP Request

6 DRARP Reply

7 DRARP Error

8 InARP Request

9 InARP Reply

After the ARP message has been composed it is passed down to the data link layer for

transmission. The entire contents of the message becomes the payload for the message

actually sent on the network, such as an Ethernet frame. Note that the total size of the ARP

message is variable, since the address fields are of variable length. Normally, though, these

messages are quite small: for example, they are only 28 bytes for a network carrying IPv4

datagrams in IEEE 802 MAC addresses.

ARP Caching

ARP is a dynamic resolution protocol, which means that every resolution requires the inter-

change of messages on the network. Each time a device sends an ARP message, it ties up

the local network, consuming network bandwidth that cannot be used for “real” data traffic.

ARP messages aren't large, but having to send them for every hop of every IP datagram

would represent an unacceptable performance hit on the network. It also wastes time

compared to the simpler direct mapping method of resolution. On top of this, the ARP

Request message is broadcasted, which means every device on the local network must

spend CPU time examining the contents of each one.

The general solution to the efficiency issues with dynamic resolution is to employ caching,

which I described in general terms in the section on address resolution concepts. In

addition to reducing network traffic, caching also ensures that the resolution of commonly-

used addresses is fast, making overall performance comparable to direct mapping. For this

reason, caching functionality has been built into ARP from the start.

Figure 49: Address Resolution Protocol (ARP) Message Format

The ARP message format is designed to accommodate layer two and layer three addresses of various sizes.

This diagram shows the most common implementation, which uses 32 bits for the layer three (“Protocol”)

addresses, and 48 bits for the layer two hardware addresses. These numbers of course correspond to the

address sizes of the Internet Protocol version 4 and IEEE 802 MAC addresses, used by Ethernet.

Hardware Type Protocol Type

Hardware Address

Length

Protocol Address

Length

Opcode

Target Protocol Address

4 8 12 16 20 24 28 320

Sender Hardware Address

Sender Protocol Address

(bytes 3-4)

Target Hardware Address

Sender Protocol Address

(bytes 1-2)

Static and Dynamic ARP Cache Entries

The ARP cache takes the form of a table containing matched sets of hardware and IP

addresses. Each device on the network manages its own ARP cache table. There are two

different ways that cache entries can be put into the ARP cache:

☯ Static ARP Cache Entries: These are address resolutions that are manually added to

the cache table for a device and are kept in the cache on a permanent basis. Static

entries are typically managed using a tool such as the arp software utility.

☯ Dynamic ARP Cache Entries: These are hardware/IP address pairs that are added

to the cache by the software itself as a result of successfully-completed past ARP

resolutions. They are kept in the cache only for a period of time and are then removed.

A device's ARP cache can contain both static and dynamic entries, each of which has

advantages and disadvantages. However, dynamic entries are used most often because

they are automatic and don't require administrator intervention.

Static ARP entries are best used for devices that a given device has to communicate with

on a regular basis. For example, a workstation might have a static ARP entry for its local

router and file server. Since the entry is static it is always found in step #1 of the ARP trans-

action process, there is no need to ever send resolution messages for the destination in that

entry. The disadvantage is that these entries must be manually added, and they must also

be changed if the hardware or IP addresses of any of the hardware in the entries change.

Also, each static entry takes space in the ARP cache, so you don't want to “overuse” static

entries. It wouldn't be a good idea to have static entries for every device on the network, for

example.

Cache Entry Expiration

Dynamic entries are added automatically to the cache on an “as needed” basis, so they

represent mappings for hosts and routers that a given device is actively using. They do not

need to be manually added or maintained. However, it is also important to realize that

dynamic entries cannot be added to the cache and left there forever. The reason for this is

that due to changes in the network, dynamic entries left in place for a long time can become

stale.

Consider device A's ARP cache, which contains a dynamic mapping for device B, another

host on the network. If dynamic entries stayed in the cache forever, the following situations

might arise:

☯ Device Hardware Changes: Device B might experience a hardware failure that

requires its network interface card to be replaced. The mapping in device A's cache

would become invalid, since the hardware address in the entry is no longer on the

network.

☯ Device IP Address Changes: Similarly, the mapping in device A's cache also would

become invalid if device B's IP address changed.

☯ Device Removal: Suppose device B is removed from the local network. Device A

would never need to send to it again at the data link layer, but the mapping would

remain in device A's cache, wasting space and possibly taking up search time.

To avoid these problems, dynamic cache entries must be set to automatically expire after a

period of time. This is handled automatically by the ARP implementation, with typical

timeout values being 10 or 20 minutes. After a particular entry times out, it is removed from

the cache. The next time that address mapping is needed a fresh resolution is performed to

update the cache. This is very slightly less efficient than static entries, but sending two 28-

byte messages every 10 or 20 minutes isn't a big deal.

As mentioned in the overview of ARP operation, dynamic cache entries are added not only

when a device initiates a resolution, but when it is the destination device as well. This is

another enhancement that reduces unnecessary address resolution traffic.

Additional Caching Features

Other enhancements are also typically put into place, depending on the implementation.

Standard ARP requires that if device A initiates resolution with a broadcast, each device on

the network should update its own cache entries for device A even if they are not the device

that A is trying to reach. However, these “third party” devices are not required to create new

cache entries for A in this situation.

The issue here is a trade-off: creating a new cache entry would save any of those devices

from needing to resolve device A's address in the near future. However, it also means every

device on the network will quickly have an ARP cache table filled up with the addresses of

most of the other devices on the network. This may not be desirable in larger networks.

Even in smaller ones, this model may not make sense, given that modern computing is

client/server in nature and peer devices on a LAN may not often communicate directly.

Some devices may choose to create such cache entries, but set them to expire after a very

short time to avoid filling the cache.

Each ARP implementation is also responsible for any other “housekeeping” required to

maintain the cache. For example, if a device is on a local network with many hosts and its

cache table is too small, it might be necessary for older, less-frequently-used entries to be

removed to make room for newer ones. Ideally, the cache should be large enough to hold

all other devices on the network that a device communicates with on a regular basis, along

with some room for ones it occasionally talks to.

Proxy ARP

ARP was designed to be used by devices that are directly connected on a local network.

Each device on the network should be capable of sending both unicast and broadcast

transmissions directly to each other one. Normally, if device A and device B are separated

by a router, they would not be considered local to each other. Device A would not send

directly to B or vice-versa; they would send to the router instead at layer two, and would be

considered “two hops apart” at layer three.

Why Proxy ARP Is Needed

In contrast to the normal situation, in some networks there might be two physical network

segments connected by a router that are in the same IP network or subnetwork. In other

words, device A and device B might be on different networks at the data link layer level, but

on the same IP network or subnet. When this happens, A and B will each think the other is

on the local network when they look to send IP datagrams.

In this situation, suppose that A wants to send a datagram to B. It doesn't have B's

hardware address in the cache, so it begins an address resolution. When it broadcasts the

ARP Request message to get B's hardware address, however, it will quickly run into a

problem: B is in fact not on A's local network. The router between them will not pass A's

broadcast onto B's part of the network, because routers don't pass hardware-layer broad-

casts. B will never get the request and thus A will not get a reply containing B’s hardware

address.

Proxy ARP Operation

The solution to this situation is called ARP proxying or Proxy ARP. In this technique, the

router that sits between the local networks is configured to respond to device A's broadcast

on behalf of device B. It does not send back to A the hardware address of device B; since

they are not on the same network, A cannot send directly to B anyway. Instead, the router

sends A its own hardware address. A then sends to the router, which forwards the message

to B on the other network. Of course, the router also does the same thing on A's behalf for

B, and for every other device on both networks, when a broadcast is sent that targets a

device not on the same actual physical network as the resolution initiator. This is illustrated

in Figure 50.

Proxy ARP provides flexibility for networks where hosts are not all actually on the same

physical network but are configured as if they were at the network layer. It can be used to

provide support in other special situations where a device cannot respond directly to ARP

message broadcasts. It may be used when a firewall is configured for security purposes. A

type of proxying is also used as part of the Mobile IP protocol, to solve the problem of

address resolution when a mobile device travels away from its home network.

Key Concept: Since ARP relies on broadcasts for address resolution, and broad-

casts are not propagated beyond a physical network, ARP cannot function between

devices on different physical networks. When such operation is required, a device,

such as a router, can be configured as an ARP proxy to respond to ARP requests on the

behalf of a device on a different network.

Advantages and Disadvantages of Proxying

The main advantage of proxying is that it is transparent to the hosts on the different physical

network segments. The technique has some drawbacks though. First, it introduces added

complexity. Second, if more than one router connects two physical networks using the

same network ID, problems may arise. Third, it introduces potential security risks; since it

essentially means that a router “impersonates” devices in acting as a proxy for them, raising

the potential for a device to spoof another. For these reasons, it may be better to redesign

the network so routing is done between physical networks separated by a router, if possible.

Figure 50: ARP Proxy Operation

In this small internetwork, a single router connects two LANs that are on the same IP network or subnet. The

router will not pass ARP broadcasts, but has been configured to act as an ARP proxy. In this example, device

A and device D are each trying to send an IP datagram to the other, and so each broadcasts an ARP Request.

The router responds to the request sent by Device A as if it were Device D, giving to A its own hardware

address (without propagating Device A’s broadcast.) It will forward the message sent by A to D on D’s

network. Similarly, it responds to Device D as if it were Device A, giving its own address, then forwarding what

D sends to it over to the network where A is located.

Device A

IP Addr: IPA

Hardware Addr: #213

Device B

IP Addr: IPB

Hardware Addr: #79

Device E

IP Addr: IPE

Hardware Addr: #35

Device C

IP Addr: IPC

Hardware Addr: #46

Who Is IPD?

IPD is #17

Device D

IP Addr: IPD

Hardware Addr: #114

Who Is IPA?

IPA is #17

Workgroup

Router

Hardware Addr: #17