Talk:Address Resolution Protocol

Bold text osi model each model in graphicaly

Isn't ARP a link layer protocol in TCP/IP stack? --Jambalaya 08:15, 12 Apr 2005 (UTC)

ARP is a protocol for mapping network layer addresses to link layer addresses. Effectively it sits in-between IP and the data-link layer. However, considering it sits above the data-link layer and effectively runs parallel to IP (ARP really isn't technically needed if the users already knew the network layer addresses and the MAC addresses), it makes sense to be a layer 3. It is a layer 3 in both the TCP/IP stack and the OSI model. --huwr 12:44, 12 Apr 2005 (UTC)

But, ARP is part of Ethernet specification which is data link layer protocol (let me remind that OSI model was created inter alia to seperate standards), ARP is strictly connected to Ethernet standard not to IP, thre are many types of IP networks, that don't use ARP, but all networks based on ethernet on link layer uses ARP. Even Stevens, the author of "TCP/IP Illustrated" ("the bible" ;) ) classifies ARP as data link protocol. Therefore I postulate to move ARP to data link layer.

Please forgive me my english, I'm from Europe, and consider my arguments.

--20 October 2006 —The preceding unsigned comment was added by 83.5.250.3 (talk • contribs) 12:12, 20 October 2006 (UTC).[reply]

Conceptually, ARP belongs to the network layer. Why's that? Because it does not fit into any of the traditional data link functions: flow and access control, error detection/correction, encapsulation, etc, and does fit in the network layer, IMO, because its function is to help routing packages to their destinations by descovering which MAC is bound to which IP. In Tanenbaum's Computer Networks, 4th edition, ARP is described in the Network layer chapter. I think ARP could be seen as a network layer service for translating network layer SAP's (i.e. IP addresses) into data link SAP's (i.e. MAC addresses). Moreover, without the existence of a network making use of the data link, ARP loses its sense entirely, whilst the data link will continue to provide its services as before. I for one vote it to be moved to the network level, where I think it belongs. Diego.pereira 21:58, 18 March 2007 (UTC)[reply]

ARP is not part of the Ethernet specification, and it's not tied to Ethernet; it's also used with Token Ring, FDDI, and 802.11, for example. It's also not tied to IP. It provides a service that multiple link layers and multiple network-layer protocols use. Guy Harris 22:28, 18 March 2007 (UTC)[reply]

I was using the IP/MAC more in an illustrative fashion, and agree it is not tied to either Ethernet nor IP. But the point is that ARP definitely does not belong to the data link layer. I think it does belong to the network layer. Diego.pereira 20:08, 24 March 2007 (UTC)[reply]

ARP is a Layer 2 protocol for these reasons: 1) RFC 826 is entitled "An Ethernet Address Resolution Protocol" - not a "Network Address Resolution Protocol". We all agree that Ethernet is Layer 2, let's substitute "Ethernet" with "Layer 2" in the RFC name, and we have "A Layer 2 Address Resolution Protocol". 2) ARP is used to enable local communications (e.g., Logical Link) -- not remote communications (e.g., Network) 3) ARP frames do not contain Layer 3 fields for identifying source and destinations to network forwarding devices. 4) Layer 3 protocols fall into either of two categories: Routed Protocols, and Routing Protocols. ARP frames are forwarded by Layer 2 addressing (e.g., the Ethernet MAC address) -- not Layer 3 addressing (e.g., the IP address -- as are all other Network protocols such as IP, ICMP, etc.) thus it is not a routed protocol; additionally, ARP is not used as the control plane for making Layer 3 forwarding decisions -- thus it is not a routing protocol. Thus, ARP does not walk like a Layer 3 protocol, talk like a Layer 3 protocol, or act like a Layer 3 protocol: it is not a Layer 3 protocol. It does walk, talk, and act like a Layer 2 protocol: it is a Layer 2 protocol. Kevin Davis —Preceding unsigned comment added by 64.129.167.114 (talk) 19:16, 3 March 2008 (UTC)[reply]

Except... Layer two, by it's very definition, knows absolutely nothing about layer 3 or higher, and yet ARP must know about layer 3 addresses. Really, ARP belongs between layers 2 and 3, but if it had to be assigned to one or the other, I would have to agree with the argument to push it into the higher layer. Further, I would disagree with categorising ethernet as a layer two protocol, as it has quite a lot of layer one about it - it specifies the medium, and signalling details as well as the linklayer details. --RobbieAB (talk) 06:17, 21 June 2008 (UTC)[reply]

I was actually looking for gratuitous ARP and found a thorough explanation over here: Gratuitous ARP Worth mentioning or linking to it? Guenthert 00:37, 28 January 2006 (UTC)[reply]

I was looking for it too, so it's a definent 'yes' from me Thedarxide 10:34, 24 May 2006 (UTC)[reply]

