Internet Protocol version 4 (IPv4) is the fourth revision in the development of the Internet Protocol (IP) and the first version of the protocol to be widely deployed. Together with IPv6, it is at the core of standards-based internetworking methods of the Internet
IPv4 is a connectionless protocol for use on packet-switched Link Layer networks (e.g., Ethernet). It operates on a best effort delivery model, in that it does not guarantee delivery, nor does it assure proper sequencing or avoidance of duplicate delivery. These aspects, including data integrity, are addressed by an upper layer transport protocol , such as the Transmission Control Protocol (TCP).
The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional named: options. The IPv4 packet header consists of 20 bytes of data.
- Version:- The first header field in an IP packet is the four-bit version field. The Version field indicates the format of the internet header. Version identifies the IP version to which the packet belongs. This four-bit field is set to binary 0100 to indicate version 4 (IPv4) or binary 0110 to indicate version 6 (IPv6).
- Header length or Internet Header Length (IHL) :- The second field (4 bits) is the Internet Header Length (IHL) telling the number of 32-bit words in the header. Since an IPv4 header may contain a variable number of options, this field specifies the size of the header (this also coincides with the offset to the data). The minimum value for this field is 5 , which is a length of 5×32 = 160 bits = 20 bytes. Being a 4-bit value, the maximum length is 15 words (15×32 bits) or 480 bits = 60 bytes.
- Type of Service(ToS):– now known as Differentiated Services Code Point (DSCP). The TOS field is used to carry information to provide quality of service features. New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP (VoIP) that is used for interactive data voice exchange.
TOS allows the selection of a delivery service in terms of precedence, throughput, delay, reliability, and monetary cost.
Fig:-(a) Type of Service and (b) DSCP & ECN
- Explicit Congestion Notification (ECN) :-It allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is only effective when supported by the underlying network.
- Total Length:- This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 bytes — the maximum value of a 16-bit word. The minimum size datagram that 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.
- Identification:– This field is an identification field and 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.
- Flags:–A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):
- bit 0: Reserved; must be zero.
- bit 1: Don’t Fragment (DF)
- bit 2: More Fragments (MF)
- Don’t Fragment:- Sets the Don’t Fragment bit in sent packets. When an IP datagram has its DF flag set, intermediate devices are not allowed to fragment it so if it needs to travel across a network with a MTU(Maximum Transmission Unit) smaller that datagram length the datagram will have to be dropped. Normally an ICMP Destination Unreachable message is generated and sent back to the sender.
- More Fragments:- Sets the More Fragments bit in sent packets. The MF flag is set to indicate the receiver that the current datagram is a fragment of some larger datagram. When set to zero it indicates that the current datagram is either the last fragment in the set or that it is the only fragment.
- Fragment Offset:-The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528 bytes which would exceed the maximum IP packet length of 65,535 bytes with the header length included (65,528 + 20 = 65,548 bytes).
- Time To Live (TTL):-It is of 8 bit field. This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.
<hops>must be a number in the range [0–255].
- Protocol:-This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of IP protocol numbers.
- Header Checksum:- The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Errors in the data field must be handled by the encapsulated protocol and both UDP and TCP have checksum fields.
As the TTL field is decremented on each hop, a new checksum must be computed each time. The checksum field is the 16-bit one’s complement of the one’s complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
- Source address :- Sets the source IP address. This option lets you specify a custom IP address to be used as source IP address in sent packets. This allows spoofing the sender of the packets.
<addr>can be an IPv4 address or a hostname.
- Destination address :- An IPv4 address indicating the receiver of the packet. As with the Source address, this may be changed in transit by a network address translation device.
- Options:-Additional header fields may follow the destination address field, but these are not often used. The value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integral number of 32-bit words). The list of options may be terminated with an EOL (End of Options List) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header.
The option field is variable in length. There may be zero or more options. There are two cases for the format of an option:
Case 1: A single octet of option-type.
Case 2: An option-type octet, an option-length octet, and the actual option-data octets.
The option-length octet counts the option-type octet and the option-length octet as well as the option-data octets.
The option-type octet is viewed as having 3 fields:
1 bit copied flag,
2 bits option class,
5 bits option number.
The copied flag indicates that this option is copied into all fragments on fragmentation.
0 = not copied
1 = copied
The option classes are:
0 = control
1 = reserved for future use
2 = debugging and measurement
3 = reserved for future use
- Data:- The data portion of the packet is not included in the packet checksum. Its contents are interpreted based on the value of the Protocol header field.
In a typical IP implementation, standard protocols such as TCP and UDP are implemented in the OS kernel for performance reasons. Other protocols such as ICMP may be partially implemented by the kernel, or implemented purely in user software.
Some of the common protocols for the data portion are listed below:
|Protocol number||Protocol name||Abbreviation|
|1||Internet control message protocol||ICMP|
|2||Internet group management protocol||IGMP|
|6||Transmission control protocol||TCP|
|17||User Datagram protocol||UDP|
|89||Open Shortest path first||OSPF|
|132||Stream Control Transmission Protocol||SCTP|
This article on IPv4 header was submitted by Rajwinder Kaur of IT 6th Semester (Batch 2009) of CTIT. The resources used by her are mentioned below:
Book Referred – Cisco Certified Network Associate (Todd Lammle)