|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.|
OSPF is a layer 7 protocol
I think dynamic routing protocols have nothing to do in layers other than the application layer. These protocols are meant to manipulate routing tables (by sending and receiving routing updates). I do not even realize why this is a question:
Please read carefully: http://www.cisco.com/en/US/docs/internetworking/technology/handbook/OSPF.html
"Open Shortest Path First (OSPF) is a routing protocol developed for Internet Protocol (IP)" - which means it cannot be in layer 3. Think of it: can you use it for connectionless transport? no..
Layer 4 - TCP, UDP, RTP and so on.. the PDU (protocol date unit) of layer 4 protocols are segments. Which means that data from the application layer are segmented into smaller chunks and got encapsulated into layer 4 headers and trailers which guarantee (or not guarantee) connection-oriented service and distinguish multiple transport layer streams (applications /services) by assigning port numbers. You cannot use OSPF to do this (why would you want to?), because it is a routing protocol which exchanges data about link states (it's a link state routing protocol). Exchanging these kinds of information is handled by lower layers like IP(UDP), Ethernet and Physical:
Physical|Ethernet|IP|UDP|Data segments|UDP|IP|Ethernet|Physical(Encoding, low-level signalling, transmission).
The problem is, that in the IP template OSPF is in Layer 2(!) which is an epic fail! Layer 2 is Ethernet, Token Ring, STM and ATM (another pearl, because it contains layer 3 functionality as well, but totally different)! Frames and media access control!
Layer 5 and 6 are handled by the application.
This comes us to the conclusion, that OSPF is a layer 7 routing protocol, just like HTTP,FTP and others. "Link States" have nothing to do with data link layer and other stuff.
Link state: an interface with an IP address and subnet mask, and a medium type (shared, point-to-point) etc. This kind of information is what gets exchanged between routers, and by using which a shortest path tree gets built (oops, application layer functionality!) using Dijkstra's algorithm.
Other routing protocols (RIP, IS-IS) are thereby application layer protocols.
Unfortunately this is my second attempt to correct this severe problem. I hope the last one too.. If it won't get corrected soon I will change the IP stack template again to the correct one. If anyone reverts back to the wrong one I'll create my own and change the references in the corresponding articles. I won't let other people learn nonsense (again). Stmarci (talk) —Preceding undated comment added 21:20, 5 June 2010 (UTC).
- I do not have a firm view on this issue (it's the sort of thing that frequently crops up when people try to rigidly categorize items only to find problem items that are not so clear). However, anyone wanting to argue the case for a change should review the archive of this talk page (see link in the Archives box at the top), and should review this talk page. Search both pages for "OSPF" and review the arguments. If you think you have a reason to overrule the previous discussions, please briefly quote the point previously made and say why it is wrong. Johnuniq (talk) 02:06, 6 June 2010 (UTC)
This comes up again and again. Unfortunately most people that try to argue this, as this user, are confused by using the wrong model description and not knowing the difference between TCP/IP and OSI. We are not discussing OSI networking here, the models are different. TCP/IP classifies the layers as being realms or scopes of operation, link, network-to-network, host-to-host, application-to-application. Routing protocols fall into two categories, those that only operate on the link and those that are like any data processing application. OSI avoided this altogether by lumping them all into a sublayer of the Network Layer, as administrative protocols. But we are discussing TCP/IP here. Whether OSPF uses IP has no bearing on its placement, TCP/IP doesn't follow encapsulation hierarchies. Kbrose (talk) 16:49, 30 July 2010 (UTC)
Where do we put this?
Some articles have put it at the top of the page. Others put it after the lead. I assume consistency is good. The template documentation doesn't have anything to say about it. What's the best place? --Kvng (talk) 22:03, 26 July 2010 (UTC)
- The template really should go where it is most appropriate, rarely should it be the top, as most topics have more interesting features to prioritize. The template is large and draws attention away from the article. Always placing it in the same spot, it definitely wrong. It should augment an article if really needed, not dominate it. The template is used way too much actually. Kbrose (talk) 16:37, 30 July 2010 (UTC)
- Because it delivers data between two processes across any number of networks using a protocol defined by the application. It uses a transport protocol, UDP, TCP, SCTP, or DCCP (i.e. not just UDP) for the host-to-host connection. In this it is no different than, say HTTP. The protocol is clearly defined at a level above the Transport Layer. OSPF on the other hand is confined to operating on the local link, it never traverses routers, despite using IP as its 'transport'. In IPv4 there was some possibility to place it at the Internet Layer, because initially it was defined to operate on a subnet, but with the advent of IPv6 it is defined (by the RFCs) to operate on the link only. Kbrose (talk) 16:24, 30 July 2010 (UTC)
- I've just had a look at the RFC 3550 introduction. I was wrong. They don't put it the same way that you have but there is discussion of handling of RTP datagrams at the application layer and this reference is mentioned - Clark, D. and D. Tennenhouse (September 1990), "Architectural Considerations for a New Generation of Protocols", IEEE Computer Communications Review, 20(4): 200-208, retrieved 2010-07-30. --Kvng (talk) 19:22, 30 July 2010 (UTC)
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)
- Well, it is a major component in networking and is considered to have its origins with the Internet protocols. Being so important it its use, it does have a place here. Application protocols can vary greatly in design and function, most Internet protocols are at this level and the Internet Protocol Suite doesn't really concern itself with the structure of them. OSI tried to do that with just a little bit more success, but the landscape there is foggy too. Kbrose (talk) 16:31, 30 July 2010 (UTC)
- I've changed the link to point to the Sun/ONC RPC as that's the RPC defined in IETF documents. As far as I know the other ones (DCE/RPC etc.) were never IETF standards. Not sure if it's worth adding some new W3C stuff here like SOAP. (Probably not since there's a separate template for W3C protocols/standards.) Someone not using his real name (talk) 02:33, 14 December 2013 (UTC)
This protocol should be at the transport level, shouldn't it? Its (imho) also wrong in the main article. In the german wikipedia its rightly placed. Who did the error? post-sign: --184.108.40.206 (talk) 14:55, 8 December 2010 (UTC)
- No, it shouldn't. It's clearly an application protocol. TLS or SSL security is applied on a process-to-process basis within an application protocol, not as part of the host-to-host TCP connection. Kbrose (talk) 18:41, 8 December 2010 (UTC)
SSH and TLS/SSL do not belong together
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)
 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)
Network / Link Layer Muddle
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.
- Tarian.liber has posted the exact same text at Template talk:OSIstack#Network / Link Layer Muddle and has actually edited his ideas into Template:OSIstack. Let's keep the discussion there rather than replicate it here. --EnOreg (talk) 14:23, 1 September 2013 (UTC)