Internet protocol version 4 (IPv4)

Internet protocol version 4 (IPv4) is anetwork layer protocol for packet-switched datagram communication. Figure 5.6 illustrates the standardised format of an Internet protocol datagram (IP datagramorIP packet) conforming to IPv4, as defined in RFC 791.¹¹

Internet protocol version 4 (IPv4) is quite a straightforward packet-switching protocol.

In some ways it is similar to the ITU-T packet-switching protocol, recommendation X.25, which we met in Chapter 3. But the fact that it is a connectionless, protocol rather than a connection-oriented protocol makes it different. We shall explain IP in detail by considering the contents, meaning and use of the various IP-header fields (Figure 5.6). But if you need any extra assistance on exact details of the protocol operation or precise field codings, RFCs 791 (Internet protocol version 4) and 1812 (Requirements for IPv4 routers) provide the definitive documentation.

IP Version 4 (IPv4) header format

RFC 791, in line with most other IP-suite protocol documentation, specifies the protocol headers and packet formats in terms ofwords of data rather than in terms of singleoctets¹².

Figure 5.6 IP datagram structure showing IP-header fields and IP data.

11Though IP does not correspond exactly to OSI layer 3, it nonetheless can be considered approximately equivalent.

12Anoctet is the same as abyte— i.e., 8 bits. The name octet rather than byte is commonly used in protocol specifications.

Internet protocol version 4 (IPv4) 179 In the case of the IPv4 itself, RFC 791 specifies the packet or datagram format in terms of a number of 4octet (i.e., 32-bit)words.

The IP header is always transmitted in the non-canonical format. In other words, the header fields are always sent most significant bit (MSB) first. Thus transmission generally commences at the left-hand corner of the illustrated packet format (as shown in Figure 5.6) and continues line-by-line (i.e., word-by-word) until reaching the bottom right-hand corner of the packet header. But the transmission order of bits in theIP data (i.e., user data) field (whether transmitted incanonical ornon-canonical format) is not specified.

IP Version field

