Talk:Address Resolution Protocol/Archive 1

Archive 1

IPv6 ARP

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)

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

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)

-- 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).

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)

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)

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)

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)

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)

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)

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)

Is the example correct?

Hi,

This is an excerpt from the RFC:

Let there exist machines X and Y that are on the same 10Mbit Ethernet cable. They have Ethernet address EA(X) and EA(Y) and DOD Internet addresses IPA(X) and IPA(Y) . Let the Ethernet type of Internet be ET(IP). Machine X has just been started, and sooner or later wants to send an Internet packet to machine Y on the same cable. X knows that it wants to send to IPA(Y) and tells the hardware driver (here an Ethernet driver) IPA(Y). 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.

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)). It enters (probably replacing any existing entry) the information that <ET(IP), IPA(X)> maps to EA(X). 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.

So shouldn't receiver and sender be swapped in the response? Also, when watching ARP packets on my machine, the Hardware Destination Address is all zero (and not all F..F as described), the RFC says it is don't care. This probably has nothing to do with Broadcast anyway: Whether the packet is boradcast or not would be a F..F in the Destination MAC Address Field of the Ehternet Type II Frame Header.

Since I'm not a native english speaker, I hope someone who can read and understand the RFC can correct this. —Preceding unsigned comment added by 212.86.197.209 (talk) 15:38, 22 October 2008 (UTC)

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)

"The ARP type (0x0806) should never be used in the PTYPE field of an ARP packet, since a hardware protocol address should never be linked to the ARP protocol." - I find this statement most unclear. I believe that the comment above is right. However, his correction is not visible on the page. Doru001 (talk) 11:16, 29 January 2009 (UTC)

OSI model discussion

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).

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)

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)

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)

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)

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)

You can't have it both ways: you state that ARP can't be Layer 2 because it deals with Layer 3 issues, and yet postulate that Ethernet is Layer 1 though it deals with Layer 2 issues. Which is it? You can't eat your cake and have it too. Might I also mention that Ethernet is formally defined by IEEE 802.3 as "a standard data link layer protocol", e.g., Layer 2. The statement "Layer two, by it's very definition, knows absolutely nothing about layer 3" is a bit off (if not more), as will be evident in a moment. Now, back to ARP. Is ARP a routable protocol? No. Let's name some other Layer 3 protocols: IP, ICMP, IPX, AppleTalk, OSPF, BGP, EIGRP, RIP. What do they all have in common? They are *routable* by a Layer 3 address. I do not know of a single Layer 3 protocol that is not routable. ARP does not have a routable Layer 3 address, and such is one of the reasons it is not Layer 3. Now, are there other Layer 2 protocols that deal with Layer 3 issues such as IP addresses? Certainly, take PPP as an example. PPP has two subfunctions: LCP and NCP. NCP (Network Control Protocol) deals with Layer 2 to Layer 3 negotiation/mapping issues. What? A Layer 2 dealing with IP addresses? Yes, as does the Layer 2 protocol, ARP. I might also mention that Ethernet specifies the Layer 3 protocol (e.g., IPv4, etc.) in its header. Will you now move it from your "Layer 1" to "Layer 3" because of that? And what was that about Layer 2 knowing nothing about Layer 3? I am quite sure it doesn't hold much water. ;) Kevin Davis 11:02, 10 December 2008

Two points - 1/ The OSI model is just a model. Sometimes the real world does not fit neatly into our models. It is not something to get too stressed about. 2/ In my expereience, after people have run out of air arguing layer 2 vs. layer 3 for something like this, they are generally willing to concede that the protocol/services straddle layers. It can be called a "transitional" protocol. The term "Layer 2.5" is used in some circles.

The article currently calls ARP a link layer (layer 2) protocol. In light of the discussion here, that's probably an overly simplified position. In keeping with my point 1 above, I'm not going to jump in and edit the article. --Kvng (talk) 17:32, 13 December 2008 (UTC)

Please note that Link Layer is a TCP/IP term and by no means identical to Layer 2 of OSI, rather L2 may be mapped into the Link Layer. ARP is squarely a Link Layer protocol, as it only operates on the local link and is not IP routable. I have expanded the Operating Scope section, to clarify for OSI afficionados Kbrose (talk) 19:16, 13 December 2008 (UTC)

If a protocol is not routeable, it doesn't mean it can't belong to layer 3. Let me pull a simple example. Because most birds can fly, it doesn't mean an ostrich is not a bird. Also if Ethernet is a layer 2 protocol, ARP can't be layer 2 since it uses an Ethernet frame already. Also yes, the RFC write about "Ethernet ARP", which just means ARP meant to resolve INTO Ethernet addresses. BTW with this discussion, whereto put NDP? It's actually an ICMPv6 packet, which travels in an IPv6 frame, which travels in an Ethernet frame, so it's layer 4 (!), should we put that into layer 2 too? I don't think so. —Preceding unsigned comment added by 195.70.49.211 (talk) 16:13, 5 March 2009 (UTC)

Also two notices on Kevin Davis' comment: ICMP is at layer 4, it already using an IP frame, and BGP is layer 5+, it is over TCP (port 179 to be more precise). Also consider DHCP, its like RARP, yet it uses UDP frames, so DHCP is at layer 5+, while DHCP is not meant to be routed. —Preceding unsigned comment added by 195.70.49.211 (talk) 16:28, 5 March 2009 (UTC)

Gratuitous ARP

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)

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

I'd say that Gratuitous ARP should probably be covered here. Anyone up for writing the section? —Preceding unsigned comment added by 15.203.137.73 (talk) 13:09, 25 August 2009 (UTC)

