IP Packet

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 two, "IPv6 Overview," focuses on IPv6. Table 1-1 shows all at the moment assigned version numbers, in addition to some of the relevant RFCs. All versions aside from 4 and 6 (built on an earlier proposal referred to as Simple World wide web Protocol, or SIP, which also carried a version quantity of 6) now exist only as "culture," and it's going to be left towards the curious to read their cited RFCs.

Table 1-1. IP version numbers.

Number

Version

RFC

0

Reserved

13

Unassigned

4

World wide web Protocol version 4 (IPv4)

791

5

ST Datagram Mode

1190

6

Simple World wide web Protocol (SIP)

6

World wide web Protocol version 6 (IPv6)

1883

7

TP/IX

1475

8

P World wide web Protocol (PIP)

1621

9

TCP and UDP more than Larger Addresses (TUBA)

1347

1014

Unassigned

15

Reserved

Header Length is usually a four-bit field that tells, because the name implies, the length of the IP header in 32-bit words. This field is included mainly because the Possibilities field (described later in this section) can vary in size. The minimum length of the IP header is 20 octets, along with the alternatives might increase this size as much as a maximum of 60 octetsthe maximum length in 32-bit words that can be described by this field.

Kind of Service (TOS) is an eight-bit field that can be utilized for specifying unique handling of the packet. This field essentially might be broken down into two subfields: Precedence and TOS. Precedence sets a priority for the packet, the way a package could be sent overnight, two-day delivery, or common post. TOS will allow the choice of a delivery service in terms of throughput, delay, reliability, and monetary expense. Although this field will not be typically utilized (all of the bits will generally be set to zero), early specifications of the Open Shortest Path Very first (OSPF) protocol referred to as for TOS routing. Also, the Precedence bits are occasionally utilized in quality of service (QoS) applications. Portion (a) of Figure 1-3 summarizes the eight TOS bits; for far more data, see RFC 1340 and RFC 1349.

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

image

In current years, the ToS field has been redefined as a component of the Differentiated Services (DiffServ) framework.3 This framework creates a substantially far more flexible handling of IP packets than was allowed by the reasonably rigid ToS definitions. With DiffServ, you could define service classes on a router then sort packets into these classes. The router can then queue and forward packets with distinct levels of priority, in accordance with their classification. Each and every queuing and forwarding treatment is called a Per-Hop Behavior (PHB). Though DiffServ defines the framework or architecture, the mechanism itself is called Differentiated Class of Service or merely Class of Service (COS).

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

Portion (b) of Figure 1-3 shows how the ToS field has been redefined, in order that the first six bits now compose the DiffServ Code Point (DSCP). With these six bits you could define, either arbitrarily or in accordance with service classes predefined inside the DiffServ architecture, as much as 64 distinct service classes that can then be sorted into PHBs. Note that the field inside 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 component (b) of Figure 1-3, is utilized by some routers to signal support for Explicit Congestion Notification and, when it is actually supported, the bits might be utilized 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 usually a 16-bit field specifying the total length of the packet, which includes the header, in octets. By subtracting the header length, a receiver might decide the size of the packet's information payload. Due to the fact the largest decimal number that can be described with 16 bits is 65,535, the maximum feasible size of an IP packet is 65,535 octets.

Identifier is usually a 16-bit field utilized in conjunction with the Flags and Fragment Offset fields for fragmentation of a packet. Packets should be fragmented into smaller sized packets if the original length exceeds the Maximum Transmission Unit (MTU) of a information link by means of which they pass. By way of example, contemplate a 5000-byte packet traveling by means of a network. It encounters a information link with a 1500 byte MTU. That's, the frame can include a maximum packet size of 1500 bytes. The router that places the packet onto this information link will need to initially fragment the packet into chunks of no over 1500 octets every single. The router then marks every single fragment with the identical number inside the Identifier field in order that a receiving device can identify the fragments that go with each other.5

5 A fragmented packet will not be reassembled in the other end of the information link; the packet stays fragmented till it reaches its final destination.

