IPv4

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 may eventually replace IPv4.

Contents

1 IPv4 address representations 2 IPv4 header format 3 Fragmentation and reassembly 4 See also 5 Further reading 6 External links

IPv4 address representations

IPv4 addresses are usually written in Dot-decimal notation. Here is an example: 207.142.131.235. But it is also possible to write in the following formats:

Dotted Decimal (normal)	207.142.131.235
Dotted Hexadecimal	0xCF.0x8E.0x83.0xEB
Dotted Octal	0317.0216.0203.0353
Decimal	3482223595
Hexadecimal	0xCF8E83EB

The above IP addresses should work in most browsers and at the time of writing point to wikipedia.org.

IPv4 header format

+	Bits 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 (5×4 = 20 bytes). That is, it represents the total number of bytes occupied by header as a multiple of 4 bytes.

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.

The fragment offset field is 13-bits long, and allows a receiver to determine the place of a particular fragment in the original IP datagram, measured in units of 8-byte blocks.

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. Note that 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 use of the LSSR and SSRR (Loose and Strict Source and Record Route) options is discouraged because they create security concerns; packets with them are therefore usually blocked by routers.

Fragmentation and reassembly

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:

• The "total length" field will be smaller; it will be set to the size of each fragment
• The "more fragments" single bit flag will be one in all but the last fragment
• The "fragment offset" field will be non-zero in all but the first fragment

Note that at the destination, in any incoming packet, if either:

• The "more fragments" single bit flag is one, or
• The "fragment offset" field is non-zero

that packet is a fragment.

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 does not need to know whether the packet it is fragmenting is 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.

See also

• Internet protocol suite
• Classes of IP addresses
• Subnetwork
• IPv4 address exhaustion
• IPv4 subnetting reference
• List of well-known ports (computing)
• IANA
• IPv6
• Internet Protocol

Further reading

• RFC 791 - Internet Protocol
• RFC 3168 - Explicit congestion notification

External links

• Internet Assigned Numbers Authority (IANA) (http://www.iana.org)
• Show your IP address (http://ip-number.com)
• My Ip Address (http://www.myipaddress.in) - Shows your Ip address, city and country
• My IP Tool (http://www.iptool.us/extensions/iptool.php) Firefox extension that retrieves your ip addresses.da:IPv4

de:IPv4 es:IPv4 fr:IPv4 ko:IPv4 it:IPv4 no:IPv4 pl:IPv4 sk:IPv4 zh:IPv4