|This is the "talk page for discussing improvements to the "IPstack template.
|"Archives: "Index, "1|
|"WikiProject Computing / "Networking||(Rated Template-class)|
|""||This talk page is automatically "archived by "MiszaBot II. Any threads with no replies in 90 days may be automatically moved. Sections without timestamps are not archived.|
Referenced "RPC is a general method or class of protocols. It may not be appropriate to include a link to this article in the list of protocols in this template. --"Kvng ("talk) 14:13, 30 July 2010 (UTC)
Putting SSH and SSL/TLS in the same layer doesn't seem logical. As a means of securing an application, TLS was designed better than SSL, but SSH wasn't created to secure applications. SSH was created to secure connections.
RFC 4251 (which describes SSH) explains that SSH is comprised of 3 components, each of which is referred to in RFC 4251 as a "protocol". Setting up an SSH connection starts at the Transport Layer, with the "Transport Layer Protocol [SSH-TRANS]". (For reference, this is taken from the following URL: http://www.ietf.org/rfc/rfc4251.txt.)
RFC 2246 defines the TLS protocol (Ver 1). Like SSH, it is a mutli-layered protocol. However, its lowest-level protocol is above the transport layer, not in it. (Reference URL: http://www.ietf.org/rfc/rfc2246.txt). Ver 1.2 exists as a draft. (Reference URL: http://tools.ietf.org/html/draft-ietf-tls-rfc4346-bis-10). (Understanding it sufficiently to definitely determine that it does not exist as deeply (within a given architecture stack or a networking model stack) seems to require reading both RFCs.
Regardless of which RFCs one uses as reference(s), the fact that these protocols are at different networking layers seems clear once the definitions are understood. SSH can be run over TCP/IP as well as any other "reliable data stream". (See RFC 4251, Paragraph 1. "Introduction"). RFC 2246 seems to imply this is also true for TLS (see RFC 2246, Para 1. "Introduction"). Analysis of each reveals a difference in the number of sub-components between them. As a practical matter, tunneling a TLS/SSL connection over SSH seems conceivable (though unnecessary) whereas the reverse does not.
Differences may not seem especially important until there is discussion over which is "more" secure. At the most basic level, SSH seems to be because it is less demanding on resources and comprises a smaller code base. To consider another perspective, consider which protocols are implemented by most web browsers that are capable of "secure" connections.
Another aspect to consider when evaluating alternative methods of securing a connection is the ability to stack one protocol on another. Stacking has trade-offs too for the same reasons (resource requirements and the size of the code base), but may differ in familiarity to admins within a certain environment. Tunneling FTP over SSH isn't possible as a result of FTP's complexities but the openssh project provide s secure file transfer protocol: sftp.
TLS differs from SSH in that TLS is designed to allow cryptographic security while separating security requirements from the application. Quoting from RFC 2246,
"The TLS Record Protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. ..."
Designers wishing to secure an application may wish to consider one other aspect of TLS, which is the fact that, "The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication."
Two additional RFCs that cast light on differences between networking layers are RFC 1122 (http://tools.ietf.org/html/rfc1122) and RFC 1123 (http://tools.ietf.org/html/rfc1123). (They each also have related updates). They group communication layers (RFC 1122) with each other and group Application and Support layers together (RFC 1123).
Networking models enable discussion of theoretical concepts pertaining to networking. When an implementation resembles one of them, the reasons are best explained by that vendor. When networked systems were first developed, separating function was a reasonable design choice dictated by cost. As costs got lower integrating them was a choice, but it became a choice that was curtailed in favor of privilege separation. (Today it is difficult to justify maintaining privilege separation because computing power and memory are inexpensive. Nevertheless, the value of privilege separation is not limited to theory.)
These protocols seem to highlight the difference between theory and implementation.
The Wikipedia entry for "Neighbor Discovery Protocol shows NDP to be an Internet layer protocol. This would seem to be correct since it is based on ICMPv6. However, this template shows NDP at the Link layer. NDP should be moved to the Internet layer. "Dave Braunschweig ("talk) 23:51, 6 November 2012 (UTC)
Agreed, NDP uses a special set ICMPv6 messages and is carried over IPv6, unlike ARP which is a separate layer two protocol from IP. I suspect may users are confused since these two protocols fulfill the same function (provide L3 to L2 address mappings), but are implemented vary differently. NDP should be moved into the Internet layer. DustinLundquist (talk) 22:20, 8 August 2016 (UTC)
 Yes, the Internet Protocol Suite does not distinguish routing protocols. But Wikipedia is not obliged to follow strictly classifications of the IP Suite or any other authority. Lack of "routing protocols" was the cause of a prolonged edit war, when the arrangement in the template was unstable and moving items back and forth flooded the history list. After my introduction of "routing protocols" a silence came. Why not to have the "routing protocols" group? It is convenient for Wikipedia and numerous reliable sources distinguish such class of protocols. "Incnis Mrsi ("talk) 19:18, 7 January 2013 (UTC)
I am puzzled by the way the various protocols have been classified in these pages. My understanding is as follows.
The OSI Physical Layer = the definition of the physical infrastructure capable of providing an (unreliable) symbol stream between two directly connected endpoints. The symbols are often bits, but can be from any finite alphabet. The key characteristics of the physical layer are (a) that it is between two directly connected endpoints (there is no concept of network address), and it is unreliable. Examples: RS-232, RS-422, 10Base5, 10BaseT, 100BaseTX, V.22, etc. Copper cable, optical cable, wireless carrier signal, smoke signals, etc.
The OSI Link Layer = the layer which turns an unreliable symbol stream connection between two directly connected endpoints into a reliable symbol stream connection between two directly connected endpoints. The key characteristics of the link layer are (a) that it is between two directly connected endpoints (there is no concept of a network address), and it is reliable. Examples: v.41, v.42, v.42bis. PPP, Zmodem, Kermit. Error-correcting code / error-detecting code with retransmission protocol, superimposed on a raw binary channel.
The OSI Network Layer = the layer which turns reliable direct connections between pairs of directly connected endpoints into a network, i.e. a communications medium in which each endpoint can send a packet to another endpoint by relaying its packet to its (directly connected) gateway and providing to the gateway a delivery address on the network. The sender does not have to worry further about the message getting delivered — the network layer provides the necessary routing to deliver the message. Message delivery is not necessarily reliable (delivery is not guaranteed and the sender does not know if it has been delivered). The key characteristics of the network layer are (a) that it is between a sender and an addressee (there is a concept of a network address), and that it is unreliable.
The OSI Transport Layer = the layer which turns an unreliable channel for sending addressed packets into a reliable channel for sending addressed packets. The key characteristics of the transport layer are (a) that it is between a sender and an addressee (there is a concept of a network address), and that it is reliable.
The Internet (IP) and the Ethernet layer are both OSI Network layer protocols, where the IP network layer is layered on top of the Ethernet network layer. The Ethernet layer is not a data link layer.
There is nothing unusual about stacking OSI Layers in a way which doesn't build OSI Layer (n+1) on top of OSI Layer n. PPPoE is an OSI Link Layer (PPP) stacked on top of an OSI Network Layer (Ethernet). ZModem run on a serial line provided by a modem which already provides v.42bis error correction is an OSI Link Layer stacked on top of another OSI Link Layer. ZModem run over ssh is OSI Link Layer run on top of an OSI Application Layer.
To distinguish between the two network layers, the early pioneers of the Internet (who were familiar with the OSI Model) referred to the network layer(s) on top of which the IP protocol operated the network layer, or the network connection layer, and to the new network layer which they were creating, which was connecting existing networks (and network layer protocols) into a bigger network (and more universal network protocol) the inter-network layer.
It is also not the case, as is claimed on many pages in this series that there is no correspondence between the OSI layers and the TCP/IP layers. The layers are clearly defined, and the correspondence is there and it is very clear.
E.g. IP is an OSI Network Layer protocol implemented on top of other OSI Network Layer protocols, such as, e.g. the MAC/Ethernet layer.
I have re-arranged some of the protocols in line with the above definitions, though I think several of them are still in the wrong place.
I find it wrong that Wikipedia lists ARP (and NDP) as a Layer 2 protocol. First of all, protocols like ARP and ICMP are considered 'helper protocols', so it's hard to actually say that they belong to layer. True layer protocols fulfil the purpose of that layer. And ARP does not fulfil the purpose of the Data Link layer. But if we should put it at a layer, it should be Layer 3. First of all because IP uses it as a helper protocol (IP needs ARP, Ethernet does not - so layer 2 can function without it, but layer 3 cannot). Second, ARP is encapsulated inside an Ethernet (for example) header/trailer. It has its own Ethertype (0x0806).
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)
May I have a clarification please?
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)
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)