This is the talk page for discussing improvements to the Internet protocol suite template.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1Auto-archiving period: 90 days

Computing: Networking Template‑class

This template is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Template This template does not require a rating on Wikipedia's content assessment scale. This template is supported by Networking task force.

There is no reason why OSPF is listed as a Layer 2 protocol. It does not accomplish any of the functions of a Data Link protocol and isn't even a helper protocol for L2. It could be considered a helper protocol for IP (layer3). But if RIP and BGP are considered Application layer protocols because they run on top of TCP/UDP so are not considered helper protocols for IP (so layer3), OSPF shouldn't be either. But even layer 3 is debatable. First of all, because it relies on IP to function. OSPF is encapsulated in IP (it has IP Protocol number 0x59). It would rather go into layer 4 protocol, since it has reliability mechanisms built in. Just as with the discussion on ARP and ICMP, these types of protocols are hard to fit into a layer. But OSPF without a doubt is not layer 2. — Preceding unsigned comment added by Alexandrujuncu (talk • contribs) 20:39, 25 March 2014 (UTC)Reply[reply]

Well, thank you, but the diagram is quite correct. You are confusing OSI layering with TCP/IP. The diagram puts it into the Link Layer, which is the realm of the local link a host is connected to. Please read the history of the Internet protocols. RFC 1122 defines the model. Granted there are some arguments to place it elsewhere, as we have at least two versions of OSPF, but the latest IPv6 specs clearly place it into the Link Layer, as that version only uses link layer addresses in its communications, among other explanations. You may also want to read past postings in this talk page. Kbrose (talk) 22:23, 25 March 2014 (UTC)Reply[reply]

I am very well aware of both the TCP/IP and the OSI model. OSPF is neither a layer 1 protocol in TCP/IP or a layer 2 protocol in OSI. Since you mentioned OSPFv3, I will quote from RFC 5340 - OSPF for IPv6: "The system requirements for an OSPF implementation remain unchanged, although OSPF for IPv6 requires an IPv6 protocol stack(from the network layer on down) since it runs directly over the IPv6 network layer.". It is a bullet of the things that remained unchanged from OSPFv2 (meaning that it also needs to run on top of a layer 3 protocol, but in that case, IPv4). Alexandrujuncu (talk) 19:05, 26 March 2014 (UTC)Reply[reply]

TCP/IP doesn't care whether something runs on IP or below for layers arrangement. It doesn't work that way, it only cares about scope. There is discussions about on the OSPF talk pages as well. Alone your nomenclature indicates you are confusing the models. TCP/IP doesn't have numbered layers. The OSPFv3 spec clearly states that the protocol runs on the link, not a subnet, whether or not it uses IP addresses is actually irrelevant, the addresses it does use are link local addresses. Kbrose (talk) 19:42, 26 March 2014 (UTC)Reply[reply]

Unlike EIGRP, for example, OSPF is made specificity for IP (OSPFv2 for IPv4 and OSPFv3 for IPv6, to be exact). So yes, it matters. Also, the comment "TCP/IP doesn't have numbered layers" is a misunderstanding, I think. You can refer to the second, third or any layer of a stack just like you can refer to 'c' as the 3rd letter of the alphabet. I think we can all agree that the two models have a fixed and finite number of layers that we can refer to. Alexandrujuncu (talk) 21:02, 26 March 2014 (UTC)Reply[reply]

No body in the IETF has *ever* referred to the Link Layer as Layer 1, or the Internet Layer as Layer 2, etc, or any layer number. Layer numbers are OSI language. And since you clearly associated Layer 3 with the layer that contains IP, you didn't use it in that general meaning, it would be wrong in TCP/IP. Kbrose (talk) 01:41, 27 March 2014 (UTC)Reply[reply]

