Editing Internet Protocol

{{Short description|Communication protocol that allows connections between networks}}
{{IPstack}}
{{Internet history timeline}}

The '''Internet Protocol''' ('''IP''') is the [[network layer]] [[communications protocol]] in the [[Internet protocol suite]] for relaying [[datagram]]s across network boundaries. Its [[routing]] function enables [[internetworking]], and essentially establishes the [[Internet]].

IP has the task of delivering [[Packet (information technology)|packets]] from the source [[Host (network)|host]] to the destination host solely based on the [[IP address]]es in the packet [[Header (computing)|headers]]. For this purpose, IP defines packet structures that [[encapsulation (networking)|encapsulate]] the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information.
IP was the [[connectionless]] datagram service in the original ''[[Transmission Control Program]]'' introduced by [[Vint Cerf]] and [[Bob Kahn]] in 1974, which was complemented by a [[connection-oriented]] service that became the basis for the [[Transmission Control Protocol]] (TCP). The Internet protocol suite is therefore often referred to as ''TCP/IP''.

The first major version of IP, [[Internet Protocol version 4]] (IPv4), is the dominant protocol of the Internet. Its successor is [[Internet Protocol version 6]] (IPv6), which has been in increasing [[IPv6 deployment|deployment]] on the public Internet since around 2006.<ref>{{Cite report|publisher=OECD|date=2014-11-06|title=The Economics of Transition to Internet Protocol version 6 (IPv6)|series=OECD Digital Economy Papers|url=https://www.oecd-ilibrary.org/science-and-technology/the-economics-of-transition-to-internet-protocol-version-6-ipv6_5jxt46d07bhc-en|language=en|doi=10.1787/5jxt46d07bhc-en|doi-access=free|access-date=2020-12-04|archive-date=2021-03-07|archive-url=https://web.archive.org/web/20210307213313/https://www.oecd-ilibrary.org/science-and-technology/the-economics-of-transition-to-internet-protocol-version-6-ipv6_5jxt46d07bhc-en|url-status=live}}</ref>

==Function==
[[File:UDP encapsulation.svg|thumb|260px|Encapsulation of application data carried by [[User Datagram Protocol|UDP]] to a link protocol frame]]
The Internet Protocol is responsible for addressing [[host interface]]s, encapsulating data into datagrams (including [[IP fragmentation|fragmentation and reassembly]]) and routing datagrams from a source host interface to a destination host interface across one or more IP networks.'''<ref>{{citation |url=http://www.tcpipguide.com/free/t_IPFunctions.htm |title=The TCP/IP Guide |author=Charles M. Kozierok |access-date=2017-07-22 |archive-date=2019-06-20 |archive-url=https://web.archive.org/web/20190620010402/http://www.tcpipguide.com/free/t_IPFunctions.htm |url-status=live }}</ref>''' For these purposes, the Internet Protocol defines the format of packets and provides an addressing system.

Each datagram has two components: a [[Header (computing)|header]] and a [[Payload (computing)|payload]]. The [[IP header]] includes a source IP address, a destination IP address, and other metadata needed to route and deliver the datagram. The payload is the data that is transported. This method of nesting the data payload in a packet with a header is called encapsulation.

IP addressing entails the assignment of IP addresses and associated parameters to host interfaces. The address space is divided into [[subnet]]s, involving the designation of network prefixes. IP routing is performed by all hosts, as well as [[Router (computing)|routers]], whose main function is to transport packets across network boundaries. Routers communicate with one another via specially designed [[routing protocol]]s, either [[interior gateway protocol]]s or [[exterior gateway protocol]]s, as needed for the topology of the network.<ref>{{Cite web|title=IP Technologies and Migration — EITC|url=http://www.eitc.org/research-opportunities/future-internet-and-optical-quantum-communications/internet-networks-and-tcp-ip/ip-technologies-and-migration|access-date=2020-12-04|website=www.eitc.org|archive-date=2021-01-05|archive-url=https://web.archive.org/web/20210105023938/http://www.eitc.org/research-opportunities/future-internet-and-optical-quantum-communications/internet-networks-and-tcp-ip/ip-technologies-and-migration|url-status=dead}}</ref>

==Addressing methods==
{{routing scheme}}
There are four principal addressing methods in the Internet Protocol:
{{Routing scheme/details}}

== Version history ==
[[File:TCP and IP protocols development timeline-en.svg|thumb|right|A timeline for the development of the transmission control Protocol TCP and Internet Protocol IP]]
[[File:First Internet Demonstration, 1977.jpg|thumb|right|First Internet demonstration, linking the [[ARPANET]], [[PRNET]], and [[SATNET]] on November 22, 1977]]
In May 1974, the [[Institute of Electrical and Electronics Engineers]] (IEEE) published a paper entitled "A Protocol for Packet Network Intercommunication".<ref>{{Cite journal|last1=Cerf|first1=V.|last2=Kahn|first2=R.|date=1974|title=A Protocol for Packet Network Intercommunication|url=https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf|journal=IEEE Transactions on Communications|volume=22|issue=5|pages=637–648|doi=10.1109/TCOM.1974.1092259|issn=1558-0857|quote=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.|access-date=2020-04-06|archive-date=2017-01-06|archive-url=https://web.archive.org/web/20170106204542/http://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf|url-status=live}}</ref> The paper's authors, [[Vint Cerf]] and [[Bob Kahn]], described an [[internetworking]] protocol for sharing resources using [[packet switching]] among [[network node]]s. A central control component of this model was the Transmission Control Program that incorporated both connection-oriented links and datagram services between hosts. The monolithic Transmission Control Program was later divided into a modular architecture consisting of the [[Transmission Control Protocol]] and [[User Datagram Protocol]] at the [[transport layer]] and the Internet Protocol at the [[internet layer]]. The model became known as the ''Department of Defense (DoD) Internet Model'' and ''[[Internet protocol suite]]'', and informally as ''TCP/IP''.

The following [[Internet Experiment Note]] (IEN) documents describe the evolution of the Internet Protocol into the modern version of IPv4:<ref>{{Cite web |title=Internet Experiment Note Index |url=https://www.rfc-editor.org/ien/ien-index.html |access-date=2024-01-21 |website=www.rfc-editor.org}}</ref>
* [http://www.rfc-editor.org/ien/ien2.txt IEN 2] ''Comments on Internet Protocol and TCP (''August 1977) describes the need to separate the TCP and Internet Protocol functionalities (which were previously combined).  It proposes the first version of the IP header, using 0 for the version field.
* [http://www.rfc-editor.org/ien/ien26.pdf IEN 26] ''A Proposed New Internet Header Format (''February 1978) describes a version of the IP header that uses a 1-bit version field.
* [http://www.rfc-editor.org/ien/ien28.pdf IEN 28] ''Draft Internetwork Protocol Description Version 2 (''February 1978) describes IPv2.
* [http://www.rfc-editor.org/ien/ien41.pdf IEN 41] ''Internetwork Protocol Specification Version 4 (''June 1978) describes the first protocol to be called IPv4.  The IP header is different from the modern IPv4 header.
* [http://www.rfc-editor.org/ien/ien44.pdf IEN 44] ''Latest Header Formats (''June 1978) describes another version of IPv4, also with a header different from the modern IPv4 header.
* [http://www.rfc-editor.org/ien/ien54.pdf IEN 54] ''Internetwork Protocol Specification Version 4 (''September 1978) is the first description of IPv4 using the header that would become standardized in 1980 as {{IETF RFC|760}}.
* IEN 80
* IEN 111
* IEN 123
* IEN 128/RFC 760 (1980)

IP versions 1 to 3 were experimental versions, designed between 1973 and 1978.<ref name="Coty">{{cite web |author=Stephen Coty |date=2011-02-11 |title=Where is IPv1, 2, 3, and 5? |url=https://blog.alertlogic.com/blog/where-is-ipv1,-2,-3,and-5/ |url-status=dead |archive-url=https://web.archive.org/web/20200802011845/https://blog.alertlogic.com/blog/where-is-ipv1,-2,-3,and-5/ |archive-date=2020-08-02 |access-date=2020-03-25}}</ref> Versions 2 and 3 supported variable-length addresses ranging between 1 and 16 octets (between 8 and 128 bits).<ref>{{cite IETF |last1=Postel |first1=Jonathan B. |date=February 1978 |title=Draft Internetwork Protocol Specification Version 2 |ien=28 |autolink=no |url=https://www.rfc-editor.org/ien/ien28.pdf |website=RFC Editor |access-date=6 October 2022 }} {{Webarchive|url=https://web.archive.org/web/20190516090051/https://www.rfc-editor.org/ien/ien28.pdf |date=16 May 2019 }}</ref> An early draft of version 4 supported variable-length addresses of up to 256 octets (up to 2048 bits)<ref>{{cite IETF |last1=Postel |first1=Jonathan B. |date=June 1978 |title=Internetwork Protocol Specification Version 4 |ien=41 |autolink=no |url=https://www.rfc-editor.org/ien/ien41.pdf |website=RFC Editor |access-date=11 February 2024 }} {{Webarchive|url=https://web.archive.org/web/20190516090053/http://www.rfc-editor.org/ien/ien41.pdf |date=16 May 2019 }}</ref> but this was later abandoned in favor of a fixed-size 32-bit address in the final version of [[IPv4]]. This remains the dominant internetworking protocol in use in the [[Internet Layer]]; the number 4 identifies the protocol version, carried in every IP datagram. IPv4 is defined in {{IETF RFC|791}} (1981).

Version number 5 was used by the [[Internet Stream Protocol]], an experimental streaming protocol that was not adopted.<ref name="Coty"/>

The successor to IPv4 is [[IPv6]]. IPv6 was a result of several years of experimentation and dialog during which various protocol models were proposed, such as TP/IX ({{IETF RFC|1475}}), PIP ({{IETF RFC|1621}}) and TUBA (TCP and UDP with Bigger Addresses, {{IETF RFC|1347}}). Its most prominent difference from version 4 is the size of the addresses. While IPv4 uses [[32 bits]] for addressing, yielding c. 4.3 [[1,000,000,000 (number)|billion]] ({{val|4.3|e=9}}) addresses, IPv6 uses [[128-bit]] addresses providing c. {{val|3.4|e=38}} addresses. Although adoption of IPv6 has been slow, {{as of|2023|01|lc=yes}}, most countries in the world show significant adoption of IPv6,<ref>{{Cite web|title=IPv6 Adoption in 2021|url=https://labs.ripe.net/author/stephen_strowes/ipv6-adoption-in-2021/|first1=Stephen|last1=Strowes|date=4 Jun 2021|access-date=2021-09-20|website=RIPE Labs|language=en-US|archive-date=2021-09-20|archive-url=https://web.archive.org/web/20210920213008/https://labs.ripe.net/author/stephen_strowes/ipv6-adoption-in-2021/|url-status=live}}</ref> with over 41% of Google's traffic being carried over IPv6 connections.<ref>{{Cite web |title=IPv6 |url=https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption |access-date=2023-05-19 |website=Google |archive-date=2020-07-14 |archive-url=https://web.archive.org/web/20200714184705/https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption |url-status=live }}</ref>

The assignment of the new protocol as IPv6 was uncertain until due diligence assured that IPv6 had not been used previously.<ref>{{cite web|last1=Mulligan|first1=Geoff|title=It was almost IPv7|url=http://archive.oreilly.com/cs/user/view/cs_msg/25036|website=O'Reilly |access-date=4 July 2015|archive-url=https://web.archive.org/web/20150705060055/http://archive.oreilly.com/cs/user/view/cs_msg/25036|archive-date=5 July 2015|url-status=dead}}</ref> Other Internet Layer protocols have been assigned version numbers,<ref>{{Cite web|url=https://www.iana.org/assignments/version-numbers/version-numbers.xhtml|title=IP Version Numbers|website=Internet Assigned Numbers Authority|access-date=2019-07-25|archive-date=2019-01-18|archive-url=https://web.archive.org/web/20190118144623/https://www.iana.org/assignments/version-numbers/version-numbers.xhtml|url-status=live}}</ref> such as 7 (''IP/TX''), 8 and 9 (''historic''). Notably, on April 1, 1994, the [[IETF]] published an [[April Fools' Day RfC]] about IPv9.<ref>{{IETF RFC|1606}}: ''A Historical Perspective On The Usage Of IP Version 9''. April 1, 1994.</ref> IPv9 was also used in an alternate proposed address space expansion called TUBA.<ref>{{cite IETF |rfc=1347 |title=TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing |author=Ross Callon |date=June 1992}}</ref> A 2004 Chinese proposal for [[IPv9 (China)|an IPv9 protocol]] appears to be unrelated to all of these, and is not endorsed by the IETF.

===IP version numbers===
As the version number is carried in a 4-bit field, only numbers 0–15 can be assigned.
{| class="wikitable"
|-
!IP version
!Description
!Year
!Status
|-
!0
|Internet Protocol, pre-v4||N/A||Reserved<ref name="routing tcp/ip">{{Cite book|title=Routing TCP/IP|volume=1|edition=2|author1=Jeff Doyle|author2=Jennifer Carroll|year=2006|isbn=978-1-58705-202-6|publisher=Cisco Press|page=8}}</ref>
|-
!1
|Experimental version||1973||Obsolete
|-
!2
|Experimental version||1977||Obsolete
|-
!3
|Experimental version||1978||Obsolete
|-
!4
|[[Internet Protocol version 4]] (IPv4){{Ref RFC|791|repeat=yes}}||1981||Active
|-
!rowspan=3|5
|[[Internet Stream Protocol]] (ST)||1979||Obsolete; superseded by ST-II or ST2
|-
|[[Internet Stream Protocol]] (ST-II or ST2){{Ref RFC|1819}}||1987||Obsolete; superseded by ST2+
|-
|[[Internet Stream Protocol]] (ST2+)||1995||Obsolete
|-
!rowspan=2|6
|Simple Internet Protocol (SIP)||N/A||Obsolete; merged into IPv6 in 1995<ref name="routing tcp/ip" />
|-
|[[Internet Protocol version 6]] (IPv6){{Ref RFC|8200|repeat=yes}}||1995||Active
|-
!7
|TP/IX The Next Internet (IPv7){{Ref RFC|1475}}||1993||Obsolete{{Ref RFC|6814}}
|-
!8
|P Internet Protocol (PIP){{Ref RFC|1621}}||1994||Obsolete; merged into SIP in 1993
|-
!rowspan=3|9
|TCP and UDP over Bigger Addresses (TUBA)||1992||Obsolete{{Ref RFC|1347}}
|-
|IPv9||1994||[[April Fools' Day]] joke{{Ref RFC|1606}}
|-
|[[Chinese IPv9]]||2004||Abandoned
|-
!10–14
|N/A||N/A||Unassigned
|-
!15
|''Version field sentinel value''||N/A||Reserved
|}

==Reliability==
The design of the Internet protocol suite adheres to the [[end-to-end principle]], a concept adapted from the [[CYCLADES]] project. Under the end-to-end principle, the network infrastructure is considered inherently unreliable at any single network element or transmission medium and is dynamic in terms of the availability of links and nodes. No central monitoring or performance measurement facility exists that tracks or maintains the state of the network. For the benefit of reducing [[network complexity]], the intelligence in the network is located in the [[end node]]s.

As a consequence of this design, the Internet Protocol only provides [[best-effort delivery]] and its service is characterized as [[Reliability (computer networking)|unreliable]]. In network architectural parlance, it is a [[connectionless protocol]], in contrast to [[connection-oriented communication]]. Various fault conditions may occur, such as [[data corruption]], [[packet loss]] and duplication. Because routing is dynamic, meaning every packet is treated independently, and because the network maintains no state based on the path of prior packets, different packets may be routed to the same destination via different paths, resulting in [[out-of-order delivery]] to the receiver.

All fault conditions in the network must be detected and compensated by the participating end nodes. The [[upper layer protocol]]s of the Internet protocol suite are responsible for resolving reliability issues. For example, a host may [[Data buffer|buffer]] network data to ensure correct ordering before the data is delivered to an application.

IPv4 provides safeguards to ensure that the header of an IP packet is error-free. A routing node discards packets that fail a header [[checksum]] test. Although the [[Internet Control Message Protocol]] (ICMP) provides notification of errors, a routing node is not required to notify either end node of errors. IPv6, by contrast, operates without header checksums, since current [[link layer]] technology is assumed to provide sufficient error detection.<ref>{{IETF RFC|1726}} section 6.2</ref><ref>{{IETF RFC|2460}}</ref>

==Link capacity and capability==
The dynamic nature of the Internet and the diversity of its components provide no guarantee that any particular path is actually capable of, or suitable for, performing the data transmission requested. One of the technical constraints is the size of data packets possible on a given link. Facilities exist to examine the [[maximum transmission unit]] (MTU) size of the local link and [[Path MTU Discovery]] can be used for the entire intended path to the destination.<ref>{{Cite book|last=Rishabh|first=Anand|url=https://books.google.com/books?id=XDJlDwAAQBAJ&q=The+dynamic+nature+of+the+Internet+and+the+diversity+of+its+components+provide+no+guarantee+that+any+particular+path+is+actually+capable+of%2C+or+suitable+for%2C+performing+the+data+transmission+requested.+One+of+the+technical+constraints+is+the+size+of+data+packets+possible+on+a+given+link.+Facilities+exist+to+examine+the+maximum+transmission+unit+%28MTU%29+size+of+the+local+link+and+Path+MTU+Discovery+can+be+used+for+the+entire+intended+path+to+the+destination.&pg=PA332|title=Wireless Communication|date=2012|publisher=S. Chand Publishing|isbn=978-81-219-4055-9|language=en|access-date=2020-12-11|archive-date=2024-06-12|archive-url=https://web.archive.org/web/20240612133919/https://books.google.com/books?id=XDJlDwAAQBAJ&q=The+dynamic+nature+of+the+Internet+and+the+diversity+of+its+components+provide+no+guarantee+that+any+particular+path+is+actually+capable+of%2C+or+suitable+for%2C+performing+the+data+transmission+requested.+One+of+the+technical+constraints+is+the+size+of+data+packets+possible+on+a+given+link.+Facilities+exist+to+examine+the+maximum+transmission+unit+%28MTU%29+size+of+the+local+link+and+Path+MTU+Discovery+can+be+used+for+the+entire+intended+path+to+the+destination.&pg=PA332#v=snippet&q=The%20dynamic%20nature%20of%20the%20Internet%20and%20the%20diversity%20of%20its%20components%20provide%20no%20guarantee%20that%20any%20particular%20path%20is%20actually%20capable%20of%2C%20or%20suitable%20for%2C%20performing%20the%20data%20transmission%20requested.%20One%20of%20the%20technical%20constraints%20is%20the%20size%20of%20data%20packets%20possible%20on%20a%20given%20link.%20Facilities%20exist%20to%20examine%20the%20maximum%20transmission%20unit%20(MTU)%20size%20of%20the%20local%20link%20and%20Path%20MTU%20Discovery%20can%20be%20used%20for%20the%20entire%20intended%20path%20to%20the%20destination.&f=false|url-status=live}}</ref>

The IPv4 internetworking layer automatically [[IP fragmentation|fragments]] a datagram into smaller units for transmission when the link MTU is exceeded. IP provides re-ordering of fragments received out of order.<ref>Siyan, Karanjit. ''Inside TCP/IP'', New Riders Publishing, 1997. {{ISBN|1-56205-714-6}}</ref> An IPv6 network does not perform fragmentation in network elements, but requires end hosts and higher-layer protocols to avoid exceeding the path MTU.<ref>{{cite web |title=IPv6 Fragmentation |author=Bill Cerveny |publisher=[[Arbor Networks]] |url=https://www.arbornetworks.com/blog/asert/ipv6-fragmentation/ |date=2011-07-25 |access-date=2016-09-10 |archive-date=2016-09-16 |archive-url=https://web.archive.org/web/20160916162637/https://www.arbornetworks.com/blog/asert/ipv6-fragmentation/ |url-status=live }}</ref>

The [[Transmission Control Protocol]] (TCP) is an example of a protocol that adjusts its segment size to be smaller than the MTU. The [[User Datagram Protocol]] (UDP) and ICMP disregard MTU size, thereby forcing IP to fragment oversized datagrams.<ref>{{Cite web|url = https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=03c598ea-e171-47c9-8035-753ccd8bb36e&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments|title = Basic Journey of a Packet|date = 2 November 2010|access-date = 4 May 2014|website = [[Broadcom#Symantec enterprise security|Symantec]]|publisher = [[NortonLifeLock|Symantec]]|last = Parker|first = Don|archive-date = 20 January 2022|archive-url = https://web.archive.org/web/20220120044011/https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=03c598ea-e171-47c9-8035-753ccd8bb36e&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments|url-status = live}}</ref>

==Security==
During the design phase of the [[ARPANET]] and the early Internet, the security aspects and needs of a public, international network were not adequately anticipated.  Consequently, many Internet protocols exhibited vulnerabilities highlighted by network attacks and later security assessments. In 2008, a thorough security assessment and proposed mitigation of problems was published.<ref>{{citation |archive-url=https://web.archive.org/web/20100211145721/http://www.cpni.gov.uk/Docs/InternetProtocol.pdf |archive-date=2010-02-11 |url=http://www.cpni.gov.uk/Docs/InternetProtocol.pdf |title=Security Assessment of the Internet Protocol |date=July 2008 |author= Fernando Gont |publisher=[[Centre for the Protection of National Infrastructure|CPNI]]}}</ref> The IETF has been pursuing further studies.<ref name="RFC 6274">{{cite IETF |rfc=6274 |title=Security Assessment of the Internet Protocol version 4 |author=F. Gont |date=July 2011}}</ref>

==See also==
{{Portal|Internet}}
* [[ICANN]]
* [[IP routing]]
* [[List of IP protocol numbers]]
* [[List of IP version numbers]]
* [[Next-generation network]]
* [[New IP]] (proposal)

==References==
{{Reflist}}

==External links==
{{Wiktionary}}
* {{cite web |url=https://www.ict.tuwien.ac.at/lva/384.081/datacom/09-IP_Technology_v6-3_handout.pdf |author=Manfred Lindner |title=IP Technology |access-date=2018-02-11}}
* {{cite web|url=https://www.ict.tuwien.ac.at/lva/384.081/datacom/10-IP_Routing_v6-2_handout.pdf|author=Manfred Lindner|title=IP Routing|access-date=2018-02-11}}

{{IPv6}}
{{Authority control}}

[[Category:Internet Protocol| ]]
[[Category:Internet layer protocols]]
[[Category:Internet]]