That section already exists in the article. It is called 'ARP announcement'. Do we want to change the name of the section? --Kvng (talk) 14:53, 25 August 2009 (UTC)

No, I noticed that as well now, it can be left as is. The section mentions the words "gratuitous ARP" so that is quite clear. —Preceding unsigned comment added by 15.203.137.73 (talk) 13:49, 26 August 2009 (UTC)

Packet structure examples

• Hello, I've restored the request and response examples below from the article that Kbrose deleted twice from the article. The examples served as an illustration; nothing to do with a "manual". I put the examples here for broader discussion and opinion of other editors. If there is a consensus to keep the examples in the main article, please restore them there. Thanks. --Mokhov (talk) 18:58, 2 October 2009 (UTC)

---

ARP request example

If a host with the IPv4 address 10.10.10.123 and MAC address 00:09:58:D8:11:22 needs to send a packet to another host with the IP address 10.10.10.140, but does not have its MAC address, then the host sends an ARP request to resolve the unknown address. The packet illustrated below is an example of a broadcast request. If a host with the IP 10.10.10.140 is connected and reachable, then it receives this ARP request and sends back a reply.

+ Bits 0 – 7 8 – 15 16 – 31 0 Hardware type = 0x0001 Protocol type = 0x0800 32 Hardware length = 6 Protocol length = 4 Operation = 1 64 SHA (first 32 bits) = 0x000958D8 96 SHA (last 16 bits) = 0x1122 SPA (first 16 bits) = 0x0A0A 128 SPA (last 16 bits) = 0x0A7B THA (first 16 bits) = 0x0000 160 THA (last 32 bits) = 0x00000000 192 TPA = 0x0A0A0A8C

ARP response example

According to the above scenario, if a host with the IP address 10.10.10.140 has a MAC address 00:09:58:D8:33:AA, then it will send a response packet illustrated below. Notice, the address fields of the sender and receiver now have their values exchanged (the sender of a response is a receiver of a request; the receiver of a reply is the sender of the request). Additionally, the host 10.10.10.140 has filled in its MAC address in the filed of physical address of the sender. Any host in the same network segment as the sender and receiver will get the request (as it was broadcast) and may add into their cache the sender's information. The ARP response is only sent to the source of the ARP request however, therefore the ARP response is not accessible to other hosts on the network.

+ Bits 0 – 7 8 – 15 16 – 31 0 Hardware type = 0x0001 Protocol type = 0x0806 32 Hardware length = 6 Protocol length = 4 Operation = 2 64 SHA (first 32 bits) = 0x000958D8 96 SHA (last 16 bits) = 0x33AA SPA (first 16 bits) = 0x0A0A 128 SPA (last 16 bits) = 0x0A8C THA (first 16 bits) = 0x0009 160 THA (last 32 bits) = 0x58D81122 192 TPA = 0x0A0A0A7B

---

There is no guideline that supports removing the example, and inclusion does not violate WP:NOTHOW. Furthermore, errors are handled by correction rather than section removal. Therefore, whether or not the example should be included will be resolved by consensus here: Is the material useful for this encyclopedic article? I believe the example is useful and should be included, although a couple of sentences might be trimmed from the text. I don't feel particularly strongly about this, and am happy to wait for further discussion. Johnuniq (talk) 04:03, 3 October 2009 (UTC)

I can see that the example is useful and contains errors and clarity problems. I don't feel qualified to weigh in on the "how to" question. I will point out that there's no text in the article that describes the ARP transaction. Describing the packet structure does not tell the whole story for a protocol. --Kvng (talk) 18:01, 3 October 2009 (UTC)

The example was error free in this version (this edit changed the protocol type in the example from 0x0800 to 0x0806, but 0x0800 is correct). Clarity can always be improved, but the example text is not unclear. Perhaps the section might be recast from an "example" to your suggestion of a description of a typical transaction. Johnuniq (talk) 08:43, 4 October 2009 (UTC)

Protocol overview section added

I agree with the earlier poster who wrote "I will point out that there's no text in the article that describes the ARP transaction. Describing the packet structure does not tell the whole story for a protocol...".

I've added a simply worded protocol overview section at the very start. The article used to launch straight into some rather abstract stuff about mapping to outdated OSI concepts, then straight into the packet structure. I want to start with functionality and the actual exchange of packets and I didn't see the word 'broadcast' up front. Would other wikipedians maybe pitch in and improve my first attempt?

I'd also like to say something (not necessarily up front) about the case where ARP requests fail, about routers and ARP, and about misuse/attacks. (Although the latter topic is covered in its own article, quite rightly, but a one-line mention of security aspects and a wiki-link would be nice.) I'd particularly appreciate contributions relating to routers/gateways and ARP.CecilWard (talk) 18:31, 12 April 2010 (UTC)

PTYPE

We've got two protocol identifiers we're working with and I think an editor has become confused. The ARP value (0x806) appears in the Ethernet header to identify ARP packets to the network. But, based on a review of the RFC, I believe it is the IP value (0x800) that appears in the body of the ARP packet in the PTYPE field that tells us what kind of addresses (IP) we're trying to resolve. I'm undoing some recent edits to keep others from getting confused as well. --Kvng (talk) 23:14, 14 August 2008 (UTC)

Just added a parenthetical note further clarifying this point. — Preceding unsigned comment added by 194.81.223.66 (talk) 09:34, 30 June 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Address Resolution Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20071012093401/http://www1.ietf.org:80/mail-archive/web/dhcwg/current/msg03797.html to http://www1.ietf.org/mail-archive/web/dhcwg/current/msg03797.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 04:26, 4 October 2016 (UTC)