Address Resolution Protocol

From Citizendium
Jump to navigation Jump to search
This article may be deleted soon.
To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions.

For the monthly nomination lists, see
Category:Articles for deletion.


This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Address Resolution Protocol (ARP) originated as a specific protocol (computer) for finding the locality of networks|link-local address (MAC address or Ethernet address) corresponding to an Internet Protocol address to which a computer wants to send a packet.[1] An analogy might be that the medium-independent address might be "12 Main Street, Some City, some (country-specific) higher administrative entity". If you were at 10 Main Street of the same locality, however, the link-local or medium-specific address is of the form "the building on the left".

The "local versus remote assumption", one of the fundamental architectural principles of the Internet Protocol Suite, states that layer 2 connectivity exists among hosts sharing the same subnet (i.e., address prefix); the Address Resolution Protocol (ARP) is a means by which such hosts can learn the layer 2 (i.e., medium access control} address that it will need to communicate within the same subnet. Also under the local versus remote assumption, if the destination is on a different subnet, it is appropriate to send the packet to the link-local address of a router on the same medium, which will forward the packet in the direction of the desired subnet.[1] ARP is a relatively simple protocol, although some unexpected problems came up in its initial implementation. ARP is intended for use on multicasting|broadcast-capable multiaccess medium such as local area networks. It is not needed on point-to-point networks, but the basic ARP mechanism does not work on nonbroadcast multiaccess medium (NBMA). Other methods are needed to communicate at layer 2 on NBMA media, or, in some cases, to establish that layer 2 communication is not possible on the same subnet. [2]

Other media than broadcast-capable Ethernet

The original ARP assumed a medium that supported multicasting the ARP request, perhaps to a selected multicast group of destinations on a shared medium, perhaps a broadcast to all destinations. Informally, the request would say "If you have this IP address, please respond to me with your MAC address). Link-local addressing applies to other kinds of media than LANs, and the problem of mapping between a logical address and a medium address is not unique to it.

On a medium that does not support multicasting or broadcasting, but rather many individual transmissions over single, or sets of single, connections, different methods have to be used. Some techniques, especially when the medium topology is hub-and-spoke so the hub could retransmit the message to each destinations, could simulate multicast. This had a computational cost of copyuing and retransmitting many copies of the same message.

Inverse Address Resolution Protocol (InARP), for example, is used on a nonbroadcast multiple access (NMBA) medium such as Frame Relay.[2]

Implementation issues

  • failure recovery and avoiding broadcast storms
  • ARP cache
  • Proxy ARP
  • IP address collision detection [3]

IP version 6

ARP is not needed in IPv6; the Neighbor Discovery mechanism replaces it.

References

  1. 1.0 1.1 Plummer D. (November 1982), Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware., RFC826 Cite error: Invalid <ref> tag; name "RFC826" defined multiple times with different content
  2. 2.0 2.1 T. Bradley, C. Brown, A. Malis (September 1998), Inverse Address Resolution Protocol, RFC2390 Cite error: Invalid <ref> tag; name "RFC2390" defined multiple times with different content
  3. Cheshire S. (July 2008), IPv4 Address Conflict Detection, RFC5227