IP Packet Header

Figure 1-2 shows the format of the IP packet header, specified in RFC 791. Most fields in this packet have some importance to routing.

Figure 1-2. IP packet protocol.

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). This chapter is concerned primarily with IPv4, whereas Chapter 2, "IPv6 Overview," focuses on IPv6. Table 1-1 shows all currently assigned version numbers, along with a few of the relevant RFCs. All versions other than 4 and 6 (built on an earlier proposal called Simple Internet Protocol, or SIP, which also carried a version number of 6) now exist only as "culture," and it will be left to the curious to read their cited RFCs.

Table 1-1. IP version numbers.
Number	Version	RFC
0	Reserved
13	Unassigned
4	Internet Protocol version 4 (IPv4)	791
5	ST Datagram Mode	1190
6	Simple Internet Protocol (SIP)
6	Internet Protocol version 6 (IPv6)	1883
7	TP/IX	1475
8	P Internet Protocol (PIP)	1621
9	TCP and UDP over Bigger Addresses (TUBA)	1347
1014	Unassigned
15	Reserved

Header Length is a four-bit field that tells, as the name implies, the length of the IP header in 32-bit words. This field is included because the Options field (described later in this section) can vary in size. The minimum length of the IP header is 20 octets, and the options might increase this size up to a maximum of 60 octetsthe maximum length in 32-bit words that can be described by this field.

Type of Service (TOS) is an eight-bit field that can be used for specifying special handling of the packet. This field actually can be broken down into two subfields: Precedence and TOS. Precedence sets a priority for the packet, the way a package might be sent overnight, two-day delivery, or general post. TOS allows the selection of a delivery service in terms of throughput, delay, reliability, and monetary cost. Although this field is not commonly used (all the bits will usually be set to zero), early specifications of the Open Shortest Path First (OSPF) protocol called for TOS routing. Also, the Precedence bits are occasionally used in quality of service (QoS) applications. Part (a) of Figure 1-3 summarizes the eight TOS bits; for more information, see RFC 1340 and RFC 1349.

Figure 1-3. Type of Service (a) or DiffServ and ECN (b) field.

In recent years, the ToS field has been redefined as a part of the Differentiated Services (DiffServ) framework.^[3] This framework creates a much more flexible handling of IP packets than was allowed by the relatively rigid ToS definitions. With DiffServ, you can define service classes on a router and then sort packets into these classes. The router can then queue and forward packets with different levels of priority, according to their classification. Each queuing and forwarding treatment is called a Per-Hop Behavior (PHB). While DiffServ defines the framework or architecture, the mechanism itself is called Differentiated Class of Service or simply Class of Service (COS).

^[3] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, December 1998.

Part (b) of Figure 1-3 shows how the ToS field has been redefined, so that the first six bits now compose the DiffServ Code Point (DSCP). With these six bits you can define, either arbitrarily or according to service classes predefined in the DiffServ architecture, up to 64 different service classes that can then be sorted into PHBs. Note that the field in the IP header remains 8 bits; the DiffServ architecture just redefines how a router interprets the value in that field.

Explicit Congestion Notification (ECN), in part (b) of Figure 1-3, is used by some routers to signal support for Explicit Congestion Notification and, when it is supported, the bits can be used to signal congestion (ECN = 11).^[4]

^[4] K. Ramakrishnan, "The Addition of Explicit Congestion Notification (ECN) to IP," RFC 3168, September 2001.

Total Length is a 16-bit field specifying the total length of the packet, including the header, in octets. By subtracting the header length, a receiver might determine the size of the packet's data payload. Because the largest decimal number that can be described with 16 bits is 65,535, the maximum possible size of an IP packet is 65,535 octets.

Identifier is a 16-bit field used in conjunction with the Flags and Fragment Offset fields for fragmentation of a packet. Packets must be fragmented into smaller packets if the original length exceeds the Maximum Transmission Unit (MTU) of a data link through which they pass. For example, consider a 5000-byte packet traveling through a network. It encounters a data link with a 1500 byte MTU. That is, the frame can contain a maximum packet size of 1500 bytes. The router that places the packet onto this data link must first fragment the packet into chunks of no more than 1500 octets each. The router then marks each fragment with the same number in the Identifier field so that a receiving device can identify the fragments that go together.^[5]

