   Link: manifest
   Link: license
   Link: canonical
   [ ] Open main menu
     * Home
     * Random
     * Nearby
     * Log in
     * Donate
     * About Wikipedia
     * Disclaimers
   Wikipedia
   _____________________
   Search

                            Internet protocol suite

   Article Talk
     * Language
     * Watch
     * Edit

   This article is about the protocols that make up the Internet
   architecture. For the IP network protocol only, see Internet Protocol.

   The Internet protocol suite, commonly known as TCP/IP, is the set of
   communications protocols used in the Internet and similar computer
   networks. The current foundational protocols in the suite are the
   Transmission Control Protocol (TCP) and the Internet Protocol (IP), as
   well as the User Datagram Protocol (UDP).

   During its development, versions of it were known as the Department of
   Defense (DoD) model because the development of the networking method was
   funded by the United States Department of Defense through DARPA. Its
   implementation is a protocol stack.^[1]

   The Internet protocol suite provides end-to-end data communication
   specifying how data should be packetized, addressed, transmitted, routed,
   and received. This functionality is organized into four abstraction
   layers, which classify all related protocols according to each protocol's
   scope of networking.^[2]^[3] From lowest to highest, the layers are the
   link layer, containing communication methods for data that remains within
   a single network segment (link); the internet layer, providing
   internetworking between independent networks; the transport layer,
   handling host-to-host communication; and the application layer, providing
   process-to-process data exchange for applications.

   The technical standards underlying the Internet protocol suite and its
   constituent protocols are maintained by the Internet Engineering Task
   Force (IETF). The Internet protocol suite predates the OSI model, a more
   comprehensive reference framework for general networking systems.

Contents

     * 1 History
          * 1.1 Early research
          * 1.2 Early implementation
          * 1.3 Adoption
          * 1.4 Formal specification and standards
     * 2 Key architectural principles
     * 3 Link layer
     * 4 Internet layer
     * 5 Transport layer
     * 6 Application layer
     * 7 Layer names and number of layers in the literature
     * 8 Comparison of TCP/IP and OSI layering
     * 9 Implementations
     * 10 See also
     * 11 References
     * 12 Bibliography
     * 13 External links

