Template talk:Internet protocol suite/Archive 1

Archive 1

Confusing?

I am unconvinced that this diagram makes any sense. Its organization as a table belies the fact that the column information is strictly meaningless. FTP and SMTP are not bound to any particular version of IP, nor is IRC any more bound to Wi-Fi than UDP is to a token ring. -Peter Farago

If you read the comments at the end of Talk:Internet_protocol_suite#Confusing layers, you'll find the rationale behind this better explained. (Hmm, maybe I should put that text in OSI model....) Noel 12:33, 18 Sep 2004 (UTC)

Welcome to 2005. The ISO/OSI model may have made sense in 1990, but it's not applicable to the TCP/IP protocol suit. Example: IPv6-over-UDP.

Hah. It didn't make sense in 1980, let along 1990. Noel (talk) 17:48, 14 September 2005 (UTC)

You mispelt suite ha ha!!!!

You misspelled misspelled. Or was that ironic? I thought maybe, or maybe not, considering the four idiotic exclamation points. Uh...ha? -D.D. —Preceding unsigned comment added by 76.172.145.248 (talk) 20:53, 24 March 2008 (UTC)

Colors

I just changed the colors in the table. They were way too dark in my browser (especially the blue). I suggest we not go below "CC" for any of the 3 color components in bgcolor="#RRGGBB". - dcljr 08:46, 31 Jul 2004 (UTC)

Confusing protocols

I removed ICMP in part because it was at the wrong layer, but mostly since it is such a confusing case. See Talk:Internet protocol suite for more. It seemed better not to include any of these confusing cases (like ICMP or any routing protocol) in the diagram (where there is of course no room to explain). Noel 13:08, 14 Sep 2004 (UTC)

Concur about DHCP, although if I had to put it at a layer, it too would go at the network/internetwork layer. I'm wary of adding SNMP, because that might be confusing too. Noel 12:33, 18 Sep 2004 (UTC)

ARP

(copied from Talk:IPv6 -- JTN)

Wise to have someone second this before changing it, but in the table in the top right which lists protocols, ARP is given in the Network Layer. This is incorrect - ARP does not use IP datagrams, it uses Ethernet frames, and is part of the Data Link Layer. Toby Douglass 16:33, May 26, 2005 (UTC)

ARP is a bridge (sic) function that indeed uses ethernet frames to translate IP(v4) addresses to MAC addresses. But it is not a data link layer protocol but works on top of the data link layer. W. Richard Stevens however does classify then as data link layer. I guess the template should be fixed thus. They are a bit odd tho, as is ICMP. Spearhead 21:15, 26 May 2005 (UTC)

In a properly designed model, we'd not only have a "network" layer above the "data link layer", but an "internetwork" layer above that, before getting to "transport". In that model, ARP would be assigned to the "network" layer (as would things like X.25, various MAC functions, etc).

People keep doing stupid things like putting ARP in the "data link layer" because they are trying to cram 10 pounds of you-know-what into a 3 pound sack. Noel (talk) 17:48, 14 September 2005 (UTC)

DHCP

129.67.23.117 has placed DHCP in the network layer. I'm not convinced, given that it runs on top of the UDP transport protocol. -- JTN 12:58, 2005 Jun 2 (UTC)

I concur. DHCP definitely does not belong in the network layer, due, if nothing else, to the reason mentioned above. — Itai (f&t) 18:40, 4 Jun 2005 (UTC)

Actually, as long as Internet Protocol is in the "network" layer (the 7-layer model is a piece of cr-you-know-what), DHCP does belong there, because it's part of the "internetwork layer" functionality, along with ICMP, routing protocols, etc. Noel (talk) 17:48, 14 September 2005 (UTC)

Physical layer

Why are only largely obsolete serial standards, RS-232, EIA-422, RS-449, EIA-485 mentioned? I'd drop all but one and add 10Base-T etc. --agr 1 July 2005 03:39 (UTC)

RS 232 does not belong in the template, it has as much relevance to the "stack" as IEC 320 has - after all, every piece of hardware needs a power plug, right? --Wtshymanski 14:20, 7 November 2005 (UTC)

Perhaps many of these are obsolete for end users in countries with broadband, but they are decidedly not obsolete in a number of embedded/dedicated computer systems (e.g., NMEA 0183, a variant on RS-423, is the basic protocol between shipboard sensors and computers), and in third world countries that still use modems. Howard C. Berkowitz (talk) 00:00, 17 November 2007 (UTC)

Major change

I am not sure what is the point of this template. I removed some unrelated protocols. For example, when using HTTP, you don't have to think about IPv4 or IPv6. Those belong to the different universes. -- Taku 11:29, July 31, 2005 (UTC)

This is to illustrate network layers and provide links between them. See OSI Model. The protocols you listed are all on the application layer. Reverting. --ChrisRuvolo (t) 16:59, 2 August 2005 (UTC)

Not different universes, but different protocol layers. This is exactly the point of this template. --Betterworld 17:42, 2 August 2005 (UTC)

By different universes, I wanted to mean different protocol layers. I think each article about a protocol has to talk about the protocol first and foremost not layers. Of course, it is important to note how those protocols can be implemented but that can be done by writing a text not by putting a table. -- Taku 22:52, August 2, 2005 (UTC)

First, the template is named "IPstack" not "ApplicationProtocols". Secondly, a box showing protocols at various layers is useful and informative: a reader can see the larger picture and context for the protocol. A box showing only a set of unrelated application protocols (as you would have it) is not very useful because you gain little information about the protocol in question. Please don't revert again until you've gained some consensus for your change. — Matt Crypto 23:03, 2 August 2005 (UTC)

I am not saying that the table makes no sense. What I want to try to say is that it makes little sense to put the table to every single article about a protocol; I have no problem having a table like this in one place. In wikipedia a box either eases the navigation and gives a summary not provides the big picture. Besides, I don't think the box helps understand about a protocol in question. As I said above, when you want to learn about HTTP, it is not necessary to know about protocols at other layers. That's the whole point of layering. Because the width of a template is too long, at least can we agree on moving the template to the bottom of an article? -- Taku 23:45, August 2, 2005 (UTC)

Choice of layers

Right, I'm no expert on this, but there seems to be a lot of contention about the way the layers are labelled in this template. The main issue seems to be that the OSI model, as it currently uses, doesn't really map well to the TCP/IP stack; individual issues we need to agree on include:

• Does it make sense to split this template at all? The protocols involved can often be used in all sorts of odd combinations (one user pointed out that "You can do ICMP-over-IP-over-HTTPS-over-TCP-over-IP-over-IPv6-over-UDP-over-IP for example"), but does that negate the usefulness of this as an "overview" and navigational aid? And if we don't have layers, would that mean deleting the template, having removed its only useful attribute?
  • A logged-out user writes: While that ICMP-over-IP-over-HTTPS... is a bit overkill, there are some "real world" examples I know of:
    • icmpchat - Custom IM protocol over ICMP over IP
    • Teredo - IPv6 tunneling that works via NATs; IPv6 over UDP over IP
• Is there a better set of layers we could use? PioM has been suggesting one in which there is an "Internetwork layer" instead of a "Network layer", with a merged "Network access layer" beneath it, and cites Cisco as his source for this. If we do go with a different layering model, we should do so consistently, and link to descriptions of or appropriate to that layering model. The Internet protocol suite article should also be updated to refer to said model, and discuss protocols with reference to it.

So, what do people think? - IMSoP 21:07, 19 August 2005 (UTC)