Both OSPF and EIGRP use multicast packets encapsulated inside multicast layer 2 frames (let it be ethernet, frame-relay, ppp, hdlc). scope of these packets is just link local, this does not mean that ospf works at link layer or eigrp works at link layer. It just means the ttl is 1. the nature of ospf is link-state routing protocol should not mean its only operates at link layer. the highest layer used by ospf for control/management/data plane is internet layer, and not link layer. BGP uses path vector logic, that doesnt mean bgp doesnt fit in the application layer because its scope is between autonomous systems. however ISIS is link layer as clearly frames are involved in transporting in ISIS PDUs. A discussion on this can be found here...https://learningnetwork.cisco.com/thread/82389?tstart=0on Cisco learning network, specifically addressing the wikipedia mentioning ospf under link layer...Read here what the Industry Experts (Specifically Cisco VIP Scott Morris-CCDE/4xCCIE/2xJNCIE) have to say on this: https://learningnetwork.cisco.com/thread/82389?start=30&tstart=0 Pritishp333 (talk) 16:31, 11 March 2015 (UTC)Reply[reply]

I disagree with this interpretation and could give many strongly-supported opinions as to why; however, debating opinions is not necessary to see that OSPF does not belong in the link layer. This is objectively wrong within the TCP/IP model. The "latest IPv6 specs", including both RFC 2460 (1998) and the updated RFC 8200 (2017) make this clear when defining terminology:

upper layer  a protocol layer immediately above IPv6.  Examples are...routing protocols such as OSPF....
link         a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6....

So the spec defines OSPF in particular and routing protocols in general among the "upper layer" protocols "above IPv6", whereas the link layer is "below IPv6". I agree that encapsulation is not the only consideration when deciding what layer a protocol operates in, but here OSPF is not a lower layer protocol being tunneled over IP. It is legitimately an upper layer protocol in the stack under normal operations. CheerfulPaul (talk) 15:35, 14 October 2019 (UTC)Reply[reply]

In addition to the arguments made above as to why OSPF does not belong to the link layer, I'd like to point out to RFC1812 section 7 which very explicitly states that routing protocols (including OSPF, IS-IS, BGP, and RIP) belong to the application layer in the TCP/IP model. I'm going to edit the template to that effect in a few days, and fix the paragraph in the Link_layer#Link_layer_protocols article. Tavositar (talk) 22:38, 2 November 2021 (UTC)Reply[reply]

Pigeonholes are not always easily defined. For example, from the point of view of what would be seen on an Ethernet cable, a packet carrying SMTP data consists of Ethernet : IP : TCP : SMTP, whereas OSPF looks like Ethernet : IP : OSPF. Given that, it's easy to place SMTP in the application layer because it uses the underlying TCP transport layer which uses the underlying IP layer, etc. Considering the SMTP and OSPF packets, by analogy, OSPF might operate at the transport layer but that doesn't make sense because it is not used by higher layers to transport anything. Layering in TCP/IP actually operates as shown in the diagram. I've forgotten quite a lot about OSPF but I believe one OSPF router talks only to an OSPF router at the bottom layer of that diagram. Johnuniq (talk) 06:24, 3 November 2021 (UTC)Reply[reply]

Sometimes there are several holes that can reasonably house the pigeon, but sometimes the hole really is not fit for the pigeon :) . "OSPF might operate at the transport layer but that doesn't make sense because it is not used by higher layers to transport anything" I absolutely agree, and I was not suggesting to put OSPF at the transport layer. In fact, a similar reasoning will show that putting OSPF in the link layer doesn't make sense either! For the purpose of running routing protocols, IP routers function as hosts, and routing protocol involve exchanges between processes running in the routers (running in what would be control plane in modern routers; or a user-space process if you're running 4.2BSD). Tavositar (talk) 23:29, 3 November 2021 (UTC)Reply[reply]

I made the the change I mentioned, and also added some words to Internet_protocol_suite#Comparison_of_TCP/IP_and_OSI_layering about how one RFC put routing protocols in the application layer, but OSI put ISIS in the network layer and Tanenbaum in the network layer of his 5-layer model. Tavositar (talk) 21:30, 7 November 2021 (UTC)Reply[reply]

The OSPF protocol should be in layer 3 (up one layer)! — Preceding unsigned comment added by 217.91.45.166 (talk) 14:56, 19 February 2015 (UTC)Reply[reply]

