Internet protocol suite: Difference between revisions

Revision as of 05:01, 12 July 2025

Revision as of 12:19, 13 July 2025

Line 25:

Initially, the Transmission Control Program, the precursor to the later protocol suite, provided only a [[reliable byte stream]] service, not [[datagram]]s.<ref name="TCP2">{{Cite web|url=https://www.rfc-editor.org/ien/ien5.pdf|title=Specification of Internet Transmission Control Protocol TCP (Version 2)|first=Vinton|last=Cerf|author-link=Vint Cerf|date=March 1977|access-date=2022-08-04|archive-date=May 25, 2022|archive-url=https://web.archive.org/web/20220525061950/https://www.rfc-editor.org/ien/ien5.pdf|url-status=live}}</ref> Several versions were developed by communication via the [[Internet Experiment Note]] series.<ref name=":30" /> As experience with the protocol grew, collaborators recommended division of functionality into layers of distinct protocols, providing direct access to datagram service. Advocates included [[Bob Metcalfe]] and Yogen Dalal at Xerox PARC;<ref name="BpyJd">{{cite book |last1=Panzaris |first1=Georgios |url=https://books.google.com/books?id=9yMhAQAAIAAJ |title=Machines and romances: the technical and narrative construction of networked computing as a general-purpose platform, 1960–1995 |date=2008 |publisher=[[Stanford University]] |page=128 |access-date=September 5, 2019 |archive-url=https://web.archive.org/web/20230117175134/https://books.google.com/books?id=9yMhAQAAIAAJ |archive-date=January 17, 2023 |url-status=live}}</ref><ref name="2J9cz">{{cite book |last1=Pelkey |first1=James L. |url=https://historyofcomputercommunications.info/ |title=Entrepreneurial Capitalism and Innovation: A History of Computer Communications, 1968–1988 |date=2007 |chapter=Yogen Dalal |access-date=8 October 2020 |chapter-url=https://historyofcomputercommunications.info/interviews/yogen-dalal/ |archive-url=https://web.archive.org/web/20221008232443/https://historyofcomputercommunications.info/ |archive-date=October 8, 2022 |url-status=live}}</ref> [[Danny Cohen (computer scientist)|Danny Cohen]], who needed it for his [[packet voice]] work; and [[Jonathan Postel]] of the University of Southern California's [[Information Sciences Institute]], who edited the [[Request for Comments]] (RFCs), the technical and strategic document series that has both documented and catalyzed Internet development.<ref name="i1TtW">Internet Hall of Fame</ref> Postel stated, "We are screwing up in our design of Internet protocols by violating the principle of layering."<ref name="xgruR">{{citation|url=https://www.rfc-editor.org/ien/ien2.txt|first=Jon|last=Postel|author-link=Jon Postel|title=2.3.3.2 Comments on Internet Protocol and TCP|id=IEN 2|date=15 August 1977|access-date=June 11, 2016|archive-date=May 16, 2019|archive-url=https://web.archive.org/web/20190516055704/http://www.rfc-editor.org/ien/ien2.txt|url-status=live}}</ref> Encapsulation of different mechanisms was intended to create an environment where the upper layers could access only what was needed from the lower layers. A monolithic design would be inflexible and lead to scalability issues. In [[IPv4|version 4]], written in 1978, Postel split the Transmission Control Program into two distinct protocols, the [[Internet Protocol]] as connectionless layer and the [[Transmission Control Protocol]] as a reliable [[connection-oriented service]].<ref>Abbate, ''Inventing the Internet'', 129–30.</ref><ref>{{cite journal |author=Vinton G. Cerf |date=October 1980 |title=Protocols for Interconnected Packet Networks |journal=ACM SIGCOMM Computer Communication Review |volume=10 |issue=4 |pages=10–11 |authorlink=Vint Cerf}}</ref><ref>{{Cite thesis |last=Russell |first=Andrew L. |title="Industrial Legislatures": Consensus Standardization in the Second and Third Industrial Revolutions |date=2007 |degree=PhD |publisher=Johns Hopkins University |url=https://jscholarship.library.jhu.edu/bitstream/handle/1774.2/32576/alr-diss-08012007-CBO-opt.pdf |access-date=December 28, 2022 |archive-date=December 28, 2022 |archive-url=https://web.archive.org/web/20221228000055/https://jscholarship.library.jhu.edu/bitstream/handle/1774.2/32576/alr-diss-08012007-CBO-opt.pdf |url-status=live }}</ref><ref group ="nb">For records of discussions leading up to the TCP/IP split, see the series of [[Internet Experiment Notes]] at [https://www.rfc-editor.org/ien/ien-index.html the Internet Experiment Notes Index].</ref>

The design of the network included the recognition that it should provide only the functions of efficiently transmitting and routing traffic between end nodes and that all other intelligence should be located at the edge of the network, in the end nodes. This [[end-to-end principle]] was pioneered by Louis Pouzin in the CYCLADES network,<ref name="Bennett2009">{{cite web |last1=Bennett |first1=Richard |date=September 2009 |title=Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate |url=https://www.itif.org/files/2009-designed-for-change.pdf |access-date=11 September 2017 |publisher=Information Technology and Innovation Foundation |pages=7, 11}}</ref> based on the ideas of [[Donald Davies]].<ref name="Pelkey2">{{cite book |last=Pelkey |first=James |url=https://www.historyofcomputercommunications.info/section/8.3/cyclades-network-and-louis-pouzin-1971-1972/ |title=Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988 |chapter=8.3 CYCLADES Network and Louis Pouzin 1971-1972 |quote=The inspiration for datagrams had two sources. One was Donald Davies’ studies. He had done some simulation of datagram networks, although he had not built any, and it looked technically viable. The second inspiration was I like things simple. I didn’t see any real technical motivation to overlay two levels of end-to-end protocols. I thought one was enough. |access-date=2021-11-21 |archive-url=https://web.archive.org/web/20210617093154/https://www.historyofcomputercommunications.info/section/8.3/cyclades-network-and-louis-pouzin-1971-1972/ |archive-date=2021-06-17 |url-status=dead}}</ref><ref name=":5">{{cite conference |last1=Davies |first1=Donald |last2=Bartlett |first2=Keith |last3=Scantlebury |first3=Roger |last4=Wilkinson |first4=Peter |date=October 1967 |title=A Digital Communication Network for Computers Giving Rapid Response at remote Terminals |url=https://people.mpi-sws.org/~gummadi/teaching/sp07/sys_seminar/how_did_erope_blow_this_vision.pdf |conference=ACM Symposium on Operating Systems Principles |archive-url=https://ghostarchive.org/archive/20221010/https://people.mpi-sws.org/~gummadi/teaching/sp07/sys_seminar/how_did_erope_blow_this_vision.pdf |archive-date=2022-10-10 |access-date=2020-09-15 |url-status=live |quote=all users of the network will provide themselves with some kind of error control}}</ref> Using this design, it became possible to connect other networks to the ARPANET that used the same principle, irrespective of other local characteristics, thereby solving Kahn's initial internetworking problem. A popular expression is that TCP/IP, the eventual product of Cerf and Kahn's work, can run over "two tin cans and a string."<ref>{{citationCite web needed|reasontitle=IInternet canProtocol onlySuite find possibly circular references for this phrase|url=https://www.networxsecurity.org/members-area/glossary/i/internet-protocol-suite.html#:~:text=One%20popular%20expression%20is%20that,was%20created%20and%20successfully%20tested.) |access-date=November2025-07-13 2017|website=www.networxsecurity.org}}</ref> Years later, as a [[April Fools' Day|joke]] in 1999, the [[IP over Avian Carriers]] formal protocol specification was created{{Ref RFC|1149}} and successfully tested two years later. 10 years later still, it was adapted for IPv6.{{Ref RFC|6214}}

DARPA contracted with [[BBN Technologies]], [[Stanford University]], and the [[University College London]] to develop operational versions of the protocol on several hardware platforms.<ref name="IjTdeF">{{cite web |author1=by Vinton Cerf, as told to Bernard Aboba |date=1993 |title=How the Internet Came to Be |url=http://elk.informatik.hs-augsburg.de/tmp/cdrom-oss/CerfHowInternetCame2B.html |url-status=dead |archive-url=https://web.archive.org/web/20170926042220/http://elk.informatik.hs-augsburg.de/tmp/cdrom-oss/CerfHowInternetCame2B.html |archive-date=26 September 2017 |access-date=25 September 2017 |quote=We began doing concurrent implementations at Stanford, BBN, and University College London. So effort at developing the Internet protocols was international from the beginning.}}</ref> During development of the protocol the version number of the packet routing layer progressed from version 1 to version 4, the latter of which was installed in the ARPANET in 1983. It became known as ''[[Internet Protocol version 4]]'' (IPv4) as the protocol that is still in use in the Internet, alongside its current successor, [[Internet Protocol version 6]] (IPv6).

Line 118:

At the application layer, the TCP/IP model distinguishes between ''user protocols'' and ''support protocols''.{{Ref RFC|1122|rsection=1.1.3}} Support protocols provide services to a system of network infrastructure. User protocols are used for actual user applications. For example, FTP is a user protocol and DNS is a support protocol.

Although the applications are usually aware of key qualities of the transport layer connection such as the endpoint IP addresses and port numbers, application layer protocols generally treat the transport layer (and lower) protocols as [[black box]]es which provide a stable network connection across which to communicate. The transport layer and lower-level layers are unconcerned with the specifics of application layer protocols. Routers and [[network switch|switches]] do not typically examine the encapsulated traffic, rather they just provide a conduit for it. However, some [[Firewall (computing)|firewall]] and [[bandwidth throttling]] applications use [[deep packet inspection]] to interpret application data. An example is the [[Resource Reservation Protocol]] (RSVP).<ref>{{citationCite web needed|last=Team |first=I. R. |title=A Breakdown of Deep Packet Inspection & How It Works I IR |url=https://www.ir.com/guides/deep-packet-inspection |access-date=May2025-07-13 2021|website=www.ir.com |language=en}}</ref> It is also sometimes necessary for [[Network address translation#Applications affected by NAT|Applications affected by NAT]] to consider the application payload.

==Layering evolution and representations in the literature==

Line 206:

The three top layers in the OSI model, i.e. the application layer, the presentation layer and the session layer, are not distinguished separately in the TCP/IP model which only has an application layer above the transport layer. While some pure OSI protocol applications, such as [[X.400]], also combined them, there is no requirement that a TCP/IP protocol stack must impose monolithic architecture above the transport layer. For example, the NFS application protocol runs over the [[External Data Representation]] (XDR) presentation protocol, which, in turn, runs over a protocol called [[Remote Procedure Call]] (RPC). RPC provides reliable record transmission, so it can safely use the best-effort UDP transport.

Different authors have interpreted the TCP/IP model differently, and disagree whether the link layer, or any aspect of the TCP/IP model, covers OSI layer 1 ([[physical layer]]) issues, or whether TCP/IP assumes a hardware layer exists below the link layer. Several authors have attempted to incorporate the OSI model's layers 1 and 2 into the TCP/IP model since these are commonly referred to in modern standards (for example, by [[IEEE]] and [[ITU]]). This often results in a model with five layers, where the link layer or network access layer is split into the OSI model's layers 1 and 2.<ref>{{cnCite web |last=Murray |first=Nick |date=September2018-11-28 2024|title=Network Layers Explained: OSI & TCP/IP Models [with examples] |url=https://www.plixer.com/blog/network-layers-explained/ |access-date=2025-07-13 |website=Plixer |language=en-US}}</ref>

The IETF protocol development effort is not concerned with strict layering. Some of its protocols may not fit cleanly into the OSI model, although RFCs sometimes refer to it and often use the old OSI layer numbers. The IETF has repeatedly stated<ref name="introduction-to-the-ietf" />{{failed verification|date=April 2024}} that Internet Protocol and architecture development is not intended to be OSI-compliant. RFC 3439, referring to the internet architecture, contains a section entitled: "Layering Considered Harmful".{{ref RFC|3439}}