I'm studing telecommunication (last year) we were teached that in OSI model there are 7 layers but in TCP/IP stack there are 4 layers.

I have also certify at CISCO CCNA and there was also 4 layers in TCP/IP stack: 1. Network Access layer 2. Internet(called also Internetwork) layer 3. Transport layer 4. Application layer. -PioM _EN DE PL 21:25, 19 August 2005 (UTC)

1. Network Access layer (agregates functionality of 1st, 2nd, and some 3th from OSI)

2. Internetwork layer (agregates funct. of 3th OSI layer)

3. Transport layer (agregates funct. of 4th, and some funct. from 5th. session layer)

4. Application layer (agregates some funct. of 5th layer, 6th and 7th)

I will be accessible since Monday. -PioM _EN DE PL 21:30, 19 August 2005 (UTC)

Hm; looking back at Internet protocol suite, I see this assertion:

"There is some discussion about how to map the TCP/IP model onto the OSI model. Since the TCP/IP and OSI protocol suites do not match precisely, there is no one correct answer."

The diagram there actually shows 5 layers, although you have altered this to label two of them "1"; the text isn't entirely clear which version is being referred to.

Now, I'm not saying you're wrong - this really isn't my field of expertise, though I am a computer scientist - but it's not clear to me that this arrangement of layers is as well defined as the OSI model. If there is a standard Cisco definition, though, that is probably worth describing, and labelling as such, with references.

Hm, I'm beginning to wish I'd started this thread at Talk:Internet protocol suite instead... - IMSoP 21:48, 19 August 2005 (UTC)

I'd love to discard the ISO 7-layer model, as it is totally useless and confusing for describing everything below transports (such as TCP) and above framing (e.g. HDLC). Cramming X.25, MAC, ARP, IP, ICMP, etc all into one layer is worse than useless. However, the model is widely known, and for some reason (terminal brain damage?) people keep using it, so we at least have to talk about it.

However, we don't have to use it in our articles. It just confuses the heck out of naive readers. If someone can locate a better model we can cite (heck, I could whip up one, but that won't do us much good), that would be perfect. Basically, it just needs to be the ISO model with one extra layer ("internetwork").

I don't like the Cisco model for several reasons. For one, it's a company proprietary thing, and much as Cisco propaganda would have us believe otherwise, there's more to networking than Cisco. For another, it's too simple: cramming everything under "internetworking" into a single layer makes it harder to explain all sort of things. (E.g. how MPLS relates to everything else, how the various 802.* things can be bridged together because they all use a common packet format/address-space across different technologies, etc.) Noel (talk) 17:48, 14 September 2005 (UTC)

Here's my $0.02... I think the problem is that you're trying to show structure in the IPstack template, when it is really just supposed to be a bunch of links to the individual articles. To make it right would make it huge and over-complex. So make it simpler. I guess it still needs some layering, but chuck out the ISO terminology (irrelevant) -- in fact don't label the rows at all, just use dividers (kind of like Template:History_of_China). OTOH, I think a real diagram showing the true structure -- ie. what runs over what -- would be useful in the actual "IP Suite" page. -- Johantheghost 22:11, 16 September 2005 (UTC)

All of them sound good to me! Do you want to do the diagram showing what runs on top of what, or shall I? (Reply at my talk page.) Noel (talk) 23:26, 19 September 2005 (UTC)

I think there needs to be some kind of notation in here for people taking Cisco tests that by Cisco standards there are only 4 layers. It may be proprietary, but it wouldn't be good for someone to start getting confused. —The preceding unsigned comment was added by Phren79 (talk • contribs) 02:31, 16 January 2007 (UTC).

Template overuse

Why is the IPstack template placed on so many other pages? It makes sense to put it on pages about IP related protocols such as TCP/UDP/etc. but not on the physical layer pages such as Ethernet and Token Ring. If someone is looking for information on Ethernet or Token Ring they probably don't want to know about the IP stack -- just one of many protocols which can run over the medium they're reading about. Mention of the IP stack in a "see also" section should be sufficient.

Is anyone against removing the IPstack template from Ethernet & Token Ring's pages (and others)? Sfisher 00:39, September 8, 2005 (UTC)

So what if people don't expect stuff to show up they don't want to see? Are we going to hide the truth , just because people don't want to know about it? This is an encyclopedia. Logictheo 18:48, 20 November 2006 (UTC)

I just visited the Ethernet page in order to learn about the Ethernet, and I found the IPstack template helpful.Rouencpucelle

I also like the IPstack in the sidebar. I found the reminder useful even though I wasn't searching for it.Stayce —Preceding unsigned comment added by 81.148.157.175 (talk) 10:54, 9 July 2008 (UTC)

Navboxes like this one are just a bad idea altogether. Navboxes work in very limited cases, where one has a set of tightly related articles where readers of any one of the articles are likely to want to review the others. That is not the case here. I have removed this navbox from Optical fiber.--Srleffler 04:01, 13 November 2007 (UTC)

Websphere MQ

I think Websphere MQ is not so frequently used as to belong on this list. (There are some other protocols which I would like to see added to the list - XMPP and Whois, for instance - but as this really is a matter of personal preferences, it is probably best if we stuck to a representative few.) — Itai (f&t) 18:51, 21 September 2005 (UTC)

• I agree. There's too many application levels protocols listed that really don't define the internet: IRC, NNTP, SIP, BitTorrent could be axed as well. Also, the transport level is getting burdensome. Is every research protocol going to be listed? Dols 21:08, 24 September 2005 (UTC)

Combine Data Link and Physical layers

I think the Data Link and Physical layers should be combined on this template. I tried, calling it the Link layer, but the change was reverted so I'll explain my reasoning. The comment on the revert was "ethernet doesn't run over thin air". True enough. But what Ethernet or any other link "runs over" is not part of the IP stack. All IP (v4 or v6) cares about is that sending a packet over a link will get it to the recipient IP stack; whether the links sends it over thin air (Wi-Fi), some type of cable (like Ethernet), or recursively calls the IP stack (like a VPN) is irrelevant. Important, certainly. But this isn't the OSI model; IP doesn't have separate Data Link and Physical layers.

There is no real standard term for the layer below IP. My preference is Link, which is what IPv6 calls it. An older term is Network Access (it actually predates IPv4); I don't like it as well, but would accept it if there are objections to Link. --Rick Sidwell 02:11, 10 November 2005 (UTC)

By that logic it should be removed entirely. At this point, I disagree with the merge. I'll let some others chime in though. --ChrisRuvolo (t) 02:52, 10 November 2005 (UTC)

Encapsulation

Recently, an anonymous user has added a large number of encapsulation protocols to the template. The list was too extensive, so I have removed it. I am uncertain if we need it at all or if it is indeed relevant. --huwr 23:41, 3 January 2006 (UTC)

Spam

I've used this infobox as bad example in an infoboxes considered harmful discussion below WP:LEAD. -- Omniplex 23:26, 7 April 2006 (UTC)

Middleware/Infrastructure for DNS and DHCP, Border Gateway Protocol (BGP) etc.?

Any objection to adding the crucial BGP to the stack template? --NealMcB 22:32, 23 May 2006 (UTC)

This diagram is often used less as a stack reference and more as a list of important protocols. Having a section, perhaps titled "Middleware" or "Infrastructure" might be one place to put stuff like BGP, DHCP, and DNS, for that matter.... --NealMcB 04:43, 28 May 2006 (UTC)