HistoryEdit

   Link: mw-deduplicated-inline-style
   Further information: History of the Internet

  Early researchEdit

   [IMG] 
   Enlarge
   Diagram of the first internetworked connection
   [IMG] 
   Enlarge
   An SRI International Packet Radio Van, used for the first three-way
   internetworked transmission.

   The Internet protocol suite resulted from research and development
   conducted by the Defense Advanced Research Projects Agency (DARPA) in the
   late 1960s.^[1] After initiating the pioneering ARPANET in 1969, DARPA
   started work on a number of other data transmission technologies. In 1972,
   Robert E. Kahn joined the DARPA Information Processing Technology Office,
   where he worked on both satellite packet networks and ground-based radio
   packet networks, and recognized the value of being able to communicate
   across both. In the spring of 1973, Vinton Cerf, who helped develop the
   existing ARPANET Network Control Program (NCP) protocol, joined Kahn to
   work on open-architecture interconnection models with the goal of
   designing the next protocol generation for the ARPANET.^[citation needed]
   They drew on the experience from the ARPANET research community and the
   International Networking Working Group, which Cerf chaired.^[4]

   By the summer of 1973, Kahn and Cerf had worked out a fundamental
   reformulation, in which the differences between local network protocols
   were hidden by using a common internetwork protocol, and, instead of the
   network being responsible for reliability, as in the existing ARPANET
   protocols, this function was delegated to the hosts. Cerf credits Hubert
   Zimmermann and Louis Pouzin, designer of the CYCLADES network, with
   important influences on this design.^[5]^[6] The new protocol was
   implemented as the Transmission Control Program in 1974.^[7]

   Initially, the Transmission Control Program managed both datagram
   transmissions and routing, but as experience with the protocol grew,
   collaborators recommended division of functionality into layers of
   distinct protocols. Advocates included 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,^[8] and the
   research group of Robert Metcalfe at Xerox PARC.^[9]^[10] Postel stated,
   "We are screwing up in our design of Internet protocols by violating the
   principle of layering."^[11] 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 version 3 of TCP, written in
   1978, the Transmission Control Program was split into two distinct
   protocols, the Internet Protocol as connectionless layer and the
   Transmission Control Protocol as a reliable connection-oriented
   service.^[12]

   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 design is known as the end-to-end
   principle. 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."^[citation needed] Years
   later, as a joke, the IP over Avian Carriers formal protocol specification
   was created and successfully tested.

   DARPA contracted with BBN Technologies, Stanford University, and the
   University College London to develop operational versions of the protocol
   on several hardware platforms.^[13] 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).

  Early implementationEdit

   In 1975, a two-network IP communications test was performed between
   Stanford and University College London. In November 1977, a three-network
   IP test was conducted between sites in the US, the UK, and Norway. Several
   other IP prototypes were developed at multiple research centers between
   1978 and 1983. Before the January 1, 1983 "Flag Day", the Internet used
   NCP instead of TCP as the transport layer protocol.

   A computer called a router is provided with an interface to each network.
   It forwards network packets back and forth between them.^[14] Originally a
   router was called gateway, but the term was changed to avoid confusion
   with other types of gateways.^[15]

  AdoptionEdit

   In March 1982, the US Department of Defense declared TCP/IP as the
   standard for all military computer networking.^[16] In the same year,
   NORSAR and Peter Kirstein's research group at University College London
   adopted the protocol.^[13]^[17]^[18] The migration of the ARPANET to
   TCP/IP was officially completed on flag day January 1, 1983, when the new
   protocols were permanently activated.^[19]

   In 1985, the Internet Advisory Board (later Internet Architecture Board)
   held a three-day TCP/IP workshop for the computer industry, attended by
   250 vendor representatives, promoting the protocol and leading to its
   increasing commercial use. In 1985, the first Interop conference focused
   on network interoperability by broader adoption of TCP/IP. The conference
   was founded by Dan Lynch, an early Internet activist. From the beginning,
   large corporations, such as IBM and DEC, attended the meeting.^[20]

   IBM, AT&T and DEC were the first major corporations to adopt TCP/IP, this
   despite having competing proprietary protocols. In IBM, from 1984, Barry
   Appelman's group did TCP/IP development. They navigated the corporate
   politics to get a stream of TCP/IP products for various IBM systems,
   including MVS, VM, and OS/2. At the same time, several smaller companies,
   such as FTP Software and the Wollongong Group, began offering TCP/IP
   stacks for DOS and Microsoft Windows.^[21] The first VM/CMS TCP/IP stack
   came from the University of Wisconsin.^[22]

   Some of the early TCP/IP stacks were written single-handedly by a few
   programmers. Jay Elinsky and Oleg Vishnepolsky [ru] of IBM Research wrote
   TCP/IP stacks for VM/CMS and OS/2, respectively.^[citation needed] In 1984
   Donald Gillies at MIT wrote a ntcp multi-connection TCP which runs atop
   the IP/PacketDriver layer maintained by John Romkey at MIT in 1983–4.
   Romkey leveraged this TCP in 1986 when FTP Software was founded.^[23]^[24]
   Starting in 1985, Phil Karn created a multi-connection TCP application for
   ham radio systems (KA9Q TCP).^[25]

   The spread of TCP/IP was fueled further in June 1989, when the University
   of California, Berkeley agreed to place the TCP/IP code developed for BSD
   UNIX into the public domain. Various corporate vendors, including IBM,
   included this code in commercial TCP/IP software releases. Microsoft
   released a native TCP/IP stack in Windows 95. This event helped cement
   TCP/IP's dominance over other protocols on Microsoft-based networks, which
   included IBM's Systems Network Architecture (SNA), and on other platforms
   such as Digital Equipment Corporation's DECnet, Open Systems
   Interconnection (OSI), and Xerox Network Systems (XNS).

   Nonetheless, for a period in the late 1980s and early 1990s, engineers,
   organizations and nations were polarized over the issue of which standard,
   the OSI model or the Internet protocol suite, would result in the best and
   most robust computer networks.^[26]^[27]^[28]

  Formal specification and standardsEdit

   The technical standards underlying the Internet protocol suite and its
   constituent protocols have been delegated to the Internet Engineering Task
   Force (IETF).

   The characteristic architecture of the Internet Protocol Suite is its
   broad division into operating scopes for the protocols that constitute its
   core functionality. The defining specification of the suite is RFC 1122,
   which broadly outlines four abstraction layers.^[2] These have stood the
   test of time, as the IETF has never modified this structure. As such a
   model of networking, the Internet Protocol Suite predates the OSI model, a
   more comprehensive reference framework for general networking
   systems.^[28]