^[5] A fragmented packet is not reassembled at the other end of the data link; the packet stays fragmented until it reaches its final destination.

Flags is a three-bit field in which the first bit is unused. The second is the Don't Fragment (DF) bit. When the DF bit is set to one, a router cannot fragment the packet. If the packet cannot be forwarded without fragmenting, the router drops the packet and sends an error message to the source. This function enables the testing of MTUs in a network. The DF bit can be set using the Extended Ping utility in IOS, as shown in Example 1-1.

Example 1-1. The IOS Extended Ping utility allows the setting of the DF bit to test MTUs across a network. In this ping Output, the largest MTU of the path to destination 172.16.113.17 is 1478 octets.

Handy#ping Protocol [ip]: Target IP address: 172.16.113.17 Repeat count [5]: 1 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address: Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: r Number of hops [9]: Loose, Strict, Record, Timestamp, Verbose[RV]: Sweep range of sizes [n]: y Sweep min size [76]: 500 Sweep max size [18024]: 2000 Sweep interval [1]: 500 Type escape sequence to abort. Sending 4, [500..2000]-byte ICMP Echos to 172.16.113.17, timeout is 2 seconds: Packet has IP options:  Total option bytes= 39, padded length=40  Record route: <*> 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0          0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Reply to request 0 (16 ms) (size 500).  Received packet has options  Total option bytes= 40, padded length=40  Record route: 172.16.192.5 172.16.113.18 172.16.113.17 172.16.113.17          172.16.192.6 172.16.192.5 <*> 0.0.0.0 0.0.0.0 0.0.0.0  End of list Reply to request 1 (24 ms) (size 1000).  Received packet has options  Total option bytes= 40, padded length=40  Record route: 172.16.192.5 172.16.113.18 172.16.113.17 172.16.113.17          172.16.192.6 172.16.192.5 <*> 0.0.0.0 0.0.0.0 0.0.0.0  End of list Reply to request 2 (28 ms) (size 1500).  Received packet has options  Total option bytes= 40, padded length=40  Record route: 172.16.192.5 172.16.113.18 172.16.113.17 172.16.113.17          172.16.192.6 172.16.192.5 <*> 0.0.0.0 0.0.0.0 0.0.0.0  End of list Unreachable from 172.16.192.6, maximum MTU 1478 (size 2000).  Received packet has options  Total option bytes= 39, padded length=40  Record route: <*> 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0          0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Success rate is 75 percent (3/4), round-trip min/avg/max = 16/22/28 ms Handy#

The third bit is the More Fragments (MF) bit. When a router fragments a packet, it sets the MF bit to one in all but the last fragment so that the receiver knows to keep expecting fragments until it encounters a fragment with MF = 0.

Fragment Offset is a 13-bit field that specifies the offset, in units of eight octets, from the beginning of the header to the beginning of the fragment.^[6] Because fragments might not always arrive in sequence, the Fragment Offset field allows the pieces to be reassembled in the correct order.

^[6] Units of eight octets are used so that a maximum-size packet of 65,535 bytes might be described with 13 bits.

Note that if a single fragment is lost during a transmission, the entire packet must be resent and refragmented at the same point in the network. Therefore, error-prone data links could cause a disproportionate delay. And if a fragment is lost because of congestion, the retransmission of the entire series of fragments might increase the congestion.

Time to Live (TTL) is an eight-bit field that will be set with a certain number when the packet is first generated. As the packet is passed from router to router, each router will decrement this number. If the number reaches zero, the packet will be discarded and an error message will be sent to the source. This process prevents "lost" packets from wandering endlessly through a network.

As originally conceived, the TTL was specified in seconds; if a packet was delayed more than a second in a router, the router would adjust the TTL accordingly. However, this approach is difficult to implement and has never been generally supported. Modern routers simply decrement the TTL by one, no matter what the actual delay, so the TTL is really a hop count.^[7] The recommended default TTL is 64, although values such as 15 and 32 are not uncommon.

^[7] As you will read in Chapter 2, the equivalent field in the IPv6 header has been renamed Hop Limit to more accurately reflect its true usage.