Not sure if BGP is in the right place here as it actually runs on top of TCP(port 179) and should probably be reflected as such. Also what about OSPF, which is IP Protocol Type 89 and should be in there.Sstgfraser 22:00, 18 December 2006 (UTC)

Every one of these is Layer 3 Management, according to the ISO Internal Organization of the Network Layer document. As a participant in the IETF working groups for BGP, ISIS, and IETF, I can say that no one there discusses layering, other than to say that it is the payload, not the encapsulation, that is relevant. BGP and RIP are encapsulated in transport, OSPF/IGRP/EIGRP are internal network layer encapsulation just like IGMP and ICMP, and ISIS is data link encapsulated. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)

I have to agree with Howard here. OSPF does not operate at the Data Link layer; it uses IP protocol 89 and utilizes multicast addresses 224.0.0.5 (all OSPF speakers) and 224.0.0.6 (DR). IS-IS would be a much better choice to place in this box. I'm not sure why kbrose reverted my edit; it's completely incorrect. Daedalus01 (talk) 18:24, 16 October 2008 (UTC)

OSPF does not operate at the 'Data Link Layer', that's true, because it's not an OSI protocol. Per Internet Standard RFCs OSPF is defined to operate in the Link Layer, whether or not it uses IP protocol is irrelevant, as TCP/IP does not mandate strict encapsulation sequences. OSPF/IPv4 was once considered an Internet Layer protocol, but since IPv6 it is at the Link Layer as it only operates in the scope of the local link. One could split it into OSPFv2 and v3 and place it in both layers, I suppose. IS-IS is not a TCP/IP standard protocol really, but OSI. Kbrose (talk) 18:55, 16 October 2008 (UTC)

First: I noticed someone removed DNS and DHCP from the IP stack, but these are part of the IP stack application layer in the literature. Show me a good reference, and we can discuss it. may Is really DHCP and DNS middleware? Secondly: I don't understand the above. Okay you probably mean that DHCP are machine-to-machine communication application protocols protocols rather than human-to-machine communication, but I thought middleware was about CORBA, RPC, XML, WSDF, etc, i.e. generic distributed systems rather than specific applications. Secondly: Why invent an IPstack that differs from the literature? MIddleware is part of the application layer in the computer engineering tradition. Mange01 22:22, 18 December 2006 (UTC)

Middleware is not a concept used in the IETF, IEEE, or ISO literature. DHCP is considered a management protocol for the network layer, and DNS doesn't fit neatly, especially DNS dynamically linked to DHCP or the IP Control Protocol of PPP. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)

Routing protocols are part of the network layer. Using some OSI management terminology, they are layer management as opposed to application protocols, but, from experience in the IETF, no one in the Routing Area is particularly concerned with coercing them into OSI layering. Hcberkowitz 21:44, 17 May 2007 (UTC)

Bittorrent?

Why is BitTorrent on this template? It isn't covered by an RFC, like most of the others. -- Mikeblas 01:18, 5 August 2006 (UTC)

I have removed it. Only non-proprietary standards should be included. At the network layer and above this corresponds to RFC:s. At the physical layer and data link layer there are no RFC:s, but IEEE standards, ETSI standards, ANSI standards, etc, should be okay. Mange01 16:34, 6 November 2006 (UTC)

New navigation for network related topics?

While surfing on wikipedia i came accross several articles on religions such as Christianity and Islam. As you can see, the enormous amounts of pages covering these topics are neatly bundled using the navigation on the right. At the moment we have the IPstack menu for network related topics, but i thought i'd kick it up a notch. BAM! Check out my alternative menu Template:Networks (work in progress) based on the OSI-model. frankly, i don't give a shit if we use tcp/ip or osi, as long as we don't mix those two up in articles which can be quite confusing. discussion is also possible at Template_talk:Networks --Vincent de Ruijter 05:05, 15 October 2006 (UTC)

Five layer model

The IPstack template should be modified to the more modern five layer model. Most text books have abandoned the old four layer TCP/IP model (and also the OSI model to some extent). Anyone? Mange01 08:55, 30 October 2006 (UTC)

I have now added the physical layer. Mange01 16:32, 6 November 2006 (UTC)

What means under "old four layer TCP/IP model"? TCP/IP stack is DoDs implementation of OSI, so there must be four layers - Physical, Internet, Transport, Application. NTllect 06:29, 20 February 2007 (UTC)

The five layer model is not "more modern" in the sense of appearing in any primary source or major vendor source. It is in a few textbooks. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)

Probably the most popular networking textbook right now in the US is written by Kurose and Ross, "Computer Networking, A Top-Down Approach", which does in fact use the 5-layer model. I agree with the first comment that the 5-layers should be used. 4 layers are used for simplicity while 5 layers are used for a more logical approach.

Internet protocols above the application layer

I suggest that there should be a row for "Internet standards above the application layer". I think about MIME, XML, SOAP, WSDL, etc. Only protocols and other standards that has an RFC should be included there. Or do you think that MIME is not part of the TCP/IP protocol suite? See also the discussion under Talk:Internet_protocol_suite#Web_services_model.3F_Do_we_need_an_extra_layer_in_the_future.3F Mange01 10:20, 30 October 2006 (UTC)

I agree these are above the application layer, but not that they are of the same kind. MIME, XML, and HTML are transfer syntaxes while SOAP is an application programming interface and service definition. Hcberkowitz 21:45, 17 May 2007 (UTC)

Encryption Layer

How about an encryption layer between the transport layer and the application layer? For example, secure web pages use SSL between TCP and HTTP. —The preceding unsigned comment was added by 84.104.229.104 (talk) 19:09, 24 December 2006 (UTC).