Key architectural principlesEdit

   Link: mw-deduplicated-inline-style
   See also: Communication protocol § Software layering
   [IMG] 
   Enlarge
   Conceptual data flow in a simple network topology of two hosts (A and B)
   connected by a link between their respective routers. The application on
   each host executes read and write operations as if the processes were
   directly connected to each other by some kind of data pipe. After
   establishment of this pipe, most details of the communication are hidden
   from each process, as the underlying principles of communication are
   implemented in the lower protocol layers. In analogy, at the transport
   layer the communication appears as host-to-host, without knowledge of the
   application data structures and the connecting routers, while at the
   internetworking layer, individual network boundaries are traversed at each
   router.
   [IMG] 
   Enlarge
   Encapsulation of application data descending through the layers described
   in RFC 1122

   The end-to-end principle has evolved over time. Its original expression
   put the maintenance of state and overall intelligence at the edges, and
   assumed the Internet that connected the edges retained no state and
   concentrated on speed and simplicity. Real-world needs for firewalls,
   network address translators, web content caches and the like have forced
   changes in this principle.^[29]

   The robustness principle states: "In general, an implementation must be
   conservative in its sending behavior, and liberal in its receiving
   behavior. That is, it must be careful to send well-formed datagrams, but
   must accept any datagram that it can interpret (e.g., not object to
   technical errors where the meaning is still clear)."^[30] "The second part
   of the principle is almost as important: software on other hosts may
   contain deficiencies that make it unwise to exploit legal but obscure
   protocol features."^[31]

   Encapsulation is used to provide abstraction of protocols and services.
   Encapsulation is usually aligned with the division of the protocol suite
   into layers of general functionality. In general, an application (the
   highest level of the model) uses a set of protocols to send its data down
   the layers. The data is further encapsulated at each level.

   An early architectural document, RFC 1122, emphasizes architectural
   principles over layering.^[32] RFC 1122, titled Host Requirements, is
   structured in paragraphs referring to layers, but the document refers to
   many other architectural principles and does not emphasize layering. It
   loosely defines a four-layer model, with the layers having names, not
   numbers, as follows:

     * The application layer is the scope within which applications, or
       processes, create user data and communicate this data to other
       applications on another or the same host. The applications make use of
       the services provided by the underlying lower layers, especially the
       transport layer which provides reliable or unreliable pipes to other
       processes. The communications partners are characterized by the
       application architecture, such as the client–server model and
       peer-to-peer networking. This is the layer in which all application
       protocols, such as SMTP, FTP, SSH, HTTP, operate. Processes are
       addressed via ports which essentially represent services.
     * The transport layer performs host-to-host communications on either the
       local network or remote networks separated by routers.^[33] It
       provides a channel for the communication needs of applications. UDP is
       the basic transport layer protocol, providing an unreliable
       connectionless datagram service. The Transmission Control Protocol
       provides flow-control, connection establishment, and reliable
       transmission of data.
     * The internet layer exchanges datagrams across network boundaries. It
       provides a uniform networking interface that hides the actual topology
       (layout) of the underlying network connections. It is therefore also
       the layer that establishes internetworking. Indeed, it defines and
       establishes the Internet. This layer defines the addressing and
       routing structures used for the TCP/IP protocol suite. The primary
       protocol in this scope is the Internet Protocol, which defines IP
       addresses. Its function in routing is to transport datagrams to the
       next host, functioning as an IP router, that has the connectivity to a
       network closer to the final data destination.
     * The link layer defines the networking methods within the scope of the
       local network link on which hosts communicate without intervening
       routers. This layer includes the protocols used to describe the local
       network topology and the interfaces needed to affect the transmission
       of Internet layer datagrams to next-neighbor hosts.

Link layerEdit

   The protocols of the link layer operate within the scope of the local
   network connection to which a host is attached. This regime is called the
   link in TCP/IP parlance and is the lowest component layer of the suite.
   The link includes all hosts accessible without traversing a router. The
   size of the link is therefore determined by the networking hardware
   design. In principle, TCP/IP is designed to be hardware independent and
   may be implemented on top of virtually any link-layer technology. This
   includes not only hardware implementations, but also virtual link layers
   such as virtual private networks and networking tunnels.

   The link layer is used to move packets between the Internet layer
   interfaces of two different hosts on the same link. The processes of
   transmitting and receiving packets on the link can be controlled in the
   device driver for the network card, as well as in firmware or by
   specialized chipsets. These perform functions, such as framing, to prepare
   the Internet layer packets for transmission, and finally transmit the
   frames to the physical layer and over a transmission medium. The TCP/IP
   model includes specifications for translating the network addressing
   methods used in the Internet Protocol to link-layer addresses, such as
   media access control (MAC) addresses. All other aspects below that level,
   however, are implicitly assumed to exist, and are not explicitly defined
   in the TCP/IP model.

   The link layer in the TCP/IP model has corresponding functions in Layer 2
   of the OSI model.