Some trace utilities, such as the IOS trace command, make use of the TTL field. If the router is told to trace the route to a host address such as 10.11.12.13, the router will send three packets with the TTL set to one; the first router will decrement it to zero, drop the packets, and send back error messages to the source. By reading the source address of the error messages, the first router on the path is now known. The next three packets will be sent with a TTL of two. The first router decrements to one, the second to zero, and an error message is received from the second router. The third set has a TTL of three, and so forth, until the destination is found. All routers along the network path will have identified themselves. Example 1-2 shows the output from an IOS trace.

Example 1-2. The trace utility uses the TTL field to identify routers along a route. Asterisks indicate timed-out packets.

Elvis#traceroute www.cisco.com Type escape sequence to abort. Tracing the route to cio-sys.Cisco.COM (192.31.7.130)   1 172.18.197.17 4 msec   4 msec 4 msec   2 ltlrichard-s1-13.hwy51.com (172.18.197.1) 36 msec 44 msec  2536 msec   3 cperkins-rtr-fr2.hwy51.com (10.168.204.3) 104 msec 64 msec *   4 cberry.hwy51.com (10.168.193.1)  92 msec *   5 jllewis-inner.hwy51.com (10.168.207.59) 44 msec  *  44 msec   6 bholly-fw-outer-rt.hwy51.com (10.168.207.94) 44 msec *   48 msec   7 sl-stk-14-S10/0:6-512k.sprintlink.net (144.228.214.107) 92 msec *   8 sl-stk-2-F1/0/0.sprintlink.net  (144.228.40.2) 52 msec 1156 msec *   9 sl-mae-w-H1/0-T3.sprintlink.net  (144.228.10.46) 100 msec 124 msec 2340 msec  10 sanjose1-br1.bbnplanet.net  (198.32.136.19) 2264 msec   164 msec *  11 paloalto-br2.bbnplanet.net  (4.0.1.10) 64 msec 60 msec    *  12 su-pr2.bbnplanet.net  (131.119.0.218) 76 msec 76 msec    76 msec  13 cisco.bbnplanet.net  (131.119.26.10) 2560 msec 76 msec    936 msec  14 sty.cisco.com  (192.31.7.39)  84 msec 72 msec  *  15 cio-sys.Cisco.COM  (192.31.7.130) 60 msec  *   64 msec Elvis#

Protocol is an eight-bit field that gives the "address," or protocol number, of the host-to-host or transport layer protocol for which the information in the packet is destined. Table 1-2 shows a few of the more common of the 100 or so different protocol numbers currently assigned.

Table 1-2. A few well-known protocol numbers.
Protocol Number	Host-to-Host Layer Protocol
1	Internet Control Message Protocol (ICMP)
2	Internet Group Management Protocol (IGMP)
4	IP in IP (encapsulation)
6	Transmission Control Protocol (TCP)
17	User Datagram Protocol (UDP)
45	Inter-Domain Routing Protocol (IDRP)
46	Resource Reservation Protocol (RSVP)
47	Generic Routing Encapsulation (GRE)
54	NBMA Next Hop Resolution Protocol (NHRP)
88	Cisco Internet Gateway Routing Protocol (IGRP)
89	Open Shortest Path First (OSPF)

Header Checksum is the error detection field for the IP header. The checksum is not calculated for the encapsulated data; UDP, TCP, and ICMP have their own checksums for doing this. The field contains a 16-bit one's complement checksum, calculated by the originator of the packet. The receiver will again calculate a 16-bit one's complement sum, including the original checksum. If no errors have occurred during the packet's travels, the resulting checksum will be all ones. Remember that each router decrements the TTL; therefore, the checksum must be recalculated at each router. RFC 1141 discusses some strategies for simplifying this calculation.

Source and Destination Addresses are the 32-bit IP addresses of the originator of the packet and the destination of the packet. The format of IP addresses is covered in the next section, "IPv4 Addresses."

Options is a variable-length field and, as the name says, is optional. Space is added to the packet header to contain either source-generated information or for other routers to enter information; the options are used primarily for testing. The most frequently used options are

