Template talk:IPstack

LDAP

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

RPC

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)

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.

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 158.75.104.113 (talk) 16:10, 23 May 2012 (UTC)

NDP

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

[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 91.185.69.83 (talk) 13:36, 23 February 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 (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

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 (talk • contribs) 20:29, 25 March 2014 (UTC)

OSPF is not a layer 2 protocol

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)

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

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)

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)

EAS in conflict with the purpose of this template?

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)

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)

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

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)

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

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)

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

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)

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

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)

Hello, FleetCommand. Thanks for the clarification. That is all the answers I needed. Best regards, Codename Lisa (talk) 20:16, 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)

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

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)

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)

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)