TCP/IP does not have a layer 3, as is clearly seen from the stack. Please don't conflate OSI jargon with TCP/IP. Kbrose (talk) 01:52, 20 May 2015 (UTC)Reply[reply]

Hi.

Kbrose, I hope you are seeing this; it concerns you to a great deal. Revert #675955893 by Kbrose removes EAS and says "this is not the purpose of this template".

May I have a clarification please?

Best regards,
Codename Lisa (talk) 19:51, 13 August 2015 (UTC)Reply[reply]

There are a lot of important network protocols and this template is not an attempt to list them. Traditionally, the Internet protocol suite consists of the core protocols that allow a large internetwork to function, with the core user-facing protocols such as HTTP. Johnuniq (talk) 23:08, 13 August 2015 (UTC)Reply[reply]

@Johnuniq: I am afraid that is still not a clarification. Please give me a sold inclusion criterion.

Best regards,

Codename Lisa (talk) 10:11, 16 August 2015 (UTC)Reply[reply]

There are many templates like this as well as list articles where the criteria for adding items is vague. What about my above comment? Would you agree there are at least 100 protocols that use IP and which could be added here? Why EAS? Any traditional textbook on the topic would have a list very similar to that currently shown in the template, namely just the basics. Johnuniq (talk) 10:21, 16 August 2015 (UTC)Reply[reply]

@Johnuniq and Kbrose: I do not understand this reticence to answer the topic question: What is the purpose of this template and what is its inclusion criteria? (Well, Kbrose is not even participating.)

And Johnuniq, in response to "What about my above comment?", I don't understand either of your comments. My best guest is that you are implying that this template is imitating an official list of some sort. In that case, I'm eager to look at the said list. But if this is an "others haven't done it, so we shouldn't" argument, I am afraid I rather think others have made a terrible mistake not to have done it.

By the way, this template is a mess! What's RIP, DHCP and BGP doing in application layer?

Best regards,

Codename Lisa (talk) 20:14, 18 August 2015 (UTC)Reply[reply]

Please read the template documentation first before asking what is documented, and shouting out, especially after someone had already spent time explaining it; and if you haven't understood the TCP/IP model you shouldn't add or change anything. Most routing protocols are no different than any other application, a router uses them to obtain information. This process has nothing much to do with the function of routing and it is one of the few reason why a router even needs a transport and application layer. Kbrose (talk) 12:25, 19 August 2015 (UTC)Reply[reply]

@Kbrose: Wow! Assuming bad faith and assuming ownership so explicitly, aren't we? Your second revert was categorically hostile. I do not know what I did to deserve such a hostile response. FYI, I know what is TCP/IP, I know what is Internet protocol suite and you are mistaking these two. Furthermore, I know that templates like this must summarize the articles in which they are placed. i.e., if the Routing Information Protocol says RIP is a transport layer protocol, this template must list it in transport later.

Now, back to our discussion. It seems I must invoke a third opinion. Jeh and FleetCommand, can I most humbly invite you to weight in? The questions is: Does Exchange ActiveSync belong to the application layer of this template?

Best regards,

Codename Lisa (talk) 21:07, 19 August 2015 (UTC)Reply[reply]

The article nowhere makes this statement. The article states that RIP used UDP as its transport, if that is what you are misunderstanding. So, if that is your position, then why did you move it to the Internet Layer, rather than the Transport Layer? If you have such misunderstandings of subject matter, why are you editing them into WP and automatically accuse corrections to be hostile? The only hostility I sense came from you when you would not accept the given explanations. Kbrose (talk) 00:42, 20 August 2015 (UTC)Reply[reply]

"The article nowhere makes this statement." It does. I can see it.

"If you have such misunderstandings of subject matter [~snip~]". Please put this "I know better than you" argument aside; it only makes you look like douchebag. Try citing a source instead. Fleet Command (talk) 07:44, 20 August 2015 (UTC)Reply[reply]

Hey there, CL. Since I am here by your invitation, I think I must start with your mistakes. Then, other points:

