This is the
talk page for discussing improvements to the
Internet protocol suite template. |
|
Archives: Index, 1Auto-archiving period: 90 days |
Computing: Networking Template‑class | ||||||||||
|
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)
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....
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)
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)
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)
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)
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)
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)
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)
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)
@ 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)
@ 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)
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:
Link Layer
To communicate on its directly-connected network, a host
must implement the communication protocol used to
interface to that network. We call this a link layer or
media-access layer protocol.
There is a wide variety of link layer protocols,
corresponding to the many different types of networks.
See Chapter 2.
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)
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)
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)
Shall I quote RFC 1970 which defines NDP?
kbrose ( talk) 20:14, 23 December 2021 (UTC)
@ 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.
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)
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)
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:
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)
The result of the move request was: page moved. ( non-admin closure) Steel1943 ( talk) 20:19, 29 January 2022 (UTC)
Template:IPstack → Template:Internet protocol suite – Templates should (and generally are) named by what they are (i.e. a meaningful title in clear, non-obfuscated English). Redirects allow the use of shortcuts for editors who cannot remember (or don't want to type) the full name of the template—like {{ Cn}} redirects to {{ Citation needed}}, for instance. I tried fixing this but was reverted. Additionally, Rich Farmbrough attempted to at least add a space between the words "IP" and "stack" twice, back in 2010 and 2011. All three attempts to improve the clarity of the title were promptly reverted by an apparent owner (just look at the history) with the reasons all being similar to "not necessary". This is classic owner behavior #3, and I find that kind of thing to be extremely detrimental to the forward progress of this collaborative project. Again, a redirect results from the move, so the whole "name...is short and easy to use" argument is moot. "Name has been stable for a long time" is owner behavior #2.
I propose that we move this to {{ Internet protocol suite}} because that is the title heading given at the top of the template itself as well as the common name used by the main article on this subject. Furthermore, most of the TCP/IP stack (as it is more commonly called than "IPstack") is built on top of IP and not part of that protocol itself. — void xor 20:29, 20 January 2022 (UTC)
This is the
talk page for discussing improvements to the
Internet protocol suite template. |
|
Archives: Index, 1Auto-archiving period: 90 days |
Computing: Networking Template‑class | ||||||||||
|
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)
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....
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)
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)
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)
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)
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)
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)
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)
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)
@ 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)
@ 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)
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:
Link Layer
To communicate on its directly-connected network, a host
must implement the communication protocol used to
interface to that network. We call this a link layer or
media-access layer protocol.
There is a wide variety of link layer protocols,
corresponding to the many different types of networks.
See Chapter 2.
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)
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)
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)
Shall I quote RFC 1970 which defines NDP?
kbrose ( talk) 20:14, 23 December 2021 (UTC)
@ 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.
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)
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)
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:
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)
The result of the move request was: page moved. ( non-admin closure) Steel1943 ( talk) 20:19, 29 January 2022 (UTC)
Template:IPstack → Template:Internet protocol suite – Templates should (and generally are) named by what they are (i.e. a meaningful title in clear, non-obfuscated English). Redirects allow the use of shortcuts for editors who cannot remember (or don't want to type) the full name of the template—like {{ Cn}} redirects to {{ Citation needed}}, for instance. I tried fixing this but was reverted. Additionally, Rich Farmbrough attempted to at least add a space between the words "IP" and "stack" twice, back in 2010 and 2011. All three attempts to improve the clarity of the title were promptly reverted by an apparent owner (just look at the history) with the reasons all being similar to "not necessary". This is classic owner behavior #3, and I find that kind of thing to be extremely detrimental to the forward progress of this collaborative project. Again, a redirect results from the move, so the whole "name...is short and easy to use" argument is moot. "Name has been stable for a long time" is owner behavior #2.
I propose that we move this to {{ Internet protocol suite}} because that is the title heading given at the top of the template itself as well as the common name used by the main article on this subject. Furthermore, most of the TCP/IP stack (as it is more commonly called than "IPstack") is built on top of IP and not part of that protocol itself. — void xor 20:29, 20 January 2022 (UTC)