Loose source routing, in which a series of IP addresses for router interfaces is listed. The packet must pass through each of these addresses, although multiple hops might be taken between the addresses.
Strict source routing, where again a series of router addresses is listed. Unlike loose source routing, the packet must follow the route exactly. If the next hop is not the next address on the list, an error occurs.
Record route provides room for each router to enter the address of its outgoing interface as the packet transits so that a record is kept of all routers the packet encounters. Record route provides a function similar to trace except that the outgoing interfaces, both on the path to the destination and on the return path, are recorded.
Timestamp is an option similar to record route except each router also enters a timestamp: the packet not only keeps track of where it has been but also records when it was there.

All these options might be invoked by using the Extended Ping on Cisco routers. Record route is used in Example 1-1, loose source routing and timestamp are used in Example 1-3, and strict source routing is used in Example 1-4.

Example 1-3. The Cisco Extended Ping can be used to set parameters in the Options field of the IP header. In this example, loose source routing and timestamp are used.

Handy#ping Protocol [ip]: Target IP address: 172.16.113.9 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: l Source route: 172.16.113.14 172.16.113.10 Loose, Strict, Record, Timestamp, Verbose[LV]: t Number of timestamps [ 6 ]: 2 Loose, Strict, Record, Timestamp, Verbose[LTV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.113.9, timeout is 2 seconds: Packet has IP options: Total option bytes= 23, padded length=24   Loose source route: <*> 172.16.113.14 172.16.113.10   Timestamp: Type 0. Overflows: 0 length 12, ptr 5     >>Current pointer<<     Time= 0     Time= 0 Request 0 timed out Reply to request 1 (76 ms). Received packet has options   Total option bytes= 24, padded length=24   Loose source route: 172.16.113.13 172.16.192.6 <*>   Timestamp: Type 0. Overflows: 6 length 12, ptr 13     Time= 80FF4798     Time= 80FF4750     >>Current pointer<<   End of list Request 2 timed out Reply to request 3 (76 ms). Received packet has options   Total option bytes= 24, padded length=24   Loose source route: 172.16.113.13 172.16.192.6 <*>   Timestamp: Type 0. Overflows: 6 length 12, ptr 13   Time= 80FF4FC0   Time= 80FF4F78   >>Current pointer<< End of list Request 4 timed out Success rate is 40 percent (2/5), round-trip min/avg/max = 76/76/76 ms Handy#

Example 1-4. Extended Ping is used here to set strict source routing in the ping packets.

Handy#ping Protocol [ip]: Target IP address: 172.16.113.10 Repeat count [5]: 2 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: s Source route: 172.16.192.6 172.16.113.17 172.16.113.10 Loose, Strict, Record, Timestamp, Verbose[SV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 172.16.113.10, timeout is 2 seconds: Packet has IP options: Total option bytes= 15, padded length=16   Strict source route: <*> 172.16.192.6 172.16.113.17 172.16.113.10 Reply to request 0 (80 ms). Received packet has options   Total option bytes= 16, padded length=16   Strict source route: 172.16.113.10 172.16.113.17 172.16.192.6 <*>   End of list Reply to request 1 (76 ms). Received packet has options   Total option bytes= 16, padded length=16   Strict source route: 172.16.113.10 172.16.113.17 172.16.192.6 <*>   End of list Success rate is 100 percent (2/2), round-trip min/avg/max = 76/78/80 ms Handy#

Padding ensures that the header ends on a 32-bit boundary by adding zeros after the option field until a multiple of 32 is reached.

A protocol analyzer capture of an IP header is shown in Example 1-5. Compare the information shown with Figure 1-2.

Example 1-5. You can see the fields of an IP packet's header and the values contained in each field in this protocol analyzer display.

Internet Protocol, Src Addr: 172.16.1.102 (172.16.1.102), Dst Addr: 224.0.0.5 (224.0.0.5)     Version: 4     Header length: 20 bytes     Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)     Total Length: 64     Identification: 0x6e61 (28257)     Flags: 0x00     Fragment offset: 0     Time to live: 1     Protocol: OSPF IGP (0x59)     Header checksum: 0xbcc8 (correct)     Source: 172.16.1.102 (172.16.1.102)     Destination: 224.0.0.5 (224.0.0.5)