Template talk:IPstack

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking (Rated Template-class)
WikiProject icon 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.
 Template  This template does not require a rating on the project's quality scale.
Taskforce icon
This template is supported by Networking task force.


Where's LDAP? Developex (talk) 13:05, 30 December 2010 (UTC) Developex


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: -- (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[edit]

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.

Kernel.package (talk) 06:38, 11 August 2011 (UTC)

ICMP and ICMPv6 are transport layer protocols not Internet layer protocols — Preceding unsigned comment added by (talk) 16:10, 23 May 2012 (UTC)


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)

Routing protocols[edit]

[1] 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)

2gw.ru — Preceding unsigned comment added by (talk) 13:36, 23 February 2013 (UTC)

Network / Link Layer Muddle[edit]

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 (talk) 19:27, 26 August 2013 (UTC)

Tarian.liber has posted the exact same text at [Template talk:OSIstack#Network / Link Layer Muddle] and has actually edited his ideas into Template:OSI model. Let's keep the discussion there rather than replicate it here. --EnOreg (talk) 14:23, 1 September 2013 (UTC)

ARP/NDP are not L2 protocols[edit]

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).

If you search the Internet, there is much debate on this. But layer 2 is not the preferred answer. — Preceding unsigned comment added by Alexandrujuncu (talkcontribs) 20:29, 25 March 2014 (UTC)

OSPF is not a layer 2 protocol[edit]

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 (talkcontribs) 20:39, 25 March 2014 (UTC)

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)
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)
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)
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)
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)
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)

layer for OSPF[edit]

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

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)