Shouldn't something be mentioned about IPv6 ARP? Or does the equivalent of ARP in IPv6 have another name? I found a site with some more information (look for section 3.2.4.3. Solicited node link-local multicast address). --Bernard François 13:09, 22 May 2006 (UTC)[reply]

IPv6 uses Neighbor Discovery Protocol, which uses ICMPv6. --131.159.0.17 11:52, 18 July 2006 (UTC)[reply]

Other hosts on network caching reply

How does this occur? Surely the reply packet is sent only to the sender of the request, and therefore it never reaches the other hosts on the network? QmunkE 18:43, 1 June 2006 (UTC)[reply]

-- Yeah, I think this has been changed in the document, but not in the pdf diagram at the bottom quote "Host 1 now has a mapping from Host 3 IP address to Host 3 MAC address. This entry is updated in the ARP Cache In this process, Host 2 has obtained the mapping for Host1 and Host 3 for free, without exchanging a single packet! Similarly Host 3 has obtained a mapping for Host 1" Someone should change this if it's incorrect -I have another source(lecture notes) which say "ARP replies are not broadcasted, as not every workstation needs to know the result of the query" 20:42, 8 November 2006 (NZ time) —The preceding unsigned comment was added by 203.97.116.147 (talk • contribs) 00:42, 8 November 2006 (UTC).[reply]

Timeout

I notice the article says "Once an IP address has been resolved to a hardware address it will remain in the ARP cache for 2 minutes". Isn't this an adjustable, system-dependent parameter? I'm not an expert, but I read that, in the case of Linux, "the entry is considered to be valid for at least a random value between "base_reachable_time/2 and 3*base_reachable_time/2 ... Defaults to 30 seconds" 216.13.180.74 01:35, 13 April 2007 (UTC)[reply]

I am also baffled by these fixed timeout values. RFC 826 section "Related Issue" suggests that a timeout mechanism may be desirable, but does not specify it's implementation. RFC 1122 section 2.3.2.1 states that an ARP cache implementation MUST have an invalidation mechanism, and "if this mechanism involves a timeout, it SHOULD be possible to configure the timeout value." I think we should replace the description of the invalidation mechanism with something more liberal. Picci 18:32, 3 June 2007 (UTC)[reply]

Yes. I've removed the stuff about timeouts, as it describes a particular implementation technique, not a protocol requirement. Guy Harris 18:42, 3 June 2007 (UTC)[reply]

Manually adding entries to the ARP cache

An entry into the ARP cache can also happen manually by adding a static entry. This can be done by going to the command prompt and entering arp-s <ip address> <MAC address>.

Uh, isn't this very OS specific? At least the command part. If the command should be specified in the article at all, shouldn't the OS it is available in be specified? 194.237.142.7 08:19, 10 May 2007 (UTC)[reply]

I think most Unix-like OSes, as well as Microsoft Windows, have adopted the BSD syntax, so that command will probably work on most OSes. However, there might well be OSes that don't support it (especially embedded OSes, which might not support it simply because they might not have a command line - or even a mechanism on which to type a command).

On the other hand, Wikipedia is not an instruction manual, so I'm not sure anything about how to add entries to the ARP table belongs here (RFC 826 uses the term "table", not "cache"). Guy Harris 08:58, 10 May 2007 (UTC)[reply]

Actually I just checked if there was an arp-s command in my Win XP Pro installation at home and there isn't. Tried at work too when I wrote the previous comment, but I wasn't sure if it had just been blocked by the administrators. And if it works in most OSes IMO the article should say "In most OSes bla bla" or something similar, it shouldn't be put like it's some universal truth. 213.101.208.38 21:27, 10 May 2007 (UTC)[reply]

Where does this info come from?

There are four types of ARP messages that can be sent. The ARP request, ARP reply, RARP request, and the RARP reply. In an ARP request, the local host requests the physical address of the destination hardware from the destination host. The address reply from the destination host is the ARP reply. Not only does the destination host send a reply but it also sends RARP request that will verify sender’s hardware address. Once the addresses are verified the transmission of the packet will begin.

RARP is a separate protocol with Ethernet type 0x8035. I've never read that it could/should be used in conjunction with ARP to verify the sender's hardware address. It's purpose is to obtain a protocol address at network stack configuration stage. Moreover, RARP is basically extinct by now, replaced by BOOTP/DHCP. Or am I missing something?

You are not missing anything. That claim was just wrong. I've removed it. Guy Harris 18:43, 3 June 2007 (UTC)[reply]

ARP Request target hardware adress

From ARP wiki article Target hardware address (THA) Hardware address of the intended receiver. This field is zero on request

Isn't zero just a customary behavior, as based on ARP RFC 826 this value can be anything Attached a few quotes from the RFC : 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.

(ar$tha) = don't care Eldad 62.219.119.176 12:05, 11 September 2007 (UTC)[reply]