Internet layerEdit

   Link: mw-deduplicated-inline-style
   See also: IP header

   Internetworking requires sending data from the source network to the
   destination network. This process is called routing and is supported by
   host addressing and identification using the hierarchical IP addressing
   system. The internet layer provides an unreliable datagram transmission
   facility between hosts located on potentially different IP networks by
   forwarding datagrams to an appropriate next-hop router for further
   relaying to its destination. The internet layer has the responsibility of
   sending packets across potentially multiple networks. With this
   functionality, the internet layer makes possible internetworking, the
   interworking of different IP networks, and it essentially establishes the
   Internet.

   The internet layer does not distinguish between the various transport
   layer protocols. IP carries data for a variety of different upper layer
   protocols. These protocols are each identified by a unique protocol
   number: for example, Internet Control Message Protocol (ICMP) and Internet
   Group Management Protocol (IGMP) are protocols 1 and 2, respectively.

   The Internet Protocol is the principal component of the internet layer,
   and it defines two addressing systems to identify network hosts and to
   locate them on the network. The original address system of the ARPANET and
   its successor, the Internet, is Internet Protocol version 4 (IPv4). It
   uses a 32-bit IP address and is therefore capable of identifying
   approximately four billion hosts. This limitation was eliminated in 1998
   by the standardization of Internet Protocol version 6 (IPv6) which uses
   128-bit addresses. IPv6 production implementations emerged in
   approximately 2006.

Transport layerEdit

   Link: mw-deduplicated-inline-style
   See also: Transport layer

   The transport layer establishes basic data channels that applications use
   for task-specific data exchange. The layer establishes host-to-host
   connectivity in the form of end-to-end message transfer services that are
   independent of the underlying network and independent of the structure of
   user data and the logistics of exchanging information. Connectivity at the
   transport layer can be categorized as either connection-oriented,
   implemented in TCP, or connectionless, implemented in UDP. The protocols
   in this layer may provide error control, segmentation, flow control,
   congestion control, and application addressing (port numbers).

   For the purpose of providing process-specific transmission channels for
   applications, the layer establishes the concept of the network port. This
   is a numbered logical construct allocated specifically for each of the
   communication channels an application needs. For many types of services,
   these port numbers have been standardized so that client computers may
   address specific services of a server computer without the involvement of
   service discovery or directory services.

   Because IP provides only a best-effort delivery, some transport-layer
   protocols offer reliability.

   TCP is a connection-oriented protocol that addresses numerous reliability
   issues in providing a reliable byte stream:

     * data arrives in-order
     * data has minimal error (i.e., correctness)
     * duplicate data is discarded
     * lost or discarded packets are resent
     * includes traffic congestion control

   The newer Stream Control Transmission Protocol (SCTP) is also a reliable,
   connection-oriented transport mechanism. It is message-stream-oriented,
   not byte-stream-oriented like TCP, and provides multiple streams
   multiplexed over a single connection. It also provides multihoming
   support, in which a connection end can be represented by multiple IP
   addresses (representing multiple physical interfaces), such that if one
   fails, the connection is not interrupted. It was developed initially for
   telephony applications (to transport SS7 over IP).

   Reliability can also be achieved by running IP over a reliable data-link
   protocol such as the High-Level Data Link Control (HDLC).

   The User Datagram Protocol (UDP) is a connectionless datagram protocol.
   Like IP, it is a best-effort, unreliable protocol. Reliability is
   addressed through error detection using a checksum algorithm. UDP is
   typically used for applications such as streaming media (audio, video,
   Voice over IP etc.) where on-time arrival is more important than
   reliability, or for simple query/response applications like DNS lookups,
   where the overhead of setting up a reliable connection is
   disproportionately large. Real-time Transport Protocol (RTP) is a datagram
   protocol that is used over UDP and is designed for real-time data such as
   streaming media.

   The applications at any given network address are distinguished by their
   TCP or UDP port. By convention, certain well known ports are associated
   with specific applications.

   The TCP/IP model's transport or host-to-host layer corresponds roughly to
   the fourth layer in the OSI model, also called the transport layer.

   QUIC is rapidly emerging as an alternative transport protocol. Whilst it
   is technically carried via UDP packets it seeks to offer enhanced
   transport connectivity relative to TCP. HTTP/3 works exclusively via QUIC.

Application layerEdit

   The application layer includes the protocols used by most applications for
   providing user services or exchanging application data over the network
   connections established by the lower level protocols. This may include
   some basic network support services such as routing protocols and host
   configuration. Examples of application layer protocols include the
   Hypertext Transfer Protocol (HTTP), the File Transfer Protocol (FTP), the
   Simple Mail Transfer Protocol (SMTP), and the Dynamic Host Configuration
   Protocol (DHCP).^[34] Data coded according to application layer protocols
   are encapsulated into transport layer protocol units (such as TCP streams
   or UDP datagrams), which in turn use lower layer protocols to effect
   actual data transfer.

   The TCP/IP model does not consider the specifics of formatting and
   presenting data and does not define additional layers between the
   application and transport layers as in the OSI model (presentation and
   session layers). According to the TCP/IP model, such functions are the
   realm of libraries and application programming interfaces. The application
   layer in the TCP/IP model is often compared to a combination of the fifth
   (session), sixth (presentation), and seventh (application) layers of the
   OSI model.

   Application layer protocols are often associated with particular
   client–server applications, and common services have well-known port
   numbers reserved by the Internet Assigned Numbers Authority (IANA). For
   example, the HyperText Transfer Protocol uses server port 80 and Telnet
   uses server port 23. Clients connecting to a service usually use ephemeral
   ports, i.e., port numbers assigned only for the duration of the
   transaction at random or from a specific range configured in the
   application.

   At the application layer, the TCP/IP model distinguishes between user
   protocols and support protocols.^[35] 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 boxes 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 switches do not typically examine the encapsulated
   traffic, rather they just provide a conduit for it. However, some firewall
   and bandwidth throttling applications use deep packet inspection to
   interpret application data. An example is the Resource Reservation
   Protocol (RSVP).^[citation needed] It is also sometimes necessary for
   Applications affected by NAT to consider the application payload.