1. Actually, what they say is pretty clear to me. Kbrose and Johnuniq say this template is not meant to have every protocol and that it already has enough. So, no EAS, even if it is truly an application layer protocol.
2. They don't seem vague to me at all, but again, if you had asked me "What is the purpose of this template and what is its inclusion criteria?" I'd have spelled it out for you. "To show examples of Internet Protocol Suite" and "we feel there are enough examples in it already".
   • Update: I looked back a bit and I see Kbrose's first edit summary: "this is not the purpose of this template". I can see the problem now: It wasn't the first thing that I saw but it was the first thing that you saw. You might have all along been attempting to reconcile the discussion with it. So, okay, you were mislead.
3. Your subsequent edits following your reply here seem tense at best. Take it easy, man! Be the charming Codename Lisa that you always were.
4. This entry is not a criticism of you, but a suggestion: You can create a navbox containing all protocols if you want.

Your turn, Kbrose:

1. If I wanted to be both polite and summarize this edit in one word, I'd say: Condescending. CL says her change was "accordance to their articles". If you wish to contradict it, the burden of proof is on you. But the articles and the template must still be in sync. You contrib log does not show you doing that either.
2. I don't see any evidence that characterizes CL's question as shouting; NOT BEFORE your post, at least. CL has already amassed a reputation in being calm and loving. (Even if she did make it clear that she was indeed shouting, coming to a discussion after six days and accusing someone of shouting is an act of picking a fight.) When you revert someone, that someone is entitled to ask you "why?" and get your personal answer.
   • Update: As I said in the update above, your first edit summary was misleading. When you mislead someone, you really cannot complain about their confusion.

Fleet Command (talk) 22:24, 19 August 2015 (UTC)Reply[reply]

Hello, FleetCommand. Thanks for the clarification. That is all the answers I needed. Best regards, Codename Lisa (talk) 20:16, 20 August 2015 (UTC)Reply[reply]

BGP and RIP are clearly Application Layer protocols in the Internet Protocol Suite, they don't belong into the Internet Layer. Period. Furthermore, those article don't state that either. TCP/IP does not place routing protocol into the Internet Layer. There are versions of the OSI model that created a sublayer in the Network Layer, but this is not OSI, nor were RIP or BGP developed under OSI guidance. They are IETF protocols. I don't see where any edit comment was misleading. If the editor doesn't take time to read what is already stated in the template documentation, then don't expect spending more time for lengthy explanations. Apparently the editor also didn't read those articles. There was nothing more intended to simply revert a wrong edit. I don't have time nor patience for retaliation nonsense. Kbrose (talk) 00:08, 20 August 2015 (UTC)Reply[reply]

Also, the template has a very visible link to the comprehensive category page for all Application Layer protocols covered on WP, and EAS is listed there as expected. And looking at that list it should again be obvious why not all protocols are listed in the template, and why they not possibly all can be listed there. Kbrose (talk) 00:20, 20 August 2015 (UTC)Reply[reply]

"BGP and RIP are clearly Application Layer protocols in the Internet Protocol Suite". Prove it. Else, disputed content without a proof are deleted. The rest of your message is hostile confrontation and not worth contemplating. Fleet Command (talk) 07:57, 20 August 2015 (UTC)Reply[reply]

@Codename Lisa:: Because I have written twice the number of bullet points for you, I presume you are going to be twice explosive and abusive than Kbrose. (Yes, sarcasm.) Please spare. I gave my opinion. I am out of here. You're on you own. Fleet Command (talk) 08:22, 20 August 2015 (UTC)Reply[reply]

One issue is that there is no clear and authoritative source with a precise definition of what "belongs" to what TCP/IP layer. RFC 1122 and friends provide the definitions, but someone with no other background might have trouble using that to pigeonhole a protocol in a particular layer. Part of the ambiguity is that IP suite development was done by a bunch of pragmatists who knew that layering is good but is not the ultimate objective. Tradition comes from the RFCs and The Book by Richard Stevens, and others by people like Craig Hunt. Stevens obviously follows the RFCs: the link layer is concerned with getting a packet from one host to the next over the cable or other media; the network layer (IP) extends that to connect hosts via routers; the transport layer (principally TCP or UDP) provides a communications service for applications (with port numbers to identify processes); the application layer consists of processes which communicate with other processes via the transport layer. This is all spelled out in the RFCs and standard textbooks. From that, it naturally follows that things like BGP and RIP are in the application layer because they are implemented by processes running in different computers which communicate via the transport layer. Neither BGP or RIP provide the link, internet, or transport layers—they are just applications which communicate over those layers, and which happen to feed information into the routing table, which in turn is used by IP. An internetwork does not require BGP or RIP—the transport, internet, and link layers can function happily without them. Battles over what-protocol-belongs-to-what-layer are part of the OSI world with debate confined mainly to those who have seen training guides for Cisco or other certification. Johnuniq (talk) 10:23, 20 August 2015 (UTC)Reply[reply]

