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)

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)

I disagree with this interpretation and could give many strongly-supported opinions as to why; however, debating opinions is not necessary to see that OSPF does not belong in the link layer. This is objectively wrong within the TCP/IP model. The "latest IPv6 specs", including both RFC 2460 (1998) and the updated RFC 8200 (2017) make this clear when defining terminology:

upper layer  a protocol layer immediately above IPv6.  Examples are...routing protocols such as OSPF....
link         a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6....

So the spec defines OSPF in particular and routing protocols in general among the "upper layer" protocols "above IPv6", whereas the link layer is "below IPv6". I agree that encapsulation is not the only consideration when deciding what layer a protocol operates in, but here OSPF is not a lower layer protocol being tunneled over IP. It is legitimately an upper layer protocol in the stack under normal operations. CheerfulPaul (talk) 15:35, 14 October 2019 (UTC)

In addition to the arguments made above as to why OSPF does not belong to the link layer, I'd like to point out to RFC1812 section 7 which very explicitly states that routing protocols (including OSPF, IS-IS, BGP, and RIP) belong to the application layer in the TCP/IP model. I'm going to edit the template to that effect in a few days, and fix the paragraph in the Link_layer#Link_layer_protocols article. Tavositar (talk) 22:38, 2 November 2021 (UTC)

TCP/IP layering

Pigeonholes are not always easily defined. For example, from the point of view of what would be seen on an Ethernet cable, a packet carrying SMTP data consists of Ethernet : IP : TCP : SMTP, whereas OSPF looks like Ethernet : IP : OSPF. Given that, it's easy to place SMTP in the application layer because it uses the underlying TCP transport layer which uses the underlying IP layer, etc. Considering the SMTP and OSPF packets, by analogy, OSPF might operate at the transport layer but that doesn't make sense because it is not used by higher layers to transport anything. Layering in TCP/IP actually operates as shown in the diagram. I've forgotten quite a lot about OSPF but I believe one OSPF router talks only to an OSPF router at the bottom layer of that diagram. Johnuniq (talk) 06:24, 3 November 2021 (UTC)

Sometimes there are several holes that can reasonably house the pigeon, but sometimes the hole really is not fit for the pigeon :) . "OSPF might operate at the transport layer but that doesn't make sense because it is not used by higher layers to transport anything" I absolutely agree, and I was not suggesting to put OSPF at the transport layer. In fact, a similar reasoning will show that putting OSPF in the link layer doesn't make sense either! For the purpose of running routing protocols, IP routers function as hosts, and routing protocol involve exchanges between processes running in the routers (running in what would be control plane in modern routers; or a user-space process if you're running 4.2BSD). Tavositar (talk) 23:29, 3 November 2021 (UTC)

I made the the change I mentioned, and also added some words to Internet_protocol_suite#Comparison_of_TCP/IP_and_OSI_layering about how one RFC put routing protocols in the application layer, but OSI put ISIS in the network layer and Tanenbaum in the network layer of his 5-layer model. Tavositar (talk) 21:30, 7 November 2021 (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)

DHCPv6

@Kbrose: Why shouldn't DHCPv6 be listed, while NDP and even ICMPv6 are. Also, there would be just 4 additional characters: (v6) - Piulin (talk) 12:41, 6 May 2021 (UTC)

DHCPv6 SHOULD be listed 2603:6000:B000:29A2:70F3:FDA:377D:704C (talk) 03:09, 31 December 2023 (UTC)

ARP belongs to link layer??

@Kbrose: You reverted my edit that moved ARP from the link layer to the internet layer. How is ARP supposed to belong to the link layer? Of course, it uses the link layer but it isn't part of it (in doubt, please refer to RFC 1122 for the definition of the link layer). ARP provides the glue for the IPv4 network layer to use a MAC-based link layer. As such, it is part of the interface to the link layer and an integral part of the network layer. --Zac67 (talk) 08:08, 21 December 2021 (UTC)