Flags is usually a three-bit field in which the first bit is unused. The second may be the Don't Fragment (DF) bit. When the DF bit is set to 1, a router can not fragment the packet. When the packet can not be forwarded with out fragmenting, the router drops the packet and sends an error message towards the source. This function enables the testing of MTUs inside a network. The DF bit might be set utilizing the Extended Ping utility in IOS, as shown in Example 1-1.

Example 1-1. The IOS Extended Ping utility will allow 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:
Kind of service 0:
Set DF bit in IP header? no: y
Validate reply information? no:
Information pattern 0xABCD:
Loose, Strict, Record, Timestamp, Verbosenone: r
Number of hops 9:
Loose, Strict, Record, Timestamp, VerboseRV:
Sweep range of sizes n: y
Sweep min size 76: 500
Sweep max size 18024: 2000
Sweep interval 1: 500
Kind escape sequence to abort.
Sending 4, 500..2000-byte ICMP Echos to 172.16.113.17, timeout is two seconds:
Packet has IP alternatives: Total alternative 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 alternatives
Total alternative 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
Finish of list

Reply to request 1 (24 ms) (size 1000). Received packet has alternatives
Total alternative 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
Finish of list

Reply to request two (28 ms) (size 1500). Received packet has alternatives
Total alternative 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
Finish of list

Unreachable from 172.16.192.6, maximum MTU 1478 (size 2000).
Received packet has alternatives
Total alternative 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

Achievement rate is 75 percent (3/4), round-trip min/avg/max = 16/22/28 ms
Handy#

The third bit may be the Far more Fragments (MF) bit. When a router fragments a packet, it sets the MF bit to 1 in all but the last fragment in order that the receiver knows to keep expecting fragments till it encounters a fragment with MF = 0.

Fragment Offset is usually a 13-bit field that specifies the offset, in units of eight octets, from the starting of the header towards the starting of the fragment.6 Due to the fact fragments might not always arrive in sequence, the Fragment Offset field will allow the pieces to be reassembled inside the appropriate order.

6 Units of eight octets are utilized in order that a maximum-size packet of 65,535 bytes could be described with 13 bits.

Note that if a single fragment is lost for the duration of a transmission, the entire packet should be resent and refragmented in the identical point inside the network. Thus, error-prone information links could result in a disproportionate delay. And if a fragment is lost mainly 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 initially generated. Because the packet is passed from router to router, every single router will decrement this number. When the number reaches zero, the packet are going to be discarded and an error message are going to be sent towards the source. This process prevents "lost" packets from wandering endlessly by means of a network.

As originally conceived, the TTL was specified in seconds; if a packet was delayed over a second inside a router, the router would adjust the TTL accordingly. On the other hand, this method is challenging to implement and has by no means been frequently supported. Modern routers merely decrement the TTL by 1, no matter what the actual delay, so the TTL is definitely a hop count.7 The recommended default TTL is 64, even though values for instance 15 and 32 are not uncommon.

7 As you can read in Chapter two, the equivalent field inside the IPv6 header has been renamed Hop Limit to far more accurately reflect its true usage.

Some trace utilities, for instance the IOS trace command, make use of the TTL field. When the router is told to trace the route to a host address for instance ten.11.12.13, the router will send three packets with the TTL set to 1; the first router will decrement it to zero, drop the packets, and send back error messages towards the source. By reading the source address of the error messages, the first router on the path is now known. The following three packets are going to be sent with a TTL of two. The first router decrements to 1, the second to zero, and an error message is received from the second router. The third set features a TTL of three, and so forth, till the destination is located. 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

Kind 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
two ltlrichard-s1-13.hwy51.com (172.18.197.1) 36 msec 44 msec 2536 msec
three cperkins-rtr-fr2.hwy51.com (ten.168.204.three) 104 msec 64 msec *
4 cberry.hwy51.com (ten.168.193.1) 92 msec *
5 jllewis-inner.hwy51.com (ten.168.207.59) 44 msec * 44 msec
6 bholly-fw-outer-rt.hwy51.com (ten.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.two) 52 msec 1156 msec *
9 sl-mae-w-H1/0-T3.sprintlink.net (144.228.ten.46) 100 msec 124 msec 2340 msec
ten sanjose1-br1.bbnplanet.net (198.32.136.19) 2264 msec 164 msec *
11 paloalto-br2.bbnplanet.net (4.0.1.ten) 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.ten) 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 provides the "address," or protocol number, of the host-to-host or transport layer protocol for which the data inside the packet is destined. Table 1-2 shows some of the far more typical of the 100 or so distinct protocol numbers at the moment assigned.