Hello again, Johnuniq. Thanks for the comment, even though it is not relevant to the topic of the discussion at hand. Perhaps I will pursue it later. Best regards, Codename Lisa (talk) 20:16, 20 August 2015 (UTC)Reply[reply]

My comment was for anyone looking at this later who may want an understanding of the issues without wading through previous discussions. I mentioned BGP and RIP because you mentioned them above, as well as in edit summaries to the template. The topic in the section header was covered in my first comment, and nothing more on that need have been said. Johnuniq (talk) 02:32, 21 August 2015 (UTC)Reply[reply]

@Kbrose: Why shouldn't DHCPv6 be listed, while NDP and even ICMPv6 are. Also, there would be just 4 additional characters: (v6) - Piulin (talk) 12:41, 6 May 2021 (UTC)Reply[reply]

@Kbrose: You reverted my edit that moved ARP from the link layer to the internet layer. How is ARP supposed to belong to the link layer? Of course, it uses the link layer but it isn't part of it (in doubt, please refer to RFC 1122 for the definition of the link layer). ARP provides the glue for the IPv4 network layer to use a MAC-based link layer. As such, it is part of the interface to the link layer and an integral part of the network layer. --Zac67 (talk) 08:08, 21 December 2021 (UTC)Reply[reply]

1122 is pretty clear about that, and ARP never traverses routers, which really is the defining criterion. ARP stays on the LINK. TCP/IP layers don't have "interfaces" and they are not "used". they are just realms or scopes. "Network layer" is not a term of TCP/IP, it is the Internet Layer, for "internetworking", because this is where networks are interconnected, and routers are traversed. This is also why OSPF belong to the link, despite the many wrong ideas that think otherwise. kbrose (talk) 14:16, 21 December 2021 (UTC)Reply[reply]

The Link Layer presentation in this template has always been problematic, because it lumps things in there, that strictly are not part of TCP/IP, e.g. Ethernet, WiFi, etc. kbrose (talk) 14:20, 21 December 2021 (UTC)Reply[reply]

RFC 1122 does not put ARP in any layer. It's listed under LL since it's a mechanism required to handle MAC-based LL variants. Not being routed isn't a criterion for belonging to the LL. The criterion is what kind of service a protocol provides. ARP is integral to IPv4, so it belongs to the internet layer, just like ICMP.

And of course layers have interfaces to the upper and lower layers (where applicable) and higher layers utilize or use lower layers for transport (e.g. HTTP uses TCP which uses IP which uses Ethernet) – incidentally, this is in RFC 1122 as well, literally. And btw, OSPF is an application-layer protocol. --Zac67 (talk) 21:03, 21 December 2021 (UTC)Reply[reply]

Not true, these are ideas of the OSI model, not TCP/IP. The IETF community did not put much value in these structured ideas. kbrose (talk) 01:59, 22 December 2021 (UTC)Reply[reply]

