ARP1--概念

An Ethernet Address Resolution Protocol (rfc 826)

At nearly every layer of a network architecture there are several potential protocols that could be used.The 10Mbit Ethernet allows all of these protocols (and more) to coexist on a single cable by means of a type field in the Ethernet packet header. However, the 10Mbit Ethernet requires 48.bit addresses on the physical cable, yet most protocol addresses are not 48.bits long, nor do they necessarily have any relationship to the 48.bit Ethernet address of the hardware. A protocol is needed to dynamically distribute the correspondences between a <protocol, address> pair and a 48.bit Ethernet address.

Definitions:
------------
Define the following for referring to the values put in the TYPE field of the Ethernet packet header:
ether_type$XEROX_PUP,
ether_type$DOD_INTERNET,
ether_type$CHAOS,
and a new one:
ether_type$ADDRESS_RESOLUTION.
Also define the following values (to be discussed later):
ares_op$REQUEST (= 1, high byte transmitted first) and
ares_op$REPLY (= 2),
and
ares_hrd$Ethernet (= 1).

Packet format:
--------------

To communicate mappings from <protocol, address> pairs to 48.bit Ethernet addresses, a packet format that embodies the Address Resolution protocol is needed. The format of the packet follows.

Ethernet transmission layer :

1. 48.bit: Ethernet address of destination
2. 48.bit: Ethernet address of sender
3. 16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION Ethernet packet data:
4. 16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,Packet Radio Net.)
5. 16.bit: (ar$pro) Protocol address space. For Ethernet hardware, this is from the set of type fields ether_typ$<protocol>.
6. 8.bit: (ar$hln) byte length of each hardware address
7. 8.bit: (ar$pln) byte length of each protocol address
8. 16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)
9. nbytes: (ar$sha) Hardware address of sender of this packet, n from the ar$hln field.
10. mbytes: (ar$spa) Protocol address of sender of this packet, m from the ar$pln field.
11. nbytes: (ar$tha) Hardware address of target of this packet (if known).
12. mbytes: (ar$tpa) Protocol address of target.

Packet Generation:
------------------

1. As a packet is sent down through the network layers, routing determines the protocol address of the next hop for the packet and on which piece of hardware it expects to find the station with the immediate target protocol address.
   
2. In the case of the 10Mbit Ethernet, address resolution is needed and some lower layer (probably the hardware driver) must consult the Address Resolution module (perhaps implemented in the Ethernet support module) to convert the <protocol type, target protocol address> pair to a 48.bit Ethernet address.
3. The Address Resolution module tries to find this pair in a table. If it finds the pair, it gives the corresponding 48.bit Ethernet address back to the caller (hardware driver) which then transmits the packet.
4.  If it does not, it probably informs the caller that it is throwing the packet away (on the assumption the packet will be retransmitted by a higher network layer), and generates an Ethernet packet with a type field of ether_type$ADDRESS_RESOLUTION.
   
5. The Address Resolution module then sets the
   
   1. ar$hrd field to ares_hrd$Ethernet
   2. ar$pro to the protocol type that is being resolved
   3. ar$hln to 6 (the number of bytes in a 48.bit Ethernet address)
   4. ar$pln to the length of an address in that protocol
   5. ar$op to ares_op$REQUEST
   6. ar$sha with the 48.bit ethernet address of itself
   7. ar$spa with the protocol address of itself
   8. ar$tpa with the protocol address of the machine that is trying to be accessed
   9. It does not set ar$tha to anything in particular, because it is this value that it is trying to determine.It could set ar$tha to the broadcast address for the hardware (all ones in the case of the 10Mbit Ethernet) if that makes it convenient for some aspect of the implementation.
6. It then causes this packet to be broadcast to all stations on the Ethernet cable originally determined by the routing mechanism.

Packet Reception:
-----------------

Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
Do I speak the protocol in ar$pro?

Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address field of the entry with the newinformation in the packet and set Merge_flag to true.
Am I the target protocol address?

Yes:
If Merge_flag is false, add the triplet <protocol type, sender protocol address, sender hardware address> to the translation table.
Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)

Yes:
Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on the same hardware on which the request was received.

Notice that the <protocol type, sender protocol address, sender hardware address> triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A. Notice also that if an entry already exists for the <protocol type, sender protocol address> pair, then the new hardware address supersedes the old one.

Generalization: The ar$hrd and ar$hln fields allow this protocol and packet format to be used for non-10Mbit Ethernets. For the 10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For other hardware networks, the ar$pro field may no longer correspond to the Ethernet type field, but it should be associated with the protocol whose address resolution is being sought.

1. When a monitor receives an Address Resolution packet
2. it always enters the <protocol type, sender protocol address, sender hardware address> in a table.
   
3. It can determine the length of the hardware and protocol address from the ar$hln and ar$pln fields of the packet.
4. If the opcode is a REPLY the monitor can then throw the packet away.
   
5. If the opcode is a REQUEST and the target protocol address matches the protocol address of the monitor, the monitor sends a REPLY as it normally would.
   
6. The monitor will only get one mapping this way, since the REPLY to the REQUEST will be sent directly to the requesting host.
   
7. The monitor could try sending its own REQUEST, but this could get two monitors into a REQUEST sending loop, and care must be taken.

An Example:
-----------

1. Let there exist machines X and Y that are on the same 10Mbit Ethernet cable.
   
2. They have Ethernet address EA(X) and EA(Y) and DOD Internet addresses IPA(X) and IPA(Y) .
3.  Let the Ethernet type of Internet be ET(IP).
4.  Machine X has just been started, and sooner or later wants to send an Internet packet to machine Y on the same cable.
   
5. X knows that it wants to send to IPA(Y) and tells the hardware driver (here an Ethernet driver) IPA(Y).
   
6. The driver consults the Address Resolution module to convert <ET(IP), IPA(Y)> into a 48.bit Ethernet address, but because X was just started, it does not have this information. It throws the Internet packet away and instead creates an ADDRESS RESOLUTION packet with
   (ar$hrd) = ares_hrd$Ethernet
   (ar$pro) = ET(IP)
   (ar$hln) = length(EA(X))
   (ar$pln) = length(IPA(X))
   (ar$op) = ares_op$REQUEST
   (ar$sha) = EA(X)
   (ar$spa) = IPA(X)
   (ar$tha) = don’t care
   (ar$tpa) = IPA(Y)
   and broadcasts this packet to everybody on the cable.
7. Machine Y gets this packet, and determines that it understands the hardware type (Ethernet), that it speaks the indicated protocol (Internet) and that the packet is for it ((ar$tpa)=IPA(Y)).
   
8. It enters (probably replacing any existing entry) the information that <ET(IP), IPA(X)> maps to EA(X).
   
9. It then notices that it is a request, so it swaps fields, putting EA(Y) in the new sender Ethernet address field (ar$sha), sets the opcode to reply, and sends the packet directly (not broadcast) to EA(X). At this point Y knows how to send to X, but X still doesn’t know how to send to Y.
10. Machine X gets the reply packet from Y, forms the map from <ET(IP), IPA(Y)> to EA(Y), notices the packet is a reply and throws it away.
    
11. The next time X’s Internet module tries to send a packet to Y on the Ethernet, the translation will succeed, and the packet will (hopefully) arrive.
    
12. If Y’s Internet module then wants to talk to X, this will also succeed since Y has remembered the information from X’s request for Address Resolution.