Layer names and number of layers in the literatureEdit

   The following table shows various networking models. The number of layers
   varies between three and seven.

RFC 1122,                                                                                                           
Internet    Cisco        Kurose,^[37]  Comer,^[39]   Stallings^[41] Tanenbaum^[42] Arpanet Reference   OSI model
STD 3       Academy^[36] Forouzan^[38] Kozierok^[40]                               Model (RFC 871)
(1989)      
Four layers Four layers  Five layers   Four+one      Five layers    Five layers    Three layers        Seven layers 
                                       layers        
                         "Five-layer                                                                                
                         Internet      "TCP/IP                      "TCP/IP                            
"Internet   "Internet    model" or     5-layer       "TCP/IP model" 5-layer        "Arpanet reference  OSI model
model"      model"       "TCP/IP       reference                    reference      model"
                         protocol      model"                       model"
                         suite"        
                                                                                                       Application  
Application Application  Application   Application   Application    Application    Application/Process Presentation 
                                                                                                       Session      
Transport   Transport    Transport     Transport     Host-to-host   Transport                          Transport    
                                                     or transport                  Host-to-host
Internet    Internetwork Network       Internet      Internet       Internet                           Network      
            Network                    Data link                                                                    
Link        interface    Data link     (Network      Network access Data link      Network interface   Data link
                                       interface)    
                         Physical      (Hardware)    Physical       Physical                           Physical     

   Some of the networking models are from textbooks, which are secondary
   sources that may conflict with the intent of RFC 1122 and other IETF
   primary sources.^[43]

Comparison of TCP/IP and OSI layeringEdit

   Link: mw-deduplicated-inline-style
   See also: OSI model § Comparison with TCP/IP model

   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.

   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^[citation needed] 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".

   For example, the session and presentation layers of the OSI suite are
   considered to be included in the application layer of the TCP/IP suite.
   The functionality of the session layer can be found in protocols like HTTP
   and SMTP and is more evident in protocols like Telnet and the Session
   Initiation Protocol (SIP). Session-layer functionality is also realized
   with the port numbering of the TCP and UDP protocols, which are included
   in the transport layer of the TCP/IP suite. Functions of the presentation
   layer are realized in the TCP/IP applications with the MIME standard in
   data exchange.

   Another difference is in the treatment of routing protocols. The OSI
   routing protocol IS-IS belongs to the network layer, and does not depend
   on CLNS for delivering packets from one router to another, but defines its
   own layer-3 encapsulation. In contrast, OSPF, RIP, BGP and other routing
   protocols defined by the IETF are transported over IP, and, for the
   purpose of sending and receiving routing protocol packets, routers act as
   hosts. As a consequence,
   Link: mw-deduplicated-inline-style
   RFC 1812 include routing protocols in the application layer. Some authors,
   such as Tanenbaum in Computer Networks, describe routing protocols in the
   same layer as IP, reasoning that routing protocols inform decisions made
   by the forwarding process of routers.

   IETF protocols can be encapsulated recursively, as demonstrated by
   tunnelling protocols such as Generic Routing Encapsulation (GRE). GRE uses
   the same mechanism that OSI uses for tunnelling at the network layer.

ImplementationsEdit

   ‹ The template below (Unreferenced section) is being considered for
   merging. See templates for discussion to help reach a consensus. ›

   This section does not cite any sources. Please help improve this section   
   by adding citations to reliable sources. Unsourced material may be         
   challenged and removed. (March 2014) (Learn how and when to remove this    
   template message)                                                          

   The Internet protocol suite does not presume any specific hardware or
   software environment. It only requires that hardware and a software layer
   exists that is capable of sending and receiving packets on a computer
   network. As a result, the suite has been implemented on essentially every
   computing platform. A minimal implementation of TCP/IP includes the
   following: Internet Protocol (IP), Address Resolution Protocol (ARP),
   Internet Control Message Protocol (ICMP), Transmission Control Protocol
   (TCP), User Datagram Protocol (UDP), and Internet Group Management
   Protocol (IGMP). In addition to IP, ICMP, TCP, UDP, Internet Protocol
   version 6 requires Neighbor Discovery Protocol (NDP), ICMPv6, and
   Multicast Listener Discovery (MLD) and is often accompanied by an
   integrated IPSec security layer.

