Template talk:IPstack

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking (Rated Template-class)
WikiProject icon This template is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
Taskforce icon
This template is supported by Networking task force.
 


Contents

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

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

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

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

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

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

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

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

[edit] LDAP

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

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

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

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

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

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

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