1122 is pretty clear about that, and ARP never traverses routers, which really is the defining criterion. ARP stays on the LINK. TCP/IP layers don't have "interfaces" and they are not "used". they are just realms or scopes. "Network layer" is not a term of TCP/IP, it is the Internet Layer, for "internetworking", because this is where networks are interconnected, and routers are traversed. This is also why OSPF belong to the link, despite the many wrong ideas that think otherwise. kbrose (talk) 14:16, 21 December 2021 (UTC)

The Link Layer presentation in this template has always been problematic, because it lumps things in there, that strictly are not part of TCP/IP, e.g. Ethernet, WiFi, etc. kbrose (talk) 14:20, 21 December 2021 (UTC)

RFC 1122 does not put ARP in any layer. It's listed under LL since it's a mechanism required to handle MAC-based LL variants. Not being routed isn't a criterion for belonging to the LL. The criterion is what kind of service a protocol provides. ARP is integral to IPv4, so it belongs to the internet layer, just like ICMP.

And of course layers have interfaces to the upper and lower layers (where applicable) and higher layers utilize or use lower layers for transport (e.g. HTTP uses TCP which uses IP which uses Ethernet) – incidentally, this is in RFC 1122 as well, literally. And btw, OSPF is an application-layer protocol. --Zac67 (talk) 21:03, 21 December 2021 (UTC)

Not true, these are ideas of the OSI model, not TCP/IP. The IETF community did not put much value in these structured ideas. kbrose (talk) 01:59, 22 December 2021 (UTC)