See alsoEdit

     * BBN Report 1822, an early layered network model
     * FLIP (protocol) (fast local Internet protocol stack)
     * List of automation protocols
     * List of information technology acronyms
     * List of IP protocol numbers
     * List of network protocols
     * List of TCP and UDP port numbers

ReferencesEdit

    1. ^ ^a ^b
       Link: mw-deduplicated-inline-style
       Cerf, Vinton G. & Cain, Edward (1983), "The DoD Internet Architecture
       Model", Computer Networks, 7, North-Holland, pp. 307–318,
       CiteSeerX 10.1.1.88.7505
    2. ^ ^a ^b RFC 1122, Requirements for Internet Hosts – Communication
       Layers, R. Braden (ed.), October 1989.
    3. ^ RFC 1123, Requirements for Internet Hosts – Application and Support,
       R. Braden (ed.), October 1989
    4. ^
       Link: mw-deduplicated-inline-style
       Abbate, Janet (2000). Inventing the Internet. MIT Press. pp. 123–4.
       ISBN 978-0-262-51115-5.
    5. ^
       Link: mw-deduplicated-inline-style
       Cerf, V.; Kahn, R. (1974). "A Protocol for Packet Network
       Intercommunication" (PDF). IEEE Transactions on Communications. 22
       (5): 637–648. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. The
       authors wish to thank a number of colleagues for helpful comments
       during early discussions of international network protocols,
       especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman;
       D. Davies and L. Pouzin who constructively commented on the
       fragmentation and accounting issues; and S. Crocker who commented on
       the creation and destruction of associations.
    6. ^
       Link: mw-deduplicated-inline-style
       "The internet's fifth man". Economist. December 13, 2013. Retrieved
       September 11, 2017. In the early 1970s Mr Pouzin created an innovative
       data network that linked locations in France, Italy and Britain. Its
       simplicity and efficiency pointed the way to a network that could
       connect not just dozens of machines, but millions of them. It captured
       the imagination of Dr Cerf and Dr Kahn, who included aspects of its
       design in the protocols that now power the internet.
    7. ^ Vinton Cerf, Yogen Dalal, Carl Sunshine (December 1974),
       Link: mw-deduplicated-inline-style
       RFC 675, Specification of Internet Transmission Control Protocol
       (December 1974)
    8. ^ Internet Hall of Fame
    9. ^
       Link: mw-deduplicated-inline-style
       Panzaris, Georgios (2008). Machines and romances: the technical and
       narrative construction of networked computing as a general-purpose
       platform, 1960-1995. Stanford University. p. 128.
   10. ^
       Link: mw-deduplicated-inline-style
       Pelkey, James L. (2007). "Yogen Dalal". Entrepreneurial Capitalism and
       Innovation: A History of Computer Communications, 1968-1988. Retrieved
       September 5, 2019.
   11. ^
       Link: mw-deduplicated-inline-style
       Postel, Jon (1977), "Section 3.3.3.2", Comments on Internet Protocol
       and TCP
   12. ^
       Link: mw-deduplicated-inline-style
       "The TCP/IP Guide - TCP/IP Overview and History". www.tcpipguide.com.
       Retrieved February 11, 2020.
   13. ^ ^a ^b
       Link: mw-deduplicated-inline-style
       by Vinton Cerf, as told to Bernard Aboba (1993). "How the Internet
       Came to Be". Archived from the original on September 26, 2017.
       Retrieved September 25, 2017. We began doing concurrent
       implementations at Stanford, BBN, and University College London. So
       effort at developing the Internet protocols was international from the
       beginning. ... Mar '82 - Norway leaves the ARPANET and become an
       Internet connection via TCP/IP over SATNET. Nov '82 - UCL leaves the
       ARPANET and becomes an Internet connection.
   14. ^ RFC 1812, Requirements for IP Version 4 Routers, F. Baker (June
       1995)
   15. ^
       Link: mw-deduplicated-inline-style
       Crowell, William; Contos, Brian; DeRodeff, Colby (2011). Physical and
       Logical Security Convergence: Powered By Enterprise Security
       Management. Syngress. p. 99. ISBN 9780080558783.
   16. ^
       Link: mw-deduplicated-inline-style
       Ronda Hauben. "From the ARPANET to the Internet". TCP Digest (UUCP).
       Retrieved July 5, 2007.
   17. ^
       Link: mw-deduplicated-inline-style
       Martin, Olivier (2012). The "Hidden" Prehistory of European Research
       Networking. Trafford Publishing. ISBN 978-1466938724.
   18. ^
       Link: mw-deduplicated-inline-style
       Kirstein, Peter T. "Early experiences with the ARPANET and Internet in
       the UK". Department of Computer Science, Systems and Networks Research
       Group, University College London. Retrieved April 13, 2016.
   19. ^
       Link: mw-deduplicated-inline-style
       "TCP/IP Internet Protocol". Archived from the original on January 1,
       2018. Retrieved December 31, 2017.
   20. ^
       Link: mw-deduplicated-inline-style
       Leiner, Barry M.; et al. (1997), Brief History of the Internet (PDF),
       Internet Society, p. 15
   21. ^
       Link: mw-deduplicated-inline-style
       "Using Wollongong TCP/IP with Windows for Workgroups 3.11". Microsoft
       Support. Archived from the original on January 12, 2012.
   22. ^
       Link: mw-deduplicated-inline-style
       "A Short History of Internet Protocols at CERN". Archived from the
       original on November 10, 2016. Retrieved September 12, 2016.
   23. ^
       Link: mw-deduplicated-inline-style
       Baker, Steven; Gillies, Donald W. "Desktop TCP/IP at middle age".
   24. ^
       Link: mw-deduplicated-inline-style
       Romkey, John (February 17, 2011). "About". Retrieved September 12,
       2016.
   25. ^ Phil Karn, KA9Q TCP Download Website
   26. ^
       Link: mw-deduplicated-inline-style
       Andrew L. Russell (July 30, 2013). "OSI: The Internet That Wasn't".
       IEEE Spectrum. Vol. 50, no. 8.
   27. ^
       Link: mw-deduplicated-inline-style
       Russell, Andrew L. "Rough Consensus and Running Code' and the
       Internet-OSI Standards War" (PDF). IEEE Annals of the History of
       Computing. Archived from the original (PDF) on November 17, 2019.
   28. ^ ^a ^b
       Link: mw-deduplicated-inline-style
       Davies, Howard; Bressan, Beatrice (April 26, 2010). A History of
       International Research Networking: The People who Made it Happen. John
       Wiley & Sons. ISBN 978-3-527-32710-2.
   29. ^ Rethinking the design of the Internet: The end-to-end arguments vs.
       the brave new world, Marjory S. Blumenthal, David D. Clark, August
       2001
   30. ^
       Link: mw-deduplicated-inline-style
       Jon Postel, ed. (September 1981). Internet Protocol DARPA Internet
       Program Protocol Specification. p. 23. doi:10.17487/RFC0791. RFC 791.
   31. ^
       Link: mw-deduplicated-inline-style
       R. Braden, ed. (October 1989). Requirements for Internet Hosts –
       Communication Layers. p. 13. doi:10.17487/RFC1122. RFC 1122.
   32. ^
       Link: mw-deduplicated-inline-style
       B. Carpenter, ed. (June 1996). Architectural Principles of the
       Internet. doi:10.17487/RFC1958. RFC 1958.
   33. ^
       Link: mw-deduplicated-inline-style
       Hunt, Craig (2002). TCP/IP Network Administration (3rd ed.). O'Reilly.
       pp. 9–10. ISBN 9781449390785.
   34. ^ TCP/IP Illustrated: the protocols,
       Link: mw-deduplicated-inline-style
       ISBN 0-201-63346-9, W. Richard Stevens, February 1994
   35. ^ RFC 1122, Requirements for Internet Hosts – Communication Layers,
       1.1.3 Internet Protocol Suite, 1989
   36. ^
       Link: mw-deduplicated-inline-style
       Dye, Mark; McDonald, Rick; Rufi, Antoon (October 29, 2007). Network
       Fundamentals, CCNA Exploration Companion Guide. Cisco Press.
       ISBN 9780132877435. Retrieved September 12, 2016 – via Google Books.
   37. ^ James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down
       Approach, 2008
       Link: mw-deduplicated-inline-style
       ISBN 0-321-49770-8
   38. ^
       Link: mw-deduplicated-inline-style
       Forouzan, Behrouz A.; Fegan, Sophia Chung (August 1, 2003). Data
       Communications and Networking. McGraw-Hill Higher Education.
       ISBN 9780072923544. Retrieved September 12, 2016 – via Google Books.
   39. ^
       Link: mw-deduplicated-inline-style
       Comer, Douglas (January 1, 2006). Internetworking with TCP/IP:
       Principles, protocols, and architecture. Prentice Hall.
       ISBN 0-13-187671-6. Retrieved September 12, 2016 – via Google Books.
   40. ^
       Link: mw-deduplicated-inline-style
       Kozierok, Charles M. (January 1, 2005). The TCP/IP Guide: A
       Comprehensive, Illustrated Internet Protocols Reference. No Starch
       Press. ISBN 9781593270476. Retrieved September 12, 2016 – via Google
       Books.
   41. ^
       Link: mw-deduplicated-inline-style
       Stallings, William (January 1, 2007). Data and Computer
       Communications. Prentice Hall. ISBN 978-0-13-243310-5. Retrieved
       September 12, 2016 – via Google Books.
   42. ^
       Link: mw-deduplicated-inline-style
       Tanenbaum, Andrew S. (January 1, 2003). Computer Networks. Prentice
       Hall PTR. p. 42. ISBN 0-13-066102-3. Retrieved September 12, 2016 –
       via Internet Archive. networks.
   43. ^ RFC 3439, Some Internet Architectural Guidelines and Philosophy, R.
       Bush, D. Meyer (eds.), December 2002.