The TCP/IP model does use distinctive layering, the IETF just don't define the layer for every single protocol. If we can't put ARP (and NDP) into the internet layer (the way you put it we're lacking WP:RS), then we should at least remove them from the link layer, where they are definitely wrong. --Zac67 (talk) 08:30, 22 December 2021 (UTC)Reply[reply]

Search for "Pigeonholes are not always easily defined" above to see how it is reasonable to think otherwise. Johnuniq (talk) 22:22, 21 December 2021 (UTC)Reply[reply]

Thanks, that confirms my point. But I wasn't going by encapsulation, I'm going by functionality. Not even ARP's encapsulation by the link layer puts it within the same but above. --Zac67 (talk) 08:30, 22 December 2021 (UTC)Reply[reply]

If you remove ARP from the Link Layer, the layer is essentially empty. In TCP/IP it just provides the link to the hardware, which is not a concern of TCP/IP. Ethernet aspects are covered in 1122, due to the nature of ARP, but TCP/IP really just assumes some functioning wire. The whole of layering is pretty loose, and this was always the case in TCP/IP. It was not a design guide, or goal for teaching. It was recognized that modularity and some structural design were useful, but rigid specifications were an obstacle to success. OSI proved that to a tee, when most (all?) initial implementations failed in interoperability, and it prevented OSI from becoming the standard of the Internet in the early 90s because the market place could not wait, despite almost everyone's expectations. To pick it apart three, four decades later is mood, and the IETF has never done so. You can use the OSI model if you want to argue about those details. 1122 is one of the few primary guides for layering in TCP/IP and it lists ARP in the Link Layer. There was a layering RFC later, but it was not a specification. It is not about functionality, interfaces, encapsulation, or what, but about networking scope. The layer names tell us that too, because the second layer is called "Internet", meaning more than one network, interconnected, larger than one link. Transport is the scope between hosts, anywhere, just hosts. ARP stays on the link. NDP has some mixed functionality too, yet the RFCs have Link Layer all over them. OSPF is truly a tricky one, v4 talks about subnets, but v6 does not, and in the end they both stays on the link too, informing the routers. Putting them into the application layer is a cop-out, perhaps not all bad, but not on the basis that all routing protocols belong there (ask OSI what they think!). It comprises almost anything without clear scope, but the common abstraction seems to be the process. kbrose (talk) 16:27, 22 December 2021 (UTC)Reply[reply]

We don't need any other reference than RFC 1122 to place ARP into the Link Layer. This does not need reinterpretation. This is the way the designers wanted it:

Chapter 2 provides a "walk-through" (their term!) of the protocols of the Link Layer. By this, we can argue that parts of Ethernet, ISDN, etc should get listed, or just the concepts. I think this was the original idea of listing those there, to provide the context to hardware.

My reason for me not moving OSPF back to the Link Layer, despite its limited scope as a network protocol, was that it is not directly a hardware-oriented protocol, but runs as a process on a host, just not using a transport protocol, but simply informing the IP layer of available links for routing and their metrics. This perhaps helps accommodating readers who object of a link layer protocol knowing about IP addresses. kbrose (talk) 16:51, 22 December 2021 (UTC)Reply[reply]

With all respect, If you remove ARP from the Link Layer, the layer is essentially empty. shows a serious misunderstanding of layering. All of IEEE 802 is about the link layer (or in OSI terms, the physical and the data link layers). In TCP/IP it just provides the link to the hardware, which is not a concern of TCP/IP. pretty much so - but ARP is a part of TCP/IP, isn't it? TCP/IP really just assumes some functioning wire – there's more to it than a wire and that's even detailed in RFC 1122. I fail to get your reference to OSI as I wasn't talking about that (although OSI's layer 1+2 are pretty much the same as TCP/IP's link layer). RFC 1122 [...] lists ARP in the Link Layer – no, it does not. That RFC explains ARP within the link layer chapter as it's vital to working with it. The RFC says nowhere that ARP is part of the link layer. Check out the description of the link layer's functionality and you see that ARP doesn't fit anywhere. Link layer networks are Ethernet, IEEE 802.11, ARCNET, Token Ring, ISDN, ATM, PPP, ... Where is ARP's place in that? the second layer is called "Internet", meaning more than one network, interconnected, larger than one link is your interpretation, no quote. Regarding NDP, would you be so kind and point me to an RFC that says it's part of the link layer? Once again, if there's no consense for ARP belonging to any specific layer, we should remove at least it from the template (same with NDP unless that promised RFC shows up). --Zac67 (talk) 19:49, 22 December 2021 (UTC)Reply[reply]

RFC 1122 by its own statements provides a walk through the protocols of the time for each layer. ARP is discussed in the Link Layer. That's where they wanted it. It fits perfectly because it operates only on the Link and it provides a tool for access the MAC system of Ethernet. What other interpretations are needed? kbrose (talk) 20:04, 22 December 2021 (UTC)Reply[reply]

Hello, in fact, there is no clear mention in RFC 1122 regarding where ARP resides in the protocol stack. In RFC 1180 (P.5), ARP is shown in-between IP and Ethernet, with the following statement on page 4: "If an Ethernet frame comes up into the Ethernet driver off the network, the packet can be passed upwards to either the ARP (Address Resolution Protocol) module or to the IP (Internet Protocol) module. The value of the Type field in the Ethernet frame determines whether the Ethernet frame is passed to the ARP or the IP module"

In addition, RFC 826 (ARP standard), mentions nothing related to protocol stack, which is normal to an RFC that old. In the RFC the word packet is used with protocol, which means in today's language L3 PDU (protocol data unit), this meaning was not used at that time, for example, what we called an IP packet today was simply called datagram (RFC 791: IPv4 standard).

If we look at the encapsulation of the headers, the ARP header comes after the L2 header, and there is no L3 header (no IPv4 header). From my point of view, if the protocol can access the IP header without passing through encapsulation, it, for sure, resides within the same layer.

NDP clearly resides at Layer 3, because it uses ICMPv6 messages, and "ICMPv6 is an integral part of IPv6" (RFC 4443, P. 3).

Please tag me to have a notification because I am not active in English Wikipedia.--Michel Bakni (talk) 22:57, 22 December 2021 (UTC)Reply[reply]

OSPF can not be moved to link-layer because it is, at least, above the IP which resides in the internet layer, the value 89 is reserved for OSPF in the Protocol field in the IPv4 header (Check IANA registry).--Michel Bakni (talk) 23:06, 22 December 2021 (UTC)Reply[reply]

Protocol encapsulation sequence is not a feature of TCP/IP. You are confused by OSI. Forget OSI if you want to be correct about TCP/IP. L2 and L3 are not TCP/IP terms either. Whether NDP is a part of the ICMP spec has no bearing on layering, similar with OSPF. The TCP/IP architects never intended such strict interface hierarchy. kbrose (talk) 23:12, 22 December 2021 (UTC)Reply[reply]

I think you are mistaken, please check the use of the word "encapsulation" in RFC 1122, the concept does exist and is widely adopted in TCO/IP protocols. I do not understand this sentences "NDP is a part of the ICMP spec has no bearing on layering". If NDP uses ICMPv6 messages structures, this means its messages will be treated as ICMPv6 messages, ICMPv6 is an integral part of IPv6, and thus, NDP is also.--Michel Bakni (talk) 08:15, 23 December 2021 (UTC)Reply[reply]

ICMPv6 is not an integral part of the Internet Protocol version 6, but is a part of the IPv6 suite of protocols. The IPv6 specifications are not a monolithic entity, but a group of protocols that expand or improve on the concepts of the TCP/IP protocol suite. Same applies to NDP, it is distinct protocol within the IPv6 group, this does in no way imply a certain layer level. kbrose (talk) 19:53, 23 December 2021 (UTC)Reply[reply]

Of course, TCP/IP uses encapsulation, and an Ethernet frame can only be encapsulate by IP, for example, not the other way around. But this does not impose direct limitation on layer association. A particular layer has no fixed encapsulation sequence. E.g., OSPF encapsulates on top of IP, yet no one (hopefully) places it into the Transport Layer. I say again, forget OSI when writing about TCP/IP. Why is this so hard? Why can't you discuss TCP/IP using only its own concepts and definitions? kbrose (talk) 19:23, 23 December 2021 (UTC)Reply[reply]

NDP

Shall I quote RFC 1970 which defines NDP?

• Abstract: IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.
• In section 2.2: (Link Types) Different link layers have different properties. The ones of concern to Neighbor Discovery are: and they are listed.
• Section 6.2.1: This rule simplifies the configuration of Neighbor Discovery over link types with widely differing performance characteristics.

kbrose (talk) 20:14, 23 December 2021 (UTC)Reply[reply]

@Kbrose: You entirely miss the point. Your quotes show that ARP runs on top of the link layer, not that it's part of the link layer, what this discussion is about.

• ARP is discussed in the Link Layer. — Yes, it is because it's IPv4's essential interface with the link layer. There's no word that it is part of the link layer.
• Protocol encapsulation sequence is not a feature of TCP/IP. — While I don't use encapsulation for arguing (I could but it is sometimes misleading, see PPPoE), you are clearly mistaken. IP encapsulates in link-layer frames. TCP encapsulates in IP. Also, check numerous RFCs about encapsulation; I don't think I need to provide a list.
• The TCP/IP architects never intended such strict interface hierarchy. — That is correct to some extent. I was agreeing to removing ARP (and NDP) from the link-layer section when layers are somewhat ill-defined. However, you can't lean your illogic argument on a source that doesn't define a strict hierarchy, your own words.
• ICMPv6 is not an integral part of the Internet Protocol version 6 shows you lack of understanding again. It is.
• Ethernet frame can only be encapsulate by IP, for example, not the other way around — not the point here, but with tunneling, any encapsulation is possible (not by OSI but in practice).
• Your quotes to NDP are irrelevant and NDP's place in the internet layer isn't even disputed properly.

Your arguments continue to prove that ARP runs on top of the link layer, so very obviously it can't be part of it. As a compromise (again), let's remove ARP from the link-layer section when there is no consent and sources are ambiguous (for me they're not). As it is, there are two editors for ARP in the network layer and only one for the link layer. And please don't WP:EDITWAR when sources are requested for dubious claims. --Zac67 (talk) 08:11, 24 December 2021 (UTC)Reply[reply]

I do agree with Zac67, if you can handle different link protocols, you are on the top of the layer and not a part of it, this is simply the layering concept.--Michel Bakni (talk) 11:35, 24 December 2021 (UTC)Reply[reply]

@Kbrose:, please be reasonable, you are denying a clear statement in the ICMPv6 RFC.

your words: ICMPv6 is not an integral part of the Internet Protocol version 6

ICMPv6 creator: "ICMPv6 is an integral part of IPv6, and the base protocol (all the messages and behavior required by this specification) MUST be fully implemented by every IPv6 node." (RFC 4443, p. 3)--Michel Bakni (talk) 11:42, 24 December 2021 (UTC)Reply[reply]

ICMPv6 is a part of the IPv6 specification, but not of the Internet Protocol (v6). It is not the same protocol. The IPv6 specification comprises a suite of protocols, only one of the is Internet Protocol Version 6. This is pure word splitting. What other word than run over would they use when stating multiple link types. Media access control runs on top of the hardware of the link, but TCP/IP does not concern itself with that. Therefore ARP runs in layer one of TCP/IP. It cannot be routed and therefore does not run in the Internet layer. kbrose (talk) 19:13, 24 December 2021 (UTC)Reply[reply]

Neither?

So because it's controversial and we can't decide where to put it, now it's not in this template at all? That seems like a classic worst-of-both-worlds compromise, for a protocol as important as ARP! —scs (talk) 22:12, 21 April 2023 (UTC)Reply[reply]

Re-added

I have re-added ARP, placing it at the Internet layer. I don't care so much where it goes, as long as it's listed. To my mind, it belongs wherever NDP is, since they're analogous. But:

I don't believe we have to get the placement exactly right. I believe this template's primary purpose is to list the primary Internet protocols, and ARP is certainly one of those. I don't believe this template has a mandate to definitively categorize protocols as to layer.

The impossibility of categorizing ARP perfectly is not, I believe, a reason to banish it from this template.

If it's unacceptable to list ARP here but to have it categorized imperfectly, I believe we have two options:

• put an asterisk next to it, with a footnote that it's not actually a part of whatever level we put it in, or
• create an actual "level 2.5" heading to put it and NDP in.

But, again, leaving it out entirely is not an option. ARP is undeniably a core Internet protocol, and it belongs in this template. —scs (talk) 21:50, 17 June 2023 (UTC)Reply[reply]