The TCP/IP model does use distinctive layering, the IETF just don't define the layer for every single protocol. If we can't put ARP (and NDP) into the internet layer (the way you put it we're lacking WP:RS), then we should at least remove them from the link layer, where they are definitely wrong. --Zac67 (talk) 08:30, 22 December 2021 (UTC)

Search for "Pigeonholes are not always easily defined" above to see how it is reasonable to think otherwise. Johnuniq (talk) 22:22, 21 December 2021 (UTC)

Thanks, that confirms my point. But I wasn't going by encapsulation, I'm going by functionality. Not even ARP's encapsulation by the link layer puts it within the same but above. --Zac67 (talk) 08:30, 22 December 2021 (UTC)

If you remove ARP from the Link Layer, the layer is essentially empty. In TCP/IP it just provides the link to the hardware, which is not a concern of TCP/IP. Ethernet aspects are covered in 1122, due to the nature of ARP, but TCP/IP really just assumes some functioning wire. The whole of layering is pretty loose, and this was always the case in TCP/IP. It was not a design guide, or goal for teaching. It was recognized that modularity and some structural design were useful, but rigid specifications were an obstacle to success. OSI proved that to a tee, when most (all?) initial implementations failed in interoperability, and it prevented OSI from becoming the standard of the Internet in the early 90s because the market place could not wait, despite almost everyone's expectations. To pick it apart three, four decades later is mood, and the IETF has never done so. You can use the OSI model if you want to argue about those details. 1122 is one of the few primary guides for layering in TCP/IP and it lists ARP in the Link Layer. There was a layering RFC later, but it was not a specification. It is not about functionality, interfaces, encapsulation, or what, but about networking scope. The layer names tell us that too, because the second layer is called "Internet", meaning more than one network, interconnected, larger than one link. Transport is the scope between hosts, anywhere, just hosts. ARP stays on the link. NDP has some mixed functionality too, yet the RFCs have Link Layer all over them. OSPF is truly a tricky one, v4 talks about subnets, but v6 does not, and in the end they both stays on the link too, informing the routers. Putting them into the application layer is a cop-out, perhaps not all bad, but not on the basis that all routing protocols belong there (ask OSI what they think!). It comprises almost anything without clear scope, but the common abstraction seems to be the process. kbrose (talk) 16:27, 22 December 2021 (UTC)

We don't need any other reference than RFC 1122 to place ARP into the Link Layer. This does not need reinterpretation. This is the way the designers wanted it:

Link Layer
              To communicate on its directly-connected network, a host
              must implement the communication protocol used to
              interface to that network. We call this a link layer or
              media-access layer protocol.
              There is a wide variety of link layer protocols,
              corresponding to the many different types of networks.
              See Chapter 2.

Chapter 2 provides a "walk-through" (their term!) of the protocols of the Link Layer. By this, we can argue that parts of Ethernet, ISDN, etc should get listed, or just the concepts. I think this was the original idea of listing those there, to provide the context to hardware.

My reason for me not moving OSPF back to the Link Layer, despite its limited scope as a network protocol, was that it is not directly a hardware-oriented protocol, but runs as a process on a host, just not using a transport protocol, but simply informing the IP layer of available links for routing and their metrics. This perhaps helps accommodating readers who object of a link layer protocol knowing about IP addresses. kbrose (talk) 16:51, 22 December 2021 (UTC)

With all respect, If you remove ARP from the Link Layer, the layer is essentially empty. shows a serious misunderstanding of layering. All of IEEE 802 is about the link layer (or in OSI terms, the physical and the data link layers). In TCP/IP it just provides the link to the hardware, which is not a concern of TCP/IP. pretty much so - but ARP is a part of TCP/IP, isn't it? TCP/IP really just assumes some functioning wire – there's more to it than a wire and that's even detailed in RFC 1122. I fail to get your reference to OSI as I wasn't talking about that (although OSI's layer 1+2 are pretty much the same as TCP/IP's link layer). RFC 1122 [...] lists ARP in the Link Layer – no, it does not. That RFC explains ARP within the link layer chapter as it's vital to working with it. The RFC says nowhere that ARP is part of the link layer. Check out the description of the link layer's functionality and you see that ARP doesn't fit anywhere. Link layer networks are Ethernet, IEEE 802.11, ARCNET, Token Ring, ISDN, ATM, PPP, ... Where is ARP's place in that? the second layer is called "Internet", meaning more than one network, interconnected, larger than one link is your interpretation, no quote. Regarding NDP, would you be so kind and point me to an RFC that says it's part of the link layer? Once again, if there's no consense for ARP belonging to any specific layer, we should remove at least it from the template (same with NDP unless that promised RFC shows up). --Zac67 (talk) 19:49, 22 December 2021 (UTC)

RFC 1122 by its own statements provides a walk through the protocols of the time for each layer. ARP is discussed in the Link Layer. That's where they wanted it. It fits perfectly because it operates only on the Link and it provides a tool for access the MAC system of Ethernet. What other interpretations are needed? kbrose (talk) 20:04, 22 December 2021 (UTC)

Hello, in fact, there is no clear mention in RFC 1122 regarding where ARP resides in the protocol stack. In RFC 1180 (P.5), ARP is shown in-between IP and Ethernet, with the following statement on page 4: "If an Ethernet frame comes up into the Ethernet driver off the network, the packet can be passed upwards to either the ARP (Address Resolution Protocol) module or to the IP (Internet Protocol) module. The value of the Type field in the Ethernet frame determines whether the Ethernet frame is passed to the ARP or the IP module"

In addition, RFC 826 (ARP standard), mentions nothing related to protocol stack, which is normal to an RFC that old. In the RFC the word packet is used with protocol, which means in today's language L3 PDU (protocol data unit), this meaning was not used at that time, for example, what we called an IP packet today was simply called datagram (RFC 791: IPv4 standard).

If we look at the encapsulation of the headers, the ARP header comes after the L2 header, and there is no L3 header (no IPv4 header). From my point of view, if the protocol can access the IP header without passing through encapsulation, it, for sure, resides within the same layer.

NDP clearly resides at Layer 3, because it uses ICMPv6 messages, and "ICMPv6 is an integral part of IPv6" (RFC 4443, P. 3).

Please tag me to have a notification because I am not active in English Wikipedia.--Michel Bakni (talk) 22:57, 22 December 2021 (UTC)

OSPF can not be moved to link-layer because it is, at least, above the IP which resides in the internet layer, the value 89 is reserved for OSPF in the Protocol field in the IPv4 header (Check IANA registry).--Michel Bakni (talk) 23:06, 22 December 2021 (UTC)

Protocol encapsulation sequence is not a feature of TCP/IP. You are confused by OSI. Forget OSI if you want to be correct about TCP/IP. L2 and L3 are not TCP/IP terms either. Whether NDP is a part of the ICMP spec has no bearing on layering, similar with OSPF. The TCP/IP architects never intended such strict interface hierarchy. kbrose (talk) 23:12, 22 December 2021 (UTC)

I think you are mistaken, please check the use of the word "encapsulation" in RFC 1122, the concept does exist and is widely adopted in TCO/IP protocols. I do not understand this sentences "NDP is a part of the ICMP spec has no bearing on layering". If NDP uses ICMPv6 messages structures, this means its messages will be treated as ICMPv6 messages, ICMPv6 is an integral part of IPv6, and thus, NDP is also.--Michel Bakni (talk) 08:15, 23 December 2021 (UTC)

ICMPv6 is not an integral part of the Internet Protocol version 6, but is a part of the IPv6 suite of protocols. The IPv6 specifications are not a monolithic entity, but a group of protocols that expand or improve on the concepts of the TCP/IP protocol suite. Same applies to NDP, it is distinct protocol within the IPv6 group, this does in no way imply a certain layer level. kbrose (talk) 19:53, 23 December 2021 (UTC)

Of course, TCP/IP uses encapsulation, and an Ethernet frame can only be encapsulate by IP, for example, not the other way around. But this does not impose direct limitation on layer association. A particular layer has no fixed encapsulation sequence. E.g., OSPF encapsulates on top of IP, yet no one (hopefully) places it into the Transport Layer. I say again, forget OSI when writing about TCP/IP. Why is this so hard? Why can't you discuss TCP/IP using only its own concepts and definitions? kbrose (talk) 19:23, 23 December 2021 (UTC)

NDP

Shall I quote RFC 1970 which defines NDP?

• Abstract: IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.
• In section 2.2: (Link Types) Different link layers have different properties. The ones of concern to Neighbor Discovery are: and they are listed.
• Section 6.2.1: This rule simplifies the configuration of Neighbor Discovery over link types with widely differing performance characteristics.

kbrose (talk) 20:14, 23 December 2021 (UTC)

@Kbrose: You entirely miss the point. Your quotes show that ARP runs on top of the link layer, not that it's part of the link layer, what this discussion is about.

• ARP is discussed in the Link Layer. — Yes, it is because it's IPv4's essential interface with the link layer. There's no word that it is part of the link layer.
• Protocol encapsulation sequence is not a feature of TCP/IP. — While I don't use encapsulation for arguing (I could but it is sometimes misleading, see PPPoE), you are clearly mistaken. IP encapsulates in link-layer frames. TCP encapsulates in IP. Also, check numerous RFCs about encapsulation; I don't think I need to provide a list.
• The TCP/IP architects never intended such strict interface hierarchy. — That is correct to some extent. I was agreeing to removing ARP (and NDP) from the link-layer section when layers are somewhat ill-defined. However, you can't lean your illogic argument on a source that doesn't define a strict hierarchy, your own words.
• ICMPv6 is not an integral part of the Internet Protocol version 6 shows you lack of understanding again. It is.
• Ethernet frame can only be encapsulate by IP, for example, not the other way around — not the point here, but with tunneling, any encapsulation is possible (not by OSI but in practice).
• Your quotes to NDP are irrelevant and NDP's place in the internet layer isn't even disputed properly.

Your arguments continue to prove that ARP runs on top of the link layer, so very obviously it can't be part of it. As a compromise (again), let's remove ARP from the link-layer section when there is no consent and sources are ambiguous (for me they're not). As it is, there are two editors for ARP in the network layer and only one for the link layer. And please don't WP:EDITWAR when sources are requested for dubious claims. --Zac67 (talk) 08:11, 24 December 2021 (UTC)

I do agree with Zac67, if you can handle different link protocols, you are on the top of the layer and not a part of it, this is simply the layering concept.--Michel Bakni (talk) 11:35, 24 December 2021 (UTC)

@Kbrose:, please be reasonable, you are denying a clear statement in the ICMPv6 RFC.

your words: ICMPv6 is not an integral part of the Internet Protocol version 6

ICMPv6 creator: "ICMPv6 is an integral part of IPv6, and the base protocol (all the messages and behavior required by this specification) MUST be fully implemented by every IPv6 node." (RFC 4443, p. 3)--Michel Bakni (talk) 11:42, 24 December 2021 (UTC)

ICMPv6 is a part of the IPv6 specification, but not of the Internet Protocol (v6). It is not the same protocol. The IPv6 specification comprises a suite of protocols, only one of the is Internet Protocol Version 6. This is pure word splitting. What other word than run over would they use when stating multiple link types. Media access control runs on top of the hardware of the link, but TCP/IP does not concern itself with that. Therefore ARP runs in layer one of TCP/IP. It cannot be routed and therefore does not run in the Internet layer. kbrose (talk) 19:13, 24 December 2021 (UTC)

Neither?

So because it's controversial and we can't decide where to put it, now it's not in this template at all? That seems like a classic worst-of-both-worlds compromise, for a protocol as important as ARP! —scs (talk) 22:12, 21 April 2023 (UTC)

Re-added

I have re-added ARP, placing it at the Internet layer. I don't care so much where it goes, as long as it's listed. To my mind, it belongs wherever NDP is, since they're analogous. But:

I don't believe we have to get the placement exactly right. I believe this template's primary purpose is to list the primary Internet protocols, and ARP is certainly one of those. I don't believe this template has a mandate to definitively categorize protocols as to layer.

The impossibility of categorizing ARP perfectly is not, I believe, a reason to banish it from this template.

If it's unacceptable to list ARP here but to have it categorized imperfectly, I believe we have two options:

• put an asterisk next to it, with a footnote that it's not actually a part of whatever level we put it in, or
• create an actual "level 2.5" heading to put it and NDP in.

But, again, leaving it out entirely is not an option. ARP is undeniably a core Internet protocol, and it belongs in this template. —scs (talk) 21:50, 17 June 2023 (UTC)

Requested move 20 January 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: page moved. (non-admin closure) Steel1943 (talk) 20:19, 29 January 2022 (UTC)

---

Template:IPstack → Template:Internet protocol suite – Templates should (and generally are) named by what they are (i.e. a meaningful title in clear, non-obfuscated English). Redirects allow the use of shortcuts for editors who cannot remember (or don't want to type) the full name of the template—like {{Cn}} redirects to {{Citation needed}}, for instance. I tried fixing this but was reverted. Additionally, Rich Farmbrough attempted to at least add a space between the words "IP" and "stack" twice, back in 2010 and 2011. All three attempts to improve the clarity of the title were promptly reverted by an apparent owner (just look at the history) with the reasons all being similar to "not necessary". This is classic owner behavior #3, and I find that kind of thing to be extremely detrimental to the forward progress of this collaborative project. Again, a redirect results from the move, so the whole "name...is short and easy to use" argument is moot. "Name has been stable for a long time" is owner behavior #2.

I propose that we move this to {{Internet protocol suite}} because that is the title heading given at the top of the template itself as well as the common name used by the main article on this subject. Furthermore, most of the TCP/IP stack (as it is more commonly called than "IPstack") is built on top of IP and not part of that protocol itself. — voidxor 20:29, 20 January 2022 (UTC)

Entirely agree. --Zac67 (talk) 07:17, 21 January 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.