Theversion field of the IPv4-header indicates the format of the Internet header. The value is set to binary ‘0100’ [decimal value 4] for IP version 4. The only other allowed values are 5 (IP version 5 was an experimentalstream protocol (also calledST2 andST2+which was not widely deployed) and 6 (IP version 6, which is currently commencing large-scale deployment).

IHL (Internet header length) field

TheInternet header length (IHL)field indicates the length of the packet header in 32 bit words.

The minimum value of this field is 5 words (5×4 octets), but with additional options, the header could be much longer, as is apparent from Figure 5.6. If necessary,padding can be used to fill out any remaining empty final portion of the final 4-octet word of theoptions field.

Type of service (TOS) field

Thetype of service (TOS)field (Figure 5.7a) is intended to indicate the relative priority to be afforded to theforwarding of the particular packet. The intention is that intermediate routers along the packet’s path handle packets not on a simplefirst-in-first-out (FIFO)basis but instead

Figure 5.7 Type of Service (TOS) and options fields of the IPv4 header.

Table 5.2 IP Precedence field determines relative priority for packet processing and forwarding IP Precedence Value decimal (binary in brackets)

TOS bits 0, 1 and 2

Table 5.3 Delay, throughput and reliability — bits (D-, T- and R-bits) of the type of service (TOS) field

TOS bit Meaning Binary value‘0’ Binary value‘1’

D-bit (TOS bit 3) Delay Normal Delay Low Delay

T-bit (TOS bit 4) Throughput Normal Throughput High Throughput

R-bit (TOS bit 5) Reliability Normal Reliability High Reliability TOS bit 6 Reserved for future use Always set to ‘0’ Not used TOS bit 7 Reserved for future use Always set to ‘0’ Not used

will process them in an order more appropriate to their relative priorities. The first three bits of the TOS-field (bits 0, 1 and 2) contain theIP precedenceindication (Table 5.2). This sets a relative priority for the packet’s processing and forwarding through the network. In addition, the TOS-field includes theD (delay), T (throughput)andR (reliability)bits (Table 5.3) which define additional specific needs of the communication. At most, two of the D, T, and/or R-bits in the TOS-field should be set. An alternative use of the TOS-field is to supportdifferentiated services (DiffServ)— as we shall discuss later in the chapter.

It is not mandatory that the type of service (TOS) field should be processed by all routers.

In the case that a router does not interpret or process this field, all packets must be processed normally (i.e., with equal precedence).

Total length of IPv4 datagram and the relationship to the path maximum transmission unit (PMTU)

Thetotal length field indicates the total length of an IP datagram (i.e., IP packet) including the IP header. The value is coded in binary and represents the total number of octets. The maximum value is 65 535. All hosts and routers which support IPv4 must be able to accept IP datagrams of at least 576 octets length without requiring fragmentation. The value 576 corresponds nominally to 512 octets of data plus a 64-octet header.

By first discovering themaximum transmission unit (MTU)length (i.e., the maximum IP-data field length — see Table 5.4) that can be carried by all the links of a given end-to-endpath, a host or source router can ensure that fragmentation will not be necessary. This process is calledpath MTU (PMTU) discovery. Fragmentation is avoided by sending packets corresponding to a packet length equal to or shorter than the PMTU. A standard method for PMTU discovery for IPv4 is defined in RFC 1191 (and for IPv6 in RFC 1981). A more pragmatic approach assumes that the PMTU is the lower of the first hop MTU and 576 octets (the recommended minimum MTU of an IPv4 router).

Internet protocol version 4 (IPv4) 181

Table 5.4 Path maximum transmission unit (PMTU) size for common types of networks

Network type Maximum message

transmission unit

Specification

Minimum IP MTU 68 octets (= 68 bytes) RFC 791

Standard IP MTU 576 octets RFC 791

X.25 576 octets RFC 877

IEEE 802.3/802.2 Ethernet LAN 1492 octets RFC 1042

X.25 1500 octets RFC 1356

PPP (Point-to-Point Protocol) 1500 octets RFC 1661

FDDI (Fibre Distributed Data Interface) 4352 octets RFC 1390 4 Mbit/s Token Ring LAN (IEEE 802.5) 4464 octets RFC 1042

ATM (Asynchronous Transfer Mode) 9180 octets RFC 1626 & RFC 2225

16 Mbit/s Token Ring 17914 octets RFC 1191

Maximum IP MTU 65535 octets RFC 791

Table 5.5 Fragmentation flag field of IPv4 header

Flag bits 0 1 2

Bit meaning Reserved DF — Do not Fragment MF — More Fragment Binary value‘0’ Always set to ‘0’ May be fragmented No more fragments follow Binary value‘1’ Not used May not be fragmented More fragments follow

Fragmentation-related fields

The second 4-octet word of the IPv4 header (octets 5 – 8) contains information regarding the fragmentation of the communication, i.e., whether the packet is entire (unfragmented) or only a single fragment of a larger message. The fragmentationflags(Figure 5.6 and Table 5.5) indicate whether the packet is or may befragmented. Typically, the use of path MTU discovery is employed to try to avoid fragmentation, and the flags are then set to ‘010’.

In the case that fragmentation is undertaken, the fragmentidentification field is used to mark all the fragments of an original packet with a common ‘packet number’. In addition, flag bit 2 (MF-bit) indicates whether more fragments will follow, or whether the current fragment is the last. The fragment offset is used during reassembly. It indicates where the fragment belongs in the original packet. The first fragment has offset value 0. Subsequent ones indicate the position of the fragment in multiples of 8 octets (64 bits) from the start of the original packet.

Time-to-live (TTL) field

Thetime-to-live (TTL)field contains an integer binary value corresponding to the duration of time in seconds for which the packet is still allowed to ‘live’. Each time the packet header is processed by a router, the value in the TTL field must be checked, and be reduced by at least 1 second. As soon as the TTL value reduces 0, the packet must be destroyed. In practice, although the TTL field is nominally the lifetime in seconds, in reality it reflects the maximum number of hops allowed to be traversed before a packet is considered to be ‘lost’

andundeliverable(and therefore ripe to be destroyed). A common initial default value setting for the TTL field is 64 (possible values are 0 – 255 seconds). Such a value would allow for the safe traversal of a path comprising around 20 routers (with a ‘safety margin’ to spare).