Talk:Address Resolution Protocol

message: Since when ARP is a link-layer protocol? It runs ON TOP of the link-layer protocol, therefore it is itself a network layer protocol, like IP. Please correct this mistake.  — Preceding unsigned comment added by 95.220.220.190 (talk) 20:24, 6 June 2011 (UTC)
replies: text: I came to make exactly the same point.  Calling ARP "layer 2" is exactly like calling DNS "layer 3".  The issue of scope is not relevant, because layer 3 does lots of things that are local to a single network, like forwarding a packet one hop. I'll fix this. LachlanA (talk) 08:44, 6 May 2020 (UTC)
replies: text: Reading the citation of RFC 1122 attached to the statement, which is one of the defining documents of the Internet Protocol Suite, should suffice to understand the situation. Kbrose (talk) 22:43, 6 May 2020 (UTC)
replies: text:  can you be more specific about what we should be looking at in ?  has recently asserted that the RFC does not support the claim that ARP is a link-layer protocol. ~Kvng (talk) 14:24, 23 December 2021 (UTC)
replies: text: As it seems, the whole claim for "ARP is link layer" leans on RFC 1122 listing ARP in the Link Layer section. Of course, it's an essential part of IPv4's link-layer interface but the RFC doesn't explicitly state where ARP itself is located. --Zac67 (talk) 14:58, 23 December 2021 (UTC)
replies: text:  Of course it is an essential part of IPv4's link-layer interface, so why change anything when the definition and use are so clear, and the source is so authoritative? Almost no IETF spec makes explicit definitions of layer location for a particular protocol after the overview in 1122, except for general logistical or educational purposes. It is simply not directly of interest, not a goal, of TCP/IP. The IETF creates useful, working protocols, not theoretical or philosophical safaris. Readers will recognize the functionality in relation to other protocols. Layers enhance understanding of the suite, and no more than RFC 1122 is really needed. Sublayers or groupings add nothing to the success of a protocol. Yet, some papers do consider some of these aspects, IIRC, the progression of the OSPF papers hint at it (subnet vs. link operation). But protocols were not designed by a layer specification, nor did they ever have to conform to any specific interfaces for layers. Layers have never been defined beyond the original outline there, and the IETF has commented and confirmed the reasons. When such a prominent document as 1122, which has never been superseded, discusses protocols in their layer chapters, why would anyone doubt the intent of the authors, especially when ARP fits so well into the definition for the link layer in that document, the one I cited earlier.  The document shows that limited layering was found useful, and it makes the paper readable, modular layered software has been a benefit for the reasons that everyone understands. All this layer arguing today for TCP/IP protocols is only aggravated because people learn OSI in school, and then think they have to fit TCP/IP into the same structure. You see it in all these comments here, people use OSI language for concepts that don't belong there, to fit the mold. Of course the same is true for OSI layers when people try to fit TCP/IP protocols into those layers, and it is probably worse. Endless confusion, especially in the upper layers, but also for ARP. People have even invented new sublayers to make all this fit. But there is no practical value in that.  We already have the definitive statement of layers in 1122 for TCP/IP, and it is crystal-clear where ARP is discussed. All this was actually hashed out on WP many years ago, IIRC, but every few years someone comes along and wants to change history for some ill-conceived notions. kbrose (talk) 19:03, 23 December 2021 (UTC)
thread_title:  Layer of ARP 

message: I tried adding the following table but it broke the page and I'm at a loss as to how to add it.
ARP Packet Hardware Type (HTYPE)	ARP Packet Hardware Type (HTYPE)              	ARP Packet Hardware Type (HTYPE)
Value                           	Description                                   	Reference
0                               	Reserved                                      	RFC 5494
1                               	Ethernet                                      	--
2                               	Experimental Ethernet                         	--
3                               	Amateur Radio AX.25                           	--
4                               	Proteon ProNET Token Ring                     	--
5                               	Chaos                                         	--
6                               	IEEE 802                                      	--
7                               	ARCNET                                        	RFC 1201
8                               	Hyperchannel                                  	--
9                               	LanStar                                       	--
10                              	Autonet Short Address                         	--
11                              	LocalTalk (AFP)                               	--
12                              	LocalNet (IBM PCNet or SYTEK LocalNET)        	--
13                              	Ultra link                                    	--
14                              	SMDS                                          	--
15                              	Frame Relay                                   	--
16                              	ATM (Asynchronous Transmission Mode)          	--
17                              	HDLC                                          	--
18                              	Fibre Channel                                 	RFC 4338
19                              	ATM (Asynchronous Transmission Mode)          	RFC 2225
20                              	Serial Line                                   	--
21                              	ATM (Asynchronous Transmission Mode)          	--
22                              	MIL-STD-188-220                               	--
23                              	Metricom                                      	--
24                              	IEEE 1394 (1995)                              	--
25                              	MAPOS                                         	--
26                              	Twinaxial                                     	--
27                              	EUI-64                                        	--
28                              	HIPARP                                        	RFC 2834, RFC 2835
29                              	IP and ARP over ISO 7816-3                    	--
30                              	ARPSec                                        	--
31                              	IPSec Tunnel                                  	RFC 3456
32                              	Infiniband                                    	RFC 4391
33                              	CAI, TIA-102 (Project 25 Common Air Interface)	--
34                              	Wiegand Interface                             	--
35                              	Pure IP                                       	--
36                              	HW_EXP1                                       	RFC 5494
37 - 255                        	--                                            	--
256                             	HW_EXP2                                       	RFC 5494
257 - 65534                     	--                                            	--
65535                           	Reserved                                      	RFC 5494
:Broke the talk page too but I think I fixed it. What is the source for this information? What is the reason for including it? --Kvng (talk) 15:04, 24 August 2011 (UTC)
replies: text: The source appears to be https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml this was already referenced a couple of places. I have added a reference in the HTYPE definition. Including the whole table in the article does not appear to be necessary. ~Kvng (talk) 00:39, 6 April 2022 (UTC)
thread_title:  Wish to add following table 

message: Looking at the field description of ARP Packet, we have used Hardware [Type/address/etc] and Protocol [Type/address/etc]. Why not use OSI model to represent these fields, like Data Link Layer [Type/address/etc] & Network Layer [Type/address/etc]. Makes it lot easier to correlate with known representations, and I assume I am not mistaken by my understanding.  — Preceding unsigned comment added by Nikchal87 (talk • contribs) 03:38, 8 February 2016 (UTC)
replies: text: As pointed out in the article, ARP was developed before the development of the OSI model. ARP is not cleanly defined by the OSI layers, as it overlaps Layer 2 and Layer 3. It would not be useful to hold to a strict OSI model.  Redwolfe (talk) 21:30, 31 March 2017 (UTC)
thread_title:  Using OSI Terminology to define fields in ARP Packet 

message: The [Wikipedia:Requested Articles/Applied Arts and Sciences/Computer Science, computing, and Internet]
has a redlink for the term "ARPcache" that should be resolved by having that term point to this article.
I do not know how that aspect of the Wikimedia system works yet, or I would handle the request directly.
Would some more experienced Editor fix this and comment on how it is done?
Redwolfe (talk) 21:41, 31 March 2017 (UTC)
thread_title:  WP:RA - Computing - ARPcache. Should point to this page somehow. 

message: 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/20120316213518/http://manpages.ubuntu.com/manpages/lucid/man8/arp.8.html to http://manpages.ubuntu.com/manpages/lucid/man8/arp.8.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 17:28, 26 June 2017 (UTC)
thread_title:  External links modified