IPv4 Guide, Meaning , Facts, Information and Description
IPv4 is version 4 of the Internet Protocol (IP). It was the first version of the Internet Protocol to be widely deployed, and forms the basis for most of the current Internet (as of 2004).
It is described in IETF RFC 791, which was first published in September, 1981.
IPv4 uses 32-bit addresses, limiting it to 4,294,967,296 unique addresses, many of which are reserved for special purposes such as local networks or multicast addresses, reducing the number of addresses that can be allocated as public Internet addresses.
As the number of addresses available is consumed, an IPv4 address shortage appears to be inevitable in the long run.
This limitation has helped stimulate the push towards IPv6, which is currently in the early stages of deployment, and is hoped will eventually replace IPv4.
| Table of contents |
|
2 IPv4 header format 3 Fragmentation and reassembly 4 See also 5 Further reading |
IPv4 addresses are usually written in Dot-decimal notation. Here's an example: 207.142.131.235.
But it's also possible to write in the following formats:
IPv4 address representations
| Dotted Decimal (normal) | 207.142.131.235 |
| Dotted Hexadecimal | 0xCF.0x8E.0x83.0xEB |
| Dotted Octal | 0317.0216.0203.0353 |
| Decimal | 3482223595 |
| Hexadecimal | 0xCF8E83EB |
| colspan="1" | 0 - 3 | 4 - 7 | 8 - 15 | 16 - 18 | 19 - 31 | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Version | Header length | Type of Service (now DiffServ and ECN) | Total Length | ||||||||||||||||||||||||||||
| 32 | Identification | Flags | Fragment Offset | |||||||||||||||||||||||||||||
| 64 | Time to Live | Protocol | Header Checksum | |||||||||||||||||||||||||||||
| 96 | Source Address | |||||||||||||||||||||||||||||||
| 128 | Destination Address | |||||||||||||||||||||||||||||||
| 160 | Options | |||||||||||||||||||||||||||||||
| 192 | Data | |||||||||||||||||||||||||||||||
The first header field in an IPv4 packet 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 (see below).
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. They are (in order, from high order to low order:
- Reserved, must be zero
- Don't Fragment (if set)
- More Fragments.
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.
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 are aligned on a 32-bit word boundary.
IPv4 supports the use of network elements (e.g. point-point links) which support small packet sizes. Rather than mandate link-local fragmentation and reassembly, which would require the router at the far end of the link to collect the separate pieces and reassemble the packet (a complicated process, especially when pieces may be lost due to errors on the link), a router which discovers that a packet which it is processing is too big to fit on the next link is allowed to break it into fragments (separate IPv4 packets which each carry part of the data in the original IPv4 packet), using a standardized procedure which allows the destination host to reassemble the packet from the fragments, after they are separately received there.
When a large IPv4 packet is split up into smaller fragments (which is usually, but not always, done at a router in the middle of the path from the source to the destination), the fragments are all normal IPv4 packets; i.e. they have a full IPv4 header. The original packet's data portion is split into segments which are small enough (when appended to the requisite IPv4 header) to fit into the next link; one segment of the original data is placed in each fragment. Almost all the header fields have the same value in them as the corresponding field in the original packet. In particular, all the fragments will have the same "identification" field value. The differences are:
To reassemble the fragments back into the original packet at the destination, the host looks for incoming packets with the same value in the identification field: they all belong to the same original packet. The offset and total length fields tell it where each piece goes, and how much of the original packet it fills in. It can work out the total size of the original packet because in the packet with the "more fragments" flag clear, the value of the size field in that packet (less the length of the IPv4 header, of course), plus the value in the offset field (multiplied by the 8-byte fragmentation block size), gives the total length of the original packet.
Note that a router can repeat the fragmentation process even if it only has a single fragment (e.g. at a later router along the path) - it takes the fragment, splits it up in the same manner as above to create two (or more) new fragments, and adjusts the offset and total length fields as appropriate. The only complication is that if the "more fragments" flag was zero, it needs to set it to one in all but the last new fragment. (It is relatively simple to set up the process so that the router doesn't need to know whether the packet it is fragmenting itself a fragment, or a complete packet.)
Note also that if a packet is fragmented, and some of the fragments were lost while sending them from the source to the destination, then if it is retransmitted with the same identification number, and this second copy is also fragmented (again, potentially with the loss of some fragments), then fragments from the second copy can be used to fill in the "blank spots" from the first one.
This is an Article on IPv4. Page Contains Information, Facts Details or Explanation Guide About IPv4 Fragmentation and reassembly
Note that at the destination, in any incoming packet, if either:
that packet is a fragment.See also
Further reading