The layers are not for us to decide - there is a standard four-layer Internet stack model (detailed at Internet protocol suite#Layers in the Internet protocol suite stack), and a semi-standard five-layer model, drawing on the older OSI model, in which the network access layer is split into its OSI component layers. The OSI model, by the way, has a layer which takes care of encryption - the presentation layer. — Itai (talk) 20:10, 24 December 2006 (UTC)

Again, IETF didn't concern itself with strict layering because it doesn't use the concept. Consider, however, just IPSec: the transport mode is tunneled between end hosts, while the tunnel mode is stuck on by a security gateway middlebox that breaks a basic layering model. The "3-dimensional" ATM model, which adds a dimension of user, signaling, and management to the protocol choices considers this to some extent. Howard C. Berkowitz 09:55, 16 November 2007 (UTC)

Diagram is completely broken, since transport layer is misssing

It seems to me that the diagram us broken. The important transport layer (layer 3) with the UDP and TCP protocols are missing. This has to be corrected, but in my opionion, all layers have to be rearranged. (a common model is that layers 1 (physical) and 2 (logic link) do not belong to the TCP/IP protocol family itsel, layer 3 is IP, layer 4 are the transport protocols (UDP, TCP, with some reason ICMP) and the application protocols (TELNET, FTP) are above layer 4 (layer 5 is you want). However, this interpretation reflects the OSI-Model, other models are possbile. But never ever leave out the transport layer! --87.181.51.194 06:12, 23 January 2007 (UTC)

Six layers ?!

While I can understand the discussions around 4 or 5 layers, I truly don't see the argument behind six layers ! And the explanation "I am going to add one more layer" is not very enlightening... Any clues ? I would revert, but I'm maybe missing something here...

Self-reply: given the contribution coming from the person who passed changed the 5 to a 6, I think I can safely say that this was just some fooling around... Reverting to 5 --15:00, 5 April 2007 (UTC)

Layer pages

The layer pages are very confusing. If I click on a link from the TCP/IP info box it goes to page with an OSI box on the right, sometimes there is a TCP/IP box under it but not always. While browsing through I ended up clicking OSI links by accident when I was trying to read up on TCP/IP. Needs to be clarified for those that are new to the subject. --AGruntsJaggon 16:42, 7 May 2007 (UTC)

layers all wrong

the way to get the layers right is as follows. If you are considering all protocols listed at layer N, you should be able to remove all layers above N, and the layer N protocols should be unaffected (i.e. still be able to function). For instance, Ethernet does not depend on IP. Take away IP, ethernet still works (you can still use IPX, Appletalk etc). Take away Ethernet however, and IP won't work.

There are many listed cases that break this rule.

Layer 2: PPTP depends on TCP and GRE, which both depend on IP. So, must be layer 5. Take away IP, and PPTP won't work. L2TP depends on IP Layer 3: IGMP, ICMP, RSVP, BGP, OSPF, IPsec all depend on IP, so must be layer 4. RIP depends on UDP which depends on IP, so must be layer 5

Layer 5: MIME is not a protocol, it is a data format

Add Token Ring to layer 2.

Tunnelling protocols don't really fit anywhere. PPTP, IPSec for instance. Sure, you run IP over them, but it's another copy of IP. PPTP won't work without IP underneath it, so the dependency is clear.

Actually I think the model is wrong, since it does not consider a distinction between transport and management. Strictly speaking ICMP, IGMP, OSPF, BGP etc are infrastructure management protocols, they aren't used to transport data for higher level protocols.

e.g:

The 5 layer TCP/IP model
5. Application layer HTTP, SMTP, POP3, IMAP, FTP, PPTP, SIP, SNMP, RPC	Management DHCP, RIP, OSPF, BGP ICMP, IGMP, RSVP
4. Transport layer TCP, UDP, GRE, ESP, IPIP, L2TP
3. Internet layer IP, ARP, RARP
2. Data link layer Ethernet, Token Ring, PPP, Frame Relay etc
1. Physical layer Ethernet Physical layer etc

my 2c. —The preceding unsigned comment was added by 125.237.240.118 (talk • contribs) 21 June 2007 (UTC).

A few comments:

* Your suggestion is interesting, but is it supported in established literature?

Yes. See my comments below for specific citations. See RFC 1122, RFC 1958 and RFC 3426 for the IETF view, which establishes four layers in RFC 1122, but then, in the latter two architectural RFCs, deprecates strict layering. ISO 8648, the Internal Organization of the Network Layer, splits the existing network layer into three sublayers, arguably with some overlap, not complete, with the IEEE 802.1 architecture of the bottom two layers. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

It isn't extensively considered in tunneling protocols, as the IETF essentially considered the number of layers to be a non-issue. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

* Does someone have time to search in the literature for the most common five layer TCP/IP model, and present them at this talk page?

The problem is that it only appears in certain textbooks, not any primary source, or even what I'd call a strong secondary source such as vendor documentation from Cisco, Juniper, Nortel, etc. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

* Perhaps we should remove all tuneling protocols into a separate {{tuneling protocol}} template, with one column (or row) for each of the most common alternative protocol stack. For example, one alternative is IP over PPP over L2TP over TCP over IP.

* It would also be interesting if someone developed a separate {{SOA protocol stack}} template, showing alternative protocol stacks for web service in each column or row. I beleive that examples of alternatives are RPC over SOAP over HTTP, XML over HTTP, WSDL over HTTPS/SSL, etc. Okay, XML and WSDL are not protocols, for data formats, similar to MIME, so "protocol stack" may not be an appropriate name.

* Question: What to do about MPLS?

MPLS is yet another reason to show that the idea of strict layering doesn't work. MPLS allows for an arbitrary number of stacked labels, each label level arguably being a "layer". Some simple real-world examples would be to have one level of label at an enterprise connection to its service provider, which is to be preserved at the other end of the connection to the other site(s) of the enterprise. As soon as that labeled MPLS packet hits the ISP, however, the ISP pushes another layer of label onto it so it can group Forwarding Equivalence Classes (a specific MPLS term) variously of the same quality of service and different end users, or different qualities of service for multiple end users. There are many examples of this with RFC 2547 implementation, with FECs or labels or both associated with some of the more complex delivery policies.

Even a single large ISP, however, may push down another layer of labeling if it has a distinct edge-vs.-core architecture. Further, if the first ISP now leases MPLS links (e.g., a regional provider going to a national or transoceanic provider), the latter "wholesale" provider may very well push one or more additional label/layers onto the stack. One is a minimum for carrying "wholesale" traffic; two or more might be used with edge/core organization.

Do note that a simpler but still two label level structure exists when encapsulating user VLAN 802.1q labels into an internal VLAN inside the provider cloud, called "Q-in-Q". Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

Mange01 19:36, 28 June 2007 (UTC)

I would still prefer to see a four layer model. Apparently "modern text books" split the bottom layer into the OSI data link and physical layers. I haven't tried to verify this, but can see how it would be useful for pedagogical purposes, especially since the OSI layer numbers are so commonly used in so many contexts today. But TCP/IP really doesn't include this separation; IP just passes the packets to whatever "link" or "network access" facility is used by the interface, whether it be Ethernet, MPLS, or a tunnel. So the issues of how to handle tunneling protocols and MPLS only exist because the bottom layer is split here. I'd like to see how the text books that use a five layer TCP/IP model address this.

But if someone has time for a literature search, please don't restrict it to five layer TCP/IP models. The (apparently obsolete) four layer model does have advantages!

I've never seen a TCP/IP model that treats management protocols separately. I agree it's an interesting suggestion, but there would need to be literature support before including it here.

--Rick Sidwell 04:44, 30 June 2007 (UTC)

The most common way management was shown in ISO or IEEE work, which considered layering, was as a second parallel vertical stack

OSI user layer	OSI management layer
Application	CMIP plus layer management protocols for Application itself, such as ACSE and ROSE. SNMP in an IETF stack.
Presentation	(null management in basic ISO, although arguably crypto setup in cryptographic encoding rules. Think, for example, of IETF ISAKMP
Session	(null in basic ISO)
Transport	(null in basic ISO, but non-null in end-to-end tunneling. This is discussed in ISO Technical Report 10000, which is not available online and free)
Network (3 sublayers per ISO 8648 IONL)	Multiple management levels. Layer management ("inside the cloud") includes network layer routing protocols regardless of how they are encapsulated. At the "edge", ARP and related Subnetwork Dependent Convergence Protocols
Data Link (MAC/LLC per IEEE)	IEEE fuses station management across Data Link and Physical
Physical (split under various names, such as PLS and AUI in Ethernet DIX2, and MII/MDI in later IEEE and ANSI (i.e., FDDI) standards	Fused with station management

Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

No primary or strong secondary source uses five layers

(slightly edited from TCP/IP model talk page; I just learned of this discussion and will address some of the points above).

I quite seriously propose that the five-layer stack drawing, which is not authoritative by any IETF document, be replaced with a four-layer stack consistent with RFC 1122. As far as I can tell, the basis for the five layer argument are only secondary sources, such as Stallings' book.

As long as I am being bold, I'd like an agreement to put strong words in the introduction to this article that it is not OSI-compliant, there is strong historical reason that the designers of this stack did not intend it to be OSI compliant, and that people experienced in using and teaching this stack find that one of the chief barriers to understanding the most widely used stack in the world is that they are trying to force it into an obsolete OSI model. Howard C. Berkowitz 22:29, 13 October 2007 (UTC)

I agree with you that a four-layer stack makes more sense and would be more appropriate... however, I think it's important to keep an article (or part of an article) on the five-layer model, if only because it's so well-known. If you want to create an article for the four-layer model (or maybe better, just expand this article), I think it would be an excellent idea.

But it sounds like you might just be interested in replacing that awkward TCP/IP Model template, which is actually maintained over in the Template area: Template:IPstack. It looks like they've been arguing on the Talk page about the number of layers to include for quite a while. :)

Either way, I approve of both your proposals. Indeterminate 07:18, 16 November 2007 (UTC)

Thank you. I'll try to clone this over at the Template area, but I've become frustrated about making any headway over here, because of loud and unsupported arguments that there is a five-layer model. I'm puzzled by the need to keep an article on the "five-layer model", which does not exist in any IETF documentation, but explicitly defines a four-layer model (RFC1122), and explicitly speaks against strict layering in several statements of architectural principles. ISO does not ever define a five-layer model; ISO started with a seven-layer model in ISO 7498, and then added sublayers in several documents. It does not exist in any IEEE document, which deal only with the bottom two layers and sublayers. These, I believe, constitute the primary sources on networking architecture and layering.

Further, it does not exist in any training material from Cisco, Juniper, or Nortel, and, as far as I know, Microsoft. The major vendors arguably are the chief secondary sources of de facto rather than de jure concepts of layering.

It exists, as far as I can tell, in some textbooks, and in Wikipedia. I've published textbooks myself, and I have asked a number of colleagues who are also networking book authors, and they never used the concept. If one makes use of the sublayering of IEEE or ISO, even ignoring the reorganization of the upper layers by ISO, one might get:

• 9 layers: OSI basic model plus IEEE sublayering of LLC/MAC and (two layers, but by different names in different documents), medium independent/medium dependent, or PLS/AUI in the original Ethernet documents.
• 11 layers: OSI plus the additional two layers of the Internal Organization of the Network Layer, plus the additional layers in IEEE 802.1 mentioned just above.
• 7 layers, IETF plus IEEE, taking the three layers from internetwork on up, and then two two-sublayer models below it.
• 9 layers, using the three sublayers of the ISO IONL, and the two sublayers of IETF in the bottom two layers, plus IETF end-to-end and application.

In the real world, however, all of these tend to break down when considering protocols that use recursion to create tunnels, such as L2TP, IP in IP, IPSec, MPLS (with arbitrary numbers of stacked labels), 802.1q-in-q, ATM LAN Emulation, etc.

I appreciate your comment, and will try to bring this to the template talk page. Unfortunately, I don't know how to create a revised template and propagate it, and, unless there is first some consensus that no authoritative reference uses five layers, it doesn't seem worth the effort if some people are going to keep citing a textbook or two that, as far as I can tell, is the only source. Howard C. Berkowitz 09:45, 16 November 2007 (UTC)

OSI Model vs TCP/IP Model

An anonymous user has changed the label on the box to read 'OSI Model' instead of 'TCP/IP Model', apparantly on the grounds that the TCP/IP Model is "only a part of" the OSI model. While the TCP/IP model could be viewed as a more general model whose layers correlate to those of the OSI model, it is not true to call one the other. It would, in fact, still be untrue to call one the other if one was a subset of the other, as claimed. As such, I am reverting this as a major inaccuracy (after originally seeing the rather major mislabeling on a protocol page). I note that this IP has been reverted before on the same change, and would ask them to discuss such a major change here before applying it again. —Preceding unsigned comment added by Namegduf Live (talk • contribs) 19:38, 23 February 2008 (UTC)

TCP/IP model

In the past week I have taken the initiative to resurrect the correct version of this successful model (as if there ever was another) and exposed myself to possible high-blood pressure problems. I have read RFCs for 20some years and found it not only shocking, but quite insulting to the founders of the Internet and every expert that helped along the way to deface their work, insights, and legacy by confusion rooted in pure ignorance of facts it seems. Promptly, someone tried to restore the misrepresentations today. I hope, that this knowledgeable community will be in support of the only IP model, as was as expressed here by others. Kbrose (talk) 19:58, 11 July 2008 (UTC)

Thank you. Excellent work. Indeterminate (talk) 04:54, 15 July 2008 (UTC)

Layer names and number of layers in the literature

The following table shows the layer names and the number of "Internet layers" in the "TCP/IP reference model" as presented in widespread university course literature on computer networking used today.

	Forouzan	Comer	Stallings	Tanenbaum	Kurose	Cisco Academy
	Five layers	Five layers	Five layers	Four layers	Four layers	Four layers
L5	Application	Application	Application	Application	Application	Application
L4	Transport	Transport	Host-to-host or transport	Transport	Transport	Transport
L3	Network	Internet	Internet	Internet	Internet	Internet
L2	Data link	Data link (Network interface)	Network access	Host-to-network	Link	Network interface
L1	Physical	Physical	Physical

Mange01 (talk) 22:19, 16 July 2008 (UTC)

Analysis

Well, let's pick them apart and see the merits (in no particular order)

KUROSE&ROSS

Let's start with the easy one. Don't have access to this one right now, but Mr. Kurose and Ross seem to be doing something right. They get 100 points for getting the layers right if one can trust this table.

Pretty bad state of affairs, only 1 out of 6 actually read the literature and can report it correctly.

TANNENBAUM

bottom layer: "Host-to-network Layer"

QUOTE: (this is the ENTIRE chapter on this topic)

  The Host-to-Network Layer
Below the internet layer is a great void. The TCP/IP model does
not really say much about what happens here, except to point out that the host has
to connect to the network using some protocol so it can send IP packets to it. This
protocol is not defined and varies from host to host and network to network.
Book and papers about the TCP/IP model rarely discuss it.

Well, certainly a well known author. But his insight into TCP/IP is truly mind-blowing. Is this all he can come up with? Apparently he hasn't read RFC 1122, where the layer is defined as Link layer, and populated with very well known protocols (ARP) and ETHERNET and IEEE 802 Encapsulation. Or perhaps, RFC 2328 (INTERNET STANDARD 54) and RFC 2740 that clearly place OSPF into the Link Layer, consistantly talking about Link State (as all link-state routing protocols should). Quoting: "OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis." which make this point very clear.

But then, of course, Mr. Tannenbaum, wasn't searching for references to the Link Layer, as he should have, but for some strange layer called Host-to-Network. Didactically very smooth and very pedagogical. Just save himself a whole chapter to write.

Of course there isn't much to write about, if you insist to move the Link Layer protocols into the Network Layer, as the OSI fanatics do. How more obvious can it be that this OSI layer stuff is more a brain cancer than intellectual discussion. But at least he is honest about that TCP/IP doesn't intend to cover the physical layer and he doesn't invent things, like non-existent layers.

CISCO

Just happened to look at their entire bookshelf recently, about 3 or 4 feet long, and opened the TCP/IP stuff. Discussion of models was pretty bad and when it seemed to move on to the lower than IP level(s) it abruptly stopped and suddenly slipped into CISCO-lese, in time-warp fashion. I thought I must have skipped a page or something, but hadn't. Hardly a worthy candidate to reference.

STALLINGS

-tba-

COMER

-tba-

FOROUZAN

-tba-

HOWEVER: RFC 3315

RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003 STANDARDS TRACK Authors from CISCO(!) Hewlett-Packard, Ericsson, Nominum (!), Nokia, Sun Microsystem Page 8 states as definition for terminology which is used throughout the text:

     link                      A communication facility or medium over
                               which nodes can communicate at the link
                               layer, i.e., the layer immediately
                               below IP.  Examples are Ethernet (simple
                               or bridged); Token Ring; PPP links,
                               X.25, Frame Relay, or ATM networks; and
                               Internet (or higher) layer "tunnels",
                               such as tunnels over IPv4 or IPv6
                               itself.

     link-layer identifier     A link-layer identifier for an
                               interface.  Examples include IEEE 802
                               addresses for Ethernet or Token Ring
                               network interfaces, and E.164 addresses
                               for ISDN links.

It seems like the original terminology is very much alive in STANDARD TRACK! And there seems to be no confusion what is contained in the link layer or what the layers name is. Clearly these authors don't need a physical layer to create STANDARDS for TCP/IP. Already they have more to say about the link layer than TANNENBAUM.

Kbrose (talk) 02:31, 17 July 2008 (UTC)

Vote: Four or five layers

This template has had five layers for over a year now, but recently it has changed to four layers. Also someone has without previous discussion tried do delete mentioning of a five-layer TCP/IP model in several articles. Please vote if this template should have four or five layers, and give short arguments. And what is the name of the bottom layer in case of four layers? "Link layer", "Data link layer", "Network access layer" or "Host-to-network layer"? See the table above. And is it okay to mention both the four and five layer models in wikipedia articles? Mange01 (talk) 22:21, 16 July 2008 (UTC)

• Five layers gets my vote. At least both the four layer and five layer TCP/IP models should be mentioned in wiki articles on the topic. Arguments: See the table above. The original four layer DoD model has evolved into a five layer model, according to several course books in computer networking that are widely used in today's university courses, because of pedagogical reasons, and because of shortcomings in the RFC terminology. It would be confusing for today's students if wikipedia does not mention this. The physical layer is mentioned in several RFC:s. In case of four layers, I would prefer that the bottom layer is not called link layer, since that can be confused with data link layer - it is not clear if it involves physical layer issues or not. Mange01 (talk) 10:22, 13 July 2008 (UTC)

• Four. Look, I sympathize. Times change; people want the TCP/IP model to reflect ideas they liked in the OSI model. But this contentious physical layer is, as your lovely table points out, still not standardized across the industry. A few textbook authors don't make any kind of consensus. We can add a section to the TCP/IP model page about the controversy, but I think this template should reflect the original model until an authoritative, industry-standard source publishes an updated version. Just my opinion. Indeterminate (talk) 23:37, 18 July 2008 (UTC)

• Comment: as long as this template is based on RFC 1122, which clearly it is at the moment, it needs to stay four. If an alternate source of equal or greater weight is found which states five, then the template can be updated to include the five layers along with a link to that source. But in either case, the template must agree with what its primary source says. --WayneMokane (talk) 02:20, 28 August 2008 (UTC)

RE

Please cite the RFC's you mention that constitute a physical level for TCP/IP and that don't directly relate to ISO or IEEE design. I can't remember where teaching-course books have advanced or "evolved" the state of affairs in the sciences or engineering, that's not done through text-books. There is no primary, normative, peer-review literature that advocates a 5 layer TCP/IP model (that I know of, please show us otherwise). TCP/IP never has been concerned with hardware design or physical issues. It only cares about receiving data frames from a link technology. It's not a top-down architecture for the design of networks and hardware, but a description of the methods that operate the Internet. Why don't you stick to using the OSI model for teaching, rather than forcing it into TCP/IP or vice versa? Ah, of course the students will ask why doesn't the most successful network ever use these principles? Well, you can explain the failings of OSI better perhaps, but don't blame IETF and the RFC-editor system for shortcomings that don't exist. How pedagogical is it really, when a student would pick up RFC 1122 and discover that the original creators of this technology use terms like "Link layer" that they never heard of in class and that all this text-book stuff is made up? Most of wiki articles already state that this layer non-sense is against the design intentions of TCP/IP and what the common comparisons are. They can read and there should be no confusion. Oh, confused they will be, why they are being taught rubbish in class. The most "pedagogical" education is the accurate reflection of sources. You seem to have some vested interest against that. Kbrose (talk) 03:25, 17 July 2008 (UTC)

OSPF and BGP

About OSPF, considering it under data link layer is really confusing. whatever the RFC says, it does not necessarily mean that it is a Dala-Link Layer anyway. Because OSPF functionality is not just a Layer 2 functionality. and we have to take this in consideration. OSPF acts as layer 4 protocol. I think what you say that the RFC says ( I did not see the RFC, but ppl above talked about it) does not mean exactly that the OSPF is a layer 2 protocol. You can review the OSPF header to be sure that it is not a layer 2 anyway.

about BGP, Why is it considered as Application Layer Protocol?? All what I know and all what I have studied indicates that It is a transport layer protocol. any reference?? any ideas why is that???

Amjad Abdullah (talk) 19:19, 9 December 2008 (UTC)

TCP/IP doesn't have a 'data link layer' and OSPF is therefor not considered as data link layer, but as Link Layer, as it operates only on the local link, does not traverse routers (although OSPF routers handle more than one link). BGP a transport layer protocol? please, study some more. It's simply an application trading network path information between hosts. It uses the transport layer to do so. Kbrose (talk) 21:23, 9 December 2008 (UTC)

Trying to align TCP/IP protocols into the OSI reference model can not be done satisfactorily. The placement of the OSPF into the data link layer is just one example. That being said, I also strongly disagree with placing the OSPF into the data link layer. Kbrose has pointed out that the OSPF does not traverse routers. That is only partially true (actually, the LSAs in LSUs are flooded throughout an area or OSPF domain, the virtual links use addressed OSPF packets), moreover, it is not a defining property of a Layer3 protocol to traverse routers. The OSI layers are defined by their functionality. The Layer2 layer functionality is to provide communication means between neighboring devices, i.e. between devices on a common (not necessarily shared) medium (segment). Obviously, the OSPF does not have anything to do with communication of two devices on a common hub/switch/broadcast domain, on the contrary, it relies on the prior possibility of neighboring devices to communicate! I personally tend to see the OSPF in the application layer.Paluchpeter (talk) 06:54, 15 April 2009 (UTC)

You correctly state that aligning TCP/IP protocols into the OSI reference model cannot be done satisfactorily. Yet, you continue on to use OSI terms and the OSI model here. This article, the template, concerns the TCP/IP model, not OSI. In addition, OSPF has always been developed and described within the TCP/IP suite. Please see the talk page Talk:Open Shortest Path First for prior discussions. Kbrose (talk) 17:52, 15 April 2009 (UTC)

Hi Kbrose. You are right about my OSI-ness :-) I let myself talk in OSI terms. Sorry about that, and thanks for pointing it out. I have read your discussion in the OSPF article about its placement. It was a very interesting reading and while I can't say you have convinced me, you made me think about a couple of things that I took for granted:

1. How shall a protocol be classified into a layer? Very often, it is classified by the services it depends on. Quite logically, they must be provided already by other layers, and within our usual hierarchical models, the services are provided by the lower layers than the layer in which the protocol under dispute is located. From this viewpoint, many people including me use to place the OSPF into the application layer, as it presently depends on services provided by IPv4 or IPv6 protocol. However, a second way to classify a protocol (and this is what you seem to prefer) is to classify it by the services it provides itself. Now, the OSPF clearly provides services to Internet layer, but not the usual "transport" service as, say, Ethernet does, but rather it provides control information on how shall the Internet layer operate. This would move the OSPF down to or under the Internet layer, maybe even to the Link layer as you have placed it. This second approach essentially tries to avoid the implementation dependencies. Clearly, the OSPF could be encapsulated directly into Link layer frames in a similar fashion to the IS-IS and it would work, so the Internet layer is not really necessary to deliver OSPF packets. Still, the Internet layer provides, for example, the addressing semantics (address formats et al.) used inside the OSPF messages... so even an OSPF placed on the Link layer (that should be agnostic about the Internet layer) needs to be Internet layer specific, at least in the addressing issues. That, in my opinion, moves the OSPF to the Internet layer, not as a user protocol used to transport user data, but rather as a support (or service) protocol used for purposes of the Internet layer itself.
2. You have yourself said earlier that the BGP is simply an application protocol. What makes you think differently about the OSPF?
3. May I contact you directly, using the e-mail function on the Wikipedia? This looks to be a longer debate and I am not sure if the Wiki talk page is the best place for us to discuss these subtleties.

Looking forward to your answer.Paluchpeter (talk) 06:47, 19 April 2009 (UTC)

Navbox

This template could slowly use some re-designing via Navbox.--Kozuch (talk) 21:24, 11 February 2009 (UTC)

I think it works better as a sidebar; there is an emerging meta-template for this purpose, but I'm a bit wary of deploying it right now. It works well as a sidebar for two reasons. The first is that it fills the top-right corner of related articles in lieu of a lede image (as few of the subjects have fitting images). The second is that a vertical layout is a nice analogue to the "stack" concept. Chris Cunningham (not at work) - talk 09:45, 12 February 2009 (UTC)

Sorry, I just dont agree with you. Sidebars templates are really disturbing in the articles and I see no good enough reason why this could not move over to nav-box. Such a navigational templates should be at the bottom of articles.--Kozuch (talk) 10:02, 12 February 2009 (UTC)

I don't think we're going to see the back of sidebar-style nav templates any time soon. As it stands, I reckon this is one of the better uses for the layout. Fancy taking this to a wider value to see what kind of support it has? Chris Cunningham (not at work) - talk 12:02, 12 February 2009 (UTC)

no navbox - When this template was recently converted from a blob into an infobox, I checked into other templates. I think the infobox is fine and I really don't want to see a navbox. I hadn't thought clearly whey, but I think Chris's comments above make sense to me. Wrs1864 (talk) 13:09, 12 February 2009 (UTC)

I have nothing against side-boxes, as long as you do not put on top of articles - which is impossible though.--Kozuch (talk) 14:01, 12 February 2009 (UTC)

template bloat

I am a little concerned about how many protocols are listed directly in this template. At each layer, there is a "(more)" link that shows all the protocols in the relevant category, so I don't think it is critical that every moderately-used protocol gets a spot directly on the template. I have hacked it back once, but I have concerns over how we now have two MGCP entries, GTP, RTSP, STUN, DCCP, NDP, "device drivers", etc. I guess in my opinion, we need enough of the very best known protocols at each layer so that someone looking at it can say "Oh! I understand which protocols fit where", and can click the appropriate "(more)" link if the protocol they are interested in isn't listed. Thoughts? Wrs1864 (talk) 20:37, 24 February 2009 (UTC)

In general terms, I couldn't agree more. I did have the concern when adding Megaco, I think that could be reverted. MGCP, on the other hand, is such a major protocol still to leave it out. I would say STUN could be eliminated, although in wide-spread use, it is a support protocol at best (now actually a potpourri of methods), and perhaps GTP is not well known by many, but the remainder in the template really represent the core of TCP/IP protocols and probably deserve their top exposure here. 'Device drivers' probably doesn't need the status here. Too remote from real TCP/IP concerns. Kbrose (talk) 21:19, 24 February 2009 (UTC)

I guess my point isn't whether MGCP is too much of a major protocol to leave out, but rather is MGCP well known enough to the typical reader of this template help as a guide to understanding. Most network/computer aware people recognize HTTP, TCP, IPv4, Ethernet, etc., and those help people understand the layers. The more clutter we have, the harder it is for people to scan the infobox and understand it. Does it really help people to have three e-mail protocols listed (SMTP, POP, IMAP)? Do we need SIP, MGCP, and SDP? Would it be better if the application layer was grouped by topic instead of alphabetical, so that IRC and XMPP are together, instead of picking one as a representative protocal or listing both? Wrs1864 (talk) 16:51, 25 February 2009 (UTC)

I think topical grouping within the layers might make a lot of sense, and I think it may have been tried before to a degree until someone alphabetized the list again. But grouping is probably only good for people that already know the protocols somewhat, not for people looking to find an acronym they haven't heard of before, but then, as you point out, there is the category page (more) linked in every group. I am not advocating that only protocols well know by everyone should be displayed, but those that are actually in wide-spread use (which would be the ones everyone should know). MGCP is a major protocol for VoIP still today, given that some of the largest consumer voice networks use it (BT, AT&T, Cablevision/OptimumVoice). If someone sees MGCP in this list and doesn't know it already, they have a chance to discover a major protocol that they should know, rather it being buried in the category page where they will likely not discover it. I think that's an important function of a navigation box like this. I think we should have all three e-mail protocols listed, yes, they are perhaps the busiest protocol group of the Internet. We should also have all major VoIP protocols, and we are still missing H323 for some reason, SDP might be secondary (support) priority. Kbrose (talk) 18:53, 25 February 2009 (UTC)

As I mentioned above, one solution to the "glob of protocols" at the app layer is to categorize them. I have created a possible IPstack template to show this idea on Template talk:IPstack/IPstack-categorized. I don't think this template is finished, far from it. I don't particularly like the layout, and I did not put a huge amount of thought into what the categories should be, their names, or exactly which protocols should go where. Still, I think it gives everyone an idea and makes things clearer to people who don't know most of these protocols. Thoughts? Wrs1864 (talk) 17:23, 5 March 2009 (UTC)

Looks great. I've moved it to template:IPstack/sandbox, the standard location for sandbox code. Chris Cunningham (not at work) - talk 09:21, 9 March 2009 (UTC)

Chris, looking at your edit history, you seem to do a lot with templates. Could you review how I implemented this idea if you have time? I tried several different things, none seem to be very clean (most didn't even work). Thanks. Wrs1864 (talk) 13:12, 9 March 2009 (UTC)

I think your implementation is about as clean and semantically sound as is possible with the {{infobox}} base template. If you have any questions regarding template coding please feel free to ping me and I'll see what I can do. Chris Cunningham (not at work) - talk 13:51, 9 March 2009 (UTC)

(outdent) OK, I've hacked on the template some more. I think it looks fairly good, but it is larger than the old one and I'm a little concerned about that. Anyone care to comment and/or improve it? Again, see template:IPstack/sandbox If no one objects, I may well more this to production soon. Wrs1864 (talk) 14:27, 9 March 2009 (UTC)

I think it's a fine looking design, but now that it's been presented, I think the old version with no categorization is preferable and quite adequate. Afterall this is meant to be quick-link navigation template with only the most important protocols. Application specific categories were never defined or mentioned in the TCP/IP model (with one exception, there is a notion of support protocols at the application level) and this opens the avenue for other editors to create more topics for their favorite protocols, as well as for controversies of interpreting which group a protocol belongs to. I don't like the concept of stuffing ever more information into templates instead of writing well composed articles about a subject matter. If someone wants to find, say, e-mail protocols, they ought to look for the e-mail article or a wikipedia category. We can only list a few examples in the template here, and categorizing it expands the task of choosing which ones are the most important. The categoriziation of the application protocols should be attempted in the article 'Application Layer', where there is plenty of space and where discussion can take place, not here. That article is a total mess currently. The template provides direct links into each layer article. This template is also linked into so many articles that have nothing do to with application layer protocols, and for those the categorization in that layer adds greatly to the template bloat mentioned in the past. Kbrose (talk) 15:36, 9 March 2009 (UTC)

Physical Layer protocols

I think it is necessary to add physical layers and protocols under the same. Widely used are RS232, RS485, RS422 & Physical layers of Ethernet, SPI & CAN. We can also expand this list based on the discussions. Also change the topic to ISO model which is more informative & Internet protocol suite as per RFC can be colored using a different color code under the sameFahidka (talk) —Preceding undated comment added 06:58, 28 August 2009 (UTC).

TCP/IP doesn't concern itself with the physical layer, perhaps you might like to read OSI model instead. Kbrose (talk) 16:45, 28 August 2009 (UTC)

OSPF is a layer 3 protocol not a link layer protocol

The current table lists OSPF as a link layer protocol. It is a layer 3 protocol (IP protocol 89) which works on top of other layer 2 technologies (ex. Ethernet, Frame-Relay, PPP). From the RFC (2328)

  4.3.  Routing protocol packets
       The OSPF protocol runs directly over IP, using IP protocol 89.
       OSPF does not provide any explicit fragmentation/reassembly
       support.  —Preceding unsigned comment added by 64.102.254.33 (talk) 23:24, 6 October 2009 (UTC) 

You're mixing terms with OSI; Encapsulation sequence is not a criterion in TCP/IP, only for OSI. OSPF runs on the local link only, see OSPF article and discussions there. Also, in OSPFv3 all IP specific address info is removed from the protocol. Kbrose (talk) 01:53, 7 October 2009 (UTC)

I think the above needs some work. It isn't clear to me (I am not an OSFP expert), but from reading several other sources it sure seems to run on top of IP...and thus would be a layer 3 (ISO) protocol. 192.91.173.42 (talk) 18:46, 15 October 2009 (UTC) Greg Edwards 15 October 2009

Again, this is a template for TCP/IP not OSI. TCP/IP does not use strict encapsulation layering as OSI is supposed to do, and whether OSPF runs on IP is not important, it's the fact that it only runs on the local network, by subnet as in OSPFv2, or by link as in OSPFv3. Kbrose (talk) 19:45, 15 October 2009 (UTC)

I agree that trying to stick to OSI layers is wrong. And I agree that individual OSPF messages traverse only one hop. But OSPF uses store and forward to communicate the link state throughout the routing domain. I think it should be listed at the Internet Layer, not the Link Layer. DonaldEastlake3 (talk) 02:37, 6 June 2010 (UTC)

But the distribution only happens because the routers have interfaces on multiple links. The network protocol doesn't communicate this across routers. Each router builds its own link state database. Kbrose (talk) 17:00, 30 July 2010 (UTC)

As stated in RFC 2328 OSPF is a TCP/IP internet routing protocol. It does indeed build database of directly connected links, but that doesen`t mean it is operating at layer 2 as of it`s purpose. The purpose of OSPF is to find and store network addresses which are used in the routing process, which does not happen to be data-link related. ″ Moy Standards Track [Page 10] RFC 2328 OSPF Version 2 April 1998

Lower-level protocols
           The underlying network access protocols that provide
           services to the Internet Protocol and in turn the OSPF
           protocol.  Examples of these are the X.25 packet and frame
           levels for X.25 PDNs, and the ethernet data link layer for
           ethernets. ″Dominikguz (talk) 08:36, 1 May 2013 (UTC)Dominikguz

You are using the wrong model of networking, referring to the OSI suite, the Internet Protocol Suite has a Link Layer, and any protocol that stays on the link is a Link Layer protocol. The latest versions of OSPF don't even use routable IP addresses, instead use link-local addresses exclusively, and the protocol is essential IP address system agnostic. Even in IPv4 an OSPF packet is never routed. Kbrose (talk) 18:16, 1 May 2013 (UTC)

dns

what is dns? —Preceding unsigned comment added by 122.162.71.43 (talk) 02:46, 10 October 2009 (UTC)

The Domain Name System, which uses UDP and TCP. DonaldEastlake3 (talk) 18:31, 26 May 2010 (UTC)

RTP protocol layer

Hi, there is a RTP protocol listed under application layer (7), but RTP is on the 5th layer - session. It provides a support for adding QoS at application layer (RTP alone does not ensure QoS), so it's a nonsense to list it under 7th layer. http://nsgn.net/osi_reference_model/the_internet_protocol_suite_a_lesson_in_protocol_stacks.htm —Preceding unsigned comment added by 88.146.86.251 (talk) 21:20, 18 January 2010 (UTC)

The TCPIP model only has 4 layers, so your comment is nonsense too. Kbrose (talk) 00:49, 19 January 2010 (UTC)

Including RADIUS and DIAMETER

Can we include RADIUS and DIAMETER in this info-box, as both of these protocols pages display it on top. EngineerFromVega (talk) 08:15, 27 January 2010 (UTC)

There are hundreds of protocols based on IP, we can only include the core protocols as stated in the guidelines for the template. Make sure others have a category for the layer and they will show up on the 'more' link. Kbrose (talk) 14:42, 27 January 2010 (UTC)

TRILL

Can we include TRILL (computing) as a link layer protocol? It provides link layer services. The TRILL Base Protocol draft has been approved as standards track document and is in the RFC Editor's queue. Numerous implementations are underway and an open source implementation for Solaris based on a slightly earlier draft is available... DonaldEastlake3 (talk) 15:36, 4 June 2010 (UTC)

I think the concern from the previous section (Including RADIUS and DIAMETER) would apply: why TRILL and not a lot of others? Only the major existing components should be in the infobox. Johnuniq (talk) 03:26, 5 June 2010 (UTC)

TRILL is a fundamental replacement for spanning tree and can incrementally IEEE 802.1 bridges in a network. It should be listed as an IETF link protocol. Unlike RADIUS or DIAMETER or hundreds of other IETF protoocls, TRILL is not built on IP. Although TRILL can transport IP, the links that connect RBridges (the devices that implement TRILL), can be any technology with standards specified for TRILL over Ethernet and TRILL over PPP. RFCs 6325, 6326. 6327, and 6361 have been issued. Thousands of pre-standard TRILL switches (RBridges) have been sold by Brocade and Cisco. All of the big merchant silicon manufacturers (Broadcom, Fulcrum, Marvell, Mellanox) are shipping chips with TRILL support. DonaldEastlake3 (talk) 00:36, 28 August 2011 (UTC)

OSPF is a layer 7 protocol

Greetings!

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)

Thanks, that's helpful. --Kvng (talk) 19:22, 30 July 2010 (UTC)

RTP

RTP is UDP plus timestamps. Why does RTP get classified as an application protocol here? --Kvng (talk) 14:13, 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)

TLS/SSL

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: --217.238.250.228 (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)

LDAP

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

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)

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)

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)

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)

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)

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)