BibliographyEdit

     * Link: mw-deduplicated-inline-style
       Douglas E. Comer. Internetworking with TCP/IP – Principles, Protocols
       and Architecture. ISBN 86-7991-142-9.
     * Link: mw-deduplicated-inline-style
       Joseph G. Davies; Thomas F. Lee. Microsoft Windows Server 2003 TCP/IP
       Protocols and Services. ISBN 0-7356-1291-9.
     * Link: mw-deduplicated-inline-style
       Forouzan, Behrouz A. (2003). TCP/IP Protocol Suite (2nd ed.).
       McGraw-Hill. ISBN 978-0-07-246060-5.
     * Link: mw-deduplicated-inline-style
       Craig Hunt (1998). TCP/IP Network Administration. O'Reilly.
       ISBN 1-56592-322-7.
     * Link: mw-deduplicated-inline-style
       Maufer, Thomas A. (1999). IP Fundamentals. Prentice Hall.
       ISBN 978-0-13-975483-8.
     * Link: mw-deduplicated-inline-style
       Ian McLean. Windows 2000 TCP/IP Black Book. ISBN 1-57610-687-X.
     * Link: mw-deduplicated-inline-style
       Ajit Mungale. Pro .NET 1.1 Network Programming. ISBN 1-59059-345-6.
     * Link: mw-deduplicated-inline-style
       W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols.
       ISBN 0-201-63346-9.
     * Link: mw-deduplicated-inline-style
       W. Richard Stevens; Gary R. Wright. TCP/IP Illustrated, Volume 2: The
       Implementation. ISBN 0-201-63354-X.
     * Link: mw-deduplicated-inline-style
       W. Richard Stevens. TCP/IP Illustrated, Volume 3: TCP for
       Transactions, HTTP, NNTP, and the UNIX Domain Protocols.
       ISBN 0-201-63495-3.
     * Link: mw-deduplicated-inline-style
       Andrew S. Tanenbaum. Computer Networks. ISBN 0-13-066102-3.
     * Link: mw-deduplicated-inline-style
       Clark, D. (1988). "The Design Philosophy of the DARPA Internet
       Protocols". Symposium proceedings on Communications architectures and
       protocols - SIGCOMM '88 (PDF). SIGCOMM '88 Symposium Proceedings on
       Communications Architectures and Protocols. ACM. pp. 106–114.
       doi:10.1145/52324.52336. ISBN 978-0897912792. S2CID 6156615. Retrieved
       October 16, 2011.
     * A Protocol for Packet Network Intercommunication, Cerf & Kahn, IEEE
       Trans on Comms, Vol Com-22, No 5 May 1974

