The IP Packet Header
| Figure 2.2 shows the format of the IP packet header, specified in RFC 791. Most fields in this packet have some importance to routing. Figure 2.2. The IP packet protocol. Version identifies the I P version to which the packet belongs. This four-bit field is usually set to binary 0100; version 4 (IPv4) is in current, common use. A newer version of the protocol, not yet in widespread deployment, is version 6 (IPv6), sometimes referred to as" next -generation IP"(IPng). All currently assigned version numbers can be seen in Table 2.1, 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. Header Length is a four-bit field that tells , as the name implies, the length of the IP header. The reason this field is included is that 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 may increase this size up to a maximum of 24 octets. This field describes the length of the header in terms of 32-bit words ” five for the minimum 160-bit size and six for the maximum. Table 2.1. IP version numbers.
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, 2-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. Figure 2.3 summarizes the eight TOS bits; for more information , see RFC 1340 and RFC 1349. Figure 2.3. The Type of Service field. 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 may 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 5,000-byte packet traveling through an internetwork. It encounters a data link whose MTU is 1,500 bytes ” that is, the frame can contain a maximum packet size of 1,500 bytes. The router that places the packet onto this data link must first fragment the packet into chunks of no more than 1,500 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. [1]
Note The DF bit can be used in troubleshooting to determine a path's MTU. 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 an internetwork. The DF bit can be set using the Extended Ping utility on Cisco routers, as shown in Figure 2.4. Figure 2.4. The Cisco Extended Ping utility allows the setting of the DF bit to test MTUs across an internetwork. In the figure, the largest MTU of the path to destination 172.16.113.17 is 1,478 octets. 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. [2] Because fragments may not always arrive in sequence, the Fragment Offset field allows the pieces to be reassembled in the correct order.
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 internetwork. 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 may 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 sen t to the source. This process prevents "lost" packets from wandering endlessly through an internetwork. 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 is rarely supported. Most routers simply decrement the TTL by one, no matter what the actual delay, so the TTL is really a hop count. The recommended default TTL is 64, although values such as 15 and 32 are not uncommon. Note Using trace to learn the route to a destination Some trace utilities, such as Cisco's 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 internetwork path will have identified themselves . Figure 2.5 shows the output from a trace on a Cisco router. Figure 2.5. The trace utility uses the TTL field to identify routers along a route. Asterisks indicate timed-out packets. 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 2.2 shows a few of the more common of the 100 different protocol numbers currently assigned. Table 2.2. A few well-known protocol numbers.
Header Checksum is the error correction 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, "IP Addresses." Note Using the Options field to test routers and paths Options is a variable-length field and, as the name implies, 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 follow.
All these options may be invoked by using the Extended Ping on Cisco routers. Record route is used in Figure 2.4, loose source routing and timestamp are used in Figure 2.6, and strict source routing is used in Figure 2.7. Figure 2.6. The Cisco Extended Ping may be used to set parameters in the Options field of the IP header. In this example, loose source routing and timestamp are used. Figure 2.7. Extended Ping is used here to set strict source routing in the ping packets. 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 Figure 2.8. Compare the information shown with Figure 2.2. Figure 2.8. You can see the fields of an IP packet's header and the values contained in each field in this protocol analyzer display. |
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}