Privacy Policy Cookie Policy Terms and Conditions Template talk:IPstack - Wikipedia, the free encyclopedia

Template talk:IPstack

From Wikipedia, the free encyclopedia

"Bus" network topology This article is part of WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.


Contents

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

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

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

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

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

[edit] Physical layer

Why are only largely oblsoete 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)

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

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

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

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

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

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

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

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

[edit] 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-prioprietary 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)

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

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

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

THIS WEB:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2006:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu