The Internet Protocol (IP) is a data-oriented protocol used by source and destination hosts for communicating data across a packet-switched internetwork.
Data in an IP internetwork is sent in blocks referred to as packets or datagrams (the terms are basically synonomous in IP). In particular, in IP no setup is needed before a host tries to send packets to a host it has previously not communicated with.
The Internet Protocol provides an unreliable datagram service (also called best effort); i.e. it makes almost no guarantees about the packet. The packet may arrived damaged, it may be out of order (compared to other packets sent between the same hosts), it may be duplicated, or it may be dropped entirely. If the application needs reliability, this is added by the Transport layer.
Packet switches, or internetwork routers, are used to forward IP datagrams across interconnected layer 2 networks. The lack of any delivery guarantees means that the design of packet switches is made much simpler. (Note that if the network does drop, reorder or otherwise damage a lot of packets, the performance seen by the user will be poor, so most network elements do try hard to not do these things - hence the best effort term. However, an occasional error will produce no noticeable effect.)
IP is the common element found in today's public Internet. It is described in IETF RFC 791, which was first published in September, 1981. This document describes the current and most popular network layer protocol in use today. This version of the protocol is assigned as version 4. IPv6 is the proposed successor to IPv4; the Internet is slowly running out of addresses, and IPv6 has 128-bit source and destination addresses, providing more addresses than IPv4's 32 bits. Versions 0 through 3 were either reserved or unused. Version 5 was used for an experimental stream protocol. Other version numbers have been assigned, usually for experimental protocols, but have not been widely used.
{| align="center" border="1" cellpadding="3" cellspacing="1"
|- align="center"
! colspan="1"|+
! colspan="4"|0 - 3
! colspan="4"|4 - 7
! colspan="8"|8 - 15
! colspan="3"|16 - 18
! colspan="13"|19 - 31
|- align="center"
! colspan="1"|0
| colspan="4"|Version
| colspan="4"|Header length
| colspan="8"|Type of Service
The first header field in an IPv4 datagram is the 4-bit version field.
The second field is a 4-bit Internet Header Length (IHL) telling the number of 32-bit words in the IPv4 header. Since an IPv4 header may contain a variable number of options, this field essentially specifies the offset to the data portion of an IPv4 datagram. A minimum IPv4 header is 20 bytes long, so the minimum value in decimal in the IHL field would be 5.
In RFC 791, the following 8 bits were allocated to a Type of Service (ToS) field - now DiffServ and ECN. The original intention was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internetwork. For instance, one host could set its IPv4 datagrams' ToS field value to prefer low delay, while another might prefer high reliability. In practice, the ToS field has not been widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits. These bits have been redefined and most recently through DiffServ working group in the IETF and the Explicit Congestion Notification codepoints (see RFC 3168).
The next 16-bit IPv4 field defines the entire datagram size, including header and data, in 8-bit bytes. The minimum-length datagram is 20 bytes and the maximum is 65535. The maximum size datagram which any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or packet switch in IPv4, and in the host only in IPv6.
The next 16-bit field is an identification field. This field is primarily used for uniquely identifying fragments of an original IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet tracing information to datagrams in order to help trace back datagrams with spoofed source addresses.
A 3-bit field follows and is used to control or identify fragments.
The fragment offset field is 13-bits long, and allows a receiver determine the place of a particular fragment in the original IP datagram.
An 8-bit time to live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internetwork. Historically the TTL field limited a datagram's lifetime in seconds, but has come to be a hop count field. Each packet switch (or router) that a datagram crosses decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded by a packet switch and is discarded.
An 8-bit Protocol field follows. This field defines the next protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of Protocol numbers. Common protocols and their decimal values include ICMP (1), TCP (6) and UDP (17).
The following field is a 16-bit checksum field for the IPv4 datagram header. Some values in a IPv4 datagram header may change at each packet switch hop, so the checksum must be adjusted on its way through an internetwork.
The checksum is followed by a 32-bit source address and 32-bit destination address respectively. (Note: IPv6 source and destination addresses are 128 bits each.)
Additional header fields (called options) may follow the destination address field, but these are not often used. Option fields may be followed by a pad field which ensures that the user data is aligned on a 32-bit word boundary. (In IPv6, options move out of the standard header and are specified by a Next Protocol field, similar in function to IPv4's Protocol field.)
Perhaps the most complex aspects of IP are addressing and routing. Addressing refers to how end hosts are assigned IP addresses and how subnetworks of IP host addresses are divided and grouped together. IP routing is performed by all hosts, but most famously by internetwork routers, which typically use either interior gateway protocols (IGPs) or external gateway protocols (EGPs) to help make IP datagram forwarding decisions across IP connected networks.
See also: Internet protocol suite, Classes of IP addresses, IANA,
List_of_well_known_ports_(computing)IPv4 Header Format
(now DiffServ and ECN)
| colspan="16"|Total Length
|- align="center"
! colspan="1"|32
| colspan="16"|Identification
| colspan="3"|Flags
| colspan="13"|Fragment Offset
|- align="center"
! colspan="1"|64
| colspan="8"|Time to Live
| colspan="8"|Protocol
| colspan="16"|Header Checksum
|- align="center"
! colspan="1"|96
| colspan="32"|Source Address
|- align="center"
! colspan="1"|128
| colspan="32"|Destination Address
|- align="center"
! colspan="1"|160
| colspan="32"|Options
|- align="center"
! colspan="1"|192
| colspan="32"|
Data
|}IPv4 Addressing and Routing