Talk:Address Resolution Protocol
 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
 | This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
|
|
|
This page has archives. Sections older than 365 days may be automatically archived by Lowercase sigmabot III. |
Layer of ARP
editSince 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)
- 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)
- 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)
- @Kbrose: can you be more specific about what we should be looking at in RFC 1122? Zac67 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)
- 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)
- 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)
- 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)
Wish to add following table
editI 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) | ||
|---|---|---|
| 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)
- 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)
Using OSI Terminology to define fields in ARP Packet
editLooking 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)
- 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)
WP:RA - Computing - ARPcache. Should point to this page somehow.
editThe [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?
External links modified
editHello 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.
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) 17:28, 26 June 2017 (UTC)
Wikipedia Ambassador Program course assignment
edit
This article is the subject of an educational assignment at Louisiana State University supported by WikiProject United States Public Policy and the Wikipedia Ambassador Program during the 2011 Spring term. Further details are available on the course page.
The above message was substituted from {{WAP assignment}} by PrimeBOT (talk) on 15:55, 2 January 2023 (UTC)