Table 1-2. A handful of well-known protocol numbers.

Protocol Number

Host-to-Host Layer Protocol

1

World wide web Control Message Protocol (ICMP)

two

World wide web 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 Subsequent Hop Resolution Protocol (NHRP)

88

Cisco World wide web Gateway Routing Protocol (IGRP)

89

Open Shortest Path Very first (OSPF)

Header Checksum may be the error detection field for the IP header. The checksum will not be calculated for the encapsulated information; UDP, TCP, and ICMP have their own checksums for performing this. The field contains a 16-bit one's complement checksum, calculated by the originator of the packet. The receiver will once more calculate a 16-bit one's complement sum, which includes the original checksum. If no errors have occurred for the duration of the packet's travels, the resulting checksum are going to be all ones. Remember that every single router decrements the TTL; consequently, the checksum should be recalculated at every single router. RFC 1141 discusses some techniques for simplifying this calculation.

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

Possibilities is usually a variable-length field and, because the name says, is optional. Space is added towards the packet header to include either source-generated data or for other routers to enter data; the alternatives are utilized primarily for testing. Essentially the most often utilized alternatives are

Loose source routing, in which a series of IP addresses for router interfaces is listed. The packet will need to pass by means of every single of those addresses, even though various hops could be taken between the addresses.
Strict source routing, where once more a series of router addresses is listed. Unlike loose source routing, the packet will need to follow the route exactly. When the next hop will not be the following address on the list, an error occurs.
Record route supplies space for every single router to enter the address of its outgoing interface because the packet transits in order that a record is kept of all routers the packet encounters. Record route supplies a function comparable to trace except that the outgoing interfaces, both on the path towards the destination and on the return path, are recorded.
Timestamp is an alternative comparable to record route except every single router also enters a timestamp: the packet not simply keeps track of where it has been but also records when it was there.

All these alternatives could be invoked by utilizing the Extended Ping on Cisco routers. Record route is utilized in Example 1-1, loose source routing and timestamp are utilized in Example 1-3, and strict source routing is utilized in Example 1-4.

Example 1-3. The Cisco Extended Ping might be utilized to set parameters inside the Possibilities field of the IP header. In this example, loose source routing and timestamp are utilized.

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:
Kind of service 0:
Set DF bit in IP header? no:
Validate reply information? no:
Information pattern 0xABCD:
Loose, Strict, Record, Timestamp, Verbosenone: l
Source route: 172.16.113.14 172.16.113.ten
Loose, Strict, Record, Timestamp, VerboseLV: t
Number of timestamps [ 6 ]: two
Loose, Strict, Record, Timestamp, VerboseLTV:
Sweep range of sizes n:
Kind escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.113.9, timeout is two seconds:
Packet has IP alternatives: Total alternative bytes= 23, padded length=24
Loose source route: 172.16.113.14 172.16.113.ten
Timestamp: Kind 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: Kind 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: Kind 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, Verbosenone: s
Source route: 172.16.192.6 172.16.113.17 172.16.113.10
Loose, Strict, Record, Timestamp, VerboseSV:
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.ten

Reply to request 0 (80 ms). Received packet has alternatives
Total alternative bytes= 16, padded length=16
Strict source route: 172.16.113.ten 172.16.113.17 172.16.192.6
Finish of list

Reply to request 1 (76 ms). Received packet has alternatives
Total alternative bytes= 16, padded length=16
Strict source route: 172.16.113.ten 172.16.113.17 172.16.192.6
Finish of list

Achievement 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 soon after the alternative field till a various of 32 is reached.

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

Example 1-5. You could see the fields of an IP header along with the values contained in every single field in this protocol analyzer display.

World wide web 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 (appropriate)
Source: 172.16.1.102 (172.16.1.102)
Destination: 224.0.0.5 (224.0.0.5)