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.

- 22 BITS ->

1 s

8

8 1 6

Version

Header Lsngjh

Type of Service

Tc:<i; Lcrgth

löentrfier

riaqs

rragmoHTfid Oiïscî

Time TO LivO

ProtûCû;

reader Checksum

SCLjroc Address

Destination Address

Options

? adding

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.

Number

Version

RFC

0

Reserved

1-3

Unassigned

4

Internet Protocol (IP)

791

5

ST Datagram Mode

1190

6

Simple Internet Protocol (SIP)

6

IPng

1883

7

TP/IX

1475

8

P Internet Protocol (PIP)

1621

9

TCP and UDP over Bigger Addresses (TUBA)

1347

10-14

Unassigned

15

Reserved

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.

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.111

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

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.

Handytfping

ïarçet IP address: 1ra,io, l3.17 Rep?at count [SI ; 1 Datagram im^c 1103] ; 1 ireout in seconds [2\:

cowards [n= ! = y Êotrce address: Tyufl rif service : Set DF bit in IP bender? [no]: y Validate reply date? [no[: Data p^tte-n [0ïA3CD|:

Luu-ji;, Sliiut, Bt;ur'[!r Tiiwstamp, Va r bo se | none | : r Number ot nops [ j j:

Loose, Strict, fte;or-tjp Tiniest amp, Ve'bose |RV] ;

Sweep min [7Si: SftB

Sweep interval [t}: 509

Type eîcipï sequence to stort-

Sending 4, [509.. zeooj byte ig.mp Ecnes to 172.16.113.17, timeout is 2 second Packet ha; IP Tut.il option bytes* 39, padded length <10

Record r-jute: <■> 0,0.«.» 0,0.0.0 0.0.0.0 0.0.0.0

ftopty to foquoet a (16 mfi) (SÎIÛ 500) H Itcçjxvcd picket has optiors T&U1 option Qyt««- 40, padded lcnjtti"40

Record route; 172.16,192.5 172,16.113. IS 172,16.113.17 172.16.113.17

172.16,192.6 172.16.152.& <•> 0.0.0.0 0.0.0.0 0.0.0.0 Eid ot list

Replv to recuesr 1 (24 ma) ¿sire 1600). Received packet hâs optiens Total flption bytes= , ps-fftlpd

Rïcor'd r'SutS : 172.16,192.5 1 72,16,1 13.10 172,16.113.17 172.16.1 13. 1 7

172,16.192,6 172,16,133,S 0.0,0,0 0.0,0,0 0,0,0.0 E iJ Of list

Ftiply to request 2 (2S ns) isOiJ). Received packet has options

Total option bytes 40, paifded length 40

Record route ; 172.16,192.5 172.16.113.IS 172,16,113.1? 172.16.113.17

172.16.192.0 172,16,132,& 0.0.0.0 0.0,0.0 & 0,0.0 Eid of list

Unreachable tron 172.1S , 152.G, inaxinum MTU 147S {Size 2000),

Riceivec packet nas options T-it-sl option bytes- 39, padded length-40 Record rsute: <«> o.s.D.o o.a.&.o 3.a.0.0 a.u.o.3 0,0.0,0 0.0.0.0 0.0.0.0 0.0.0.0 0.0,0.0

r-atc id 75 pireent ¡3/4), round trip «iin/ovfl/nax - 16/22/26 mo

Hindytf

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.

[2] Units of eight octets are used so that a maximum-size packet of 65,535 bytes may 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 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.

7 racing ttie route tc cio' iys,Cisco,COv {193.31,7,130)

2 Ltlrichnrd 51 1 3. fiw/G1, con f 172. 10,197. i > 3& msec 44msflc 2S36 msec

3 cperkifis<rtf-Tr2.riwySl.coin(10.168.204.3) 1G4 msec 60 nse; -

4 eberry, firtySi,c&n (Ifl. 168.193,1) [-¡sec *

5 j lie wis-inner.hviy5l .ton (i®. 13B..207. 59) 44 -jset * fl4 nset

6 aholly-fa-outer.rt.h*y51.com {1flr138.247.34) J4 nsec * i&nsec

7 Bl Bth 14 510/0:6 512k, 6printlInk_nflt (1 44, 228, ZU, 1 07) msflC * Ssl Btk 2 F1/ft/«, sprintliiih.net <i44.223-4Q.2j 52 usee i!S6 nsec *

S sl'MB-A'HWi T3,sj>r-intLiriK .net 044.223.10,46) mse; 124 nsec £340 nsec

10 -brl .bbflpLditet.net f19B. 32. 13G. 1-91 rises 164 nstc *

13 3L pr2. cbnplanft. Jist {131. 1 19. &. 2181 76 rsec 75 nsac 76 isac

13 ttjnplanet .net (131.11-0,ES,n0) msec /6 rse? S3S nsec

14 sty,cisco.con (153.31.7.39) 84 ^sec nscc * iSeio sya.Ciaco.COU (192-31.7.136) Ma« « 54 mac

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.

Protocol Number

Host-to-Host Layer Protocol

1

Internet Control Message Protocol (ICMP)

2

Internet Group Management Protocol (IGMP)

3

Gateway to Gateway Protocol (GGP)

4

IP in IP

6

Transmission Control Protocol (TCP)

8

Exterior Gateway Protocol (EGP)

17

User Datagram Protocol (UDP)

35

Inter-Domain Policy Routing Protocol (IDPR)

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 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.

• 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 may 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 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.

Handytfping Protocol [lpj :

Target IP address: 172.16.113.9

Extended commands [n]: y

Source address;

Validate reply data? [no]:

Data pattern [0kabcd|:

Loose, Strict, Record, Tiaestanp, Verbose [none\; 1 Source route: 172,16.113.14 172.16.113.10 Loose, Strict, Accord, Tiqestanp, verbosefLV]: t Nunher of timestanps [ 6 ]: 2

Loose, Strict, Record, Timestairp, VerbosefLTV [ : Sweep range of sizes |n]: Type escape sequence to abort.

Sending S, iflfl-byte ICMP Ecbos to 172.16,113.9, timeout is 2 seconds: Packet has IP options: Total option bytes51 23, padded Length-24 Loose source route: <*> 172.16.113.14 172.16.113.1® Timestamp: Type Overflows: 0 length 12, ptr 5 "Current pointer-:-: Time= 0 Time= O

Request 0 timed out

Reply to request l (76 rcs}. Received packet has options Total option bytes= 24, padded length-24 Loose source ro*ite: 172.16.113.13 172.16.192.6 Times-tamp: Type 0- Overflows: 6 length 12, ptr 13 Tine- aOFF4 798 Time = 80FF475B »Current pointer« End of list

Request £ timed out

Reply to request 2 (76 ms}. Received packet has options Total option bytes- 24, padded length"24 Loose source route: 172.16,113.13 172.16.192.6 <*> Time stamp: Type O. overflows: 6 length 12, ptr 13 Time- eOfF-i^ce Tiine=

^Current pointers End of list

Request 4 timed out

Success rate is 40 percent (2/5), round-trip irin/avg/max = 7&/76/7S m$ Handytf

Figure 2.7. Extended Ping is used here to set strict source routing in the ping packets.

Handyflpmg Protocol | ip] :

Target IP address: l72.l6.M3.i0

Repeat count [si: 2

Datagram size [198];

Tineout in seconds ¡2]:

Extended commands (nj: y

Source address:

Type of service |B|;

Validate reply data? [no]:

Data pattern [0xabCdj :

loose, Strict, Record* Tiiiestarip, Verbose[nonej: s Source route: 172.16,192.6 172.16.113.17 172.16.113.16 Loose, Strict, Record> Tiaestanp, verbose[Sv]:

Sweep range of sizes |n]: Type escape sequence to abort.

Sending 2, i3a-cyte ICWP £chas to l72,16.113<10, timeout is 2 seconds: Packet has IP options; Total option bytes" 15, padded lergth-16 Strict source route: <*> 172.16.192.6 172.16.113.17 172.16.113.10

Reply to request o (flfi ms). Received packet has options Total option bytes= 16, padded lengtr^ie

Strict source route: 172.16.113.1« 172.16,113.17 172.16.192.6 <"> Erti! Of list

Reply to request i (76 bis). Received packet has options Total option bytes= 16, padded langth=l6

Strict source route: 172.113.10 172,16,113,17 172.16.192.6 <«> End of list

Success rate is 100 percent {2/2), round-trip nm/avg/nax = 76/73/80 ms HSrtOyil

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.

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.

0 0

Post a comment