External linksEdit

   Wikiversity has learning resources about Internet protocol suite 

     * Internet History – Pages on Robert Kahn, Vinton Cerf, and TCP/IP
       (reviewed by Cerf and Kahn).
     * Link: mw-deduplicated-inline-style
       RFC 1180 A TCP/IP Tutorial – from the Internet Engineering Task Force
       (January 1991)
     * The Ultimate Guide to TCP/IP
     * The TCP/IP Guide – A comprehensive look at the protocols and the
       procedure and processes involved
     * Link: mw-deduplicated-inline-style
       A Study of the ARPANET TCP/IP Digest, archived from the original on
       December 4, 2021
     * TCP/IP Sequence Diagrams
     * Daryl's TCP/IP Primer – Intro to TCP/IP LAN administration,
       conversational style
   Retrieved from
   "https://en.wikipedia.org/w/index.php?title=Internet_protocol_suite&oldid=1080856717"
   Last edited on 3 April 2022, at 21:43
   Wikipedia
     * This page was last edited on 3 April 2022, at 21:43 (UTC).
     * Content is available under CC BY-SA 3.0 unless otherwise noted.
     * Privacy policy
     * About Wikipedia
     * Disclaimers
     * Contact Wikipedia
     * Terms of Use
     * Desktop
     * Developers
     * Statistics
     * Cookie statement
