Chapter 7

Internet
Protocol
Version4
(IPv4)

TCP/IP Protocol Suite 1

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
OBJECTIVES:
 To explain the general idea behind the IP protocol and the
position of IP in TCP/IP protocol suite.
 To show the general format of an IPv4 datagram.
 To discuss fragmentation and reassembly of datagrams.
 To discuss several options that can be in an IPv4 datagram and
their applications.
 To show how a checksum is calculated for the header of an IPv4
datagram at the sending site and how the checksum is checked at
the receiver site.
 To discuss IP over ATM and compare it with IP over LANs
and/or point-to-point WANs.
 To show a simplified version of the IP package and give the
pseudocode for some modules.

TCP/IP Protocol Suite 2

Chapter 7.1 Introduction
Outline 7.2 Datagrams
7.3 Fragmentation
7.4 Options
7.5 Checksum
7.6 IP over ATM
7.7 Security
7.8 IP Package
TCP/IP Protocol Suite 3
 7-1 INTRODUCTION

The Internet Protocol (IP) is the transmission

mechanism used by the TCP/IP protocols at the
network layer.

TCP/IP Protocol Suite 4

 Topics Discussed in the Section
Relationship of IP to the rest of the TCP/IP Suite

TCP/IP Protocol Suite 5

 Figure 7.1 Position of IP in TCP/IP protocol suite

TCP/IP Protocol Suite 6

 7-2 DATAGRAMS

Packets in the network (internet) layer are called

datagrams. A datagram is a variable-length packet
consisting of two parts: header and data. The header is
20 to 60 bytes in length and contains information
essential to routing and delivery. It is customary in
TCP/IP to show the header in 4-byte sections. A brief
description of each field is in order.

TCP/IP Protocol Suite 7

 Topics Discussed in the Section
Format of the datagram packet
Some examples

TCP/IP Protocol Suite 8

 Figure 7.2 IP datagram

back

TCP/IP Protocol Suite 9

 Figure 7.3 Service type

x x x 0 0 0 x x x x x 0
Precedence x x x x 1 1
interpretation
x x x x 0 1
Differential service
interpretation

TCP/IP Protocol Suite 10

TCP/IP Protocol Suite 11
 Note

The total length field defines the total

length of the datagram including the
header.

TCP/IP Protocol Suite 12

 Figure 7.4 Encapsulation of a small datagram in an Ethernet frame

TCP/IP Protocol Suite 13

 Figure 7.5 Multiplexing

TCP/IP Protocol Suite 14

TCP/IP Protocol Suite 15
Example 7.1
An IP packet has arrived with the first 8 bits as shown:

Slide 9

The receiver discards the packet. Why?

Solution
There is an error in this packet. The 4 left-most bits (0100) show
the version, which is correct. The next 4 bits (0010) show the
wrong header length (2 × 4 = 8). The minimum number of bytes in
the header must be 20. The packet has been corrupted in
transmission.

TCP/IP Protocol Suite 16

Example 7.2
In an IP packet, the value of HLEN is 1000 in binary. How many
bytes of options are being carried by this packet?
Slide 9
Solution
The HLEN value is 8, which means the total number of bytes in the
header is 8 × 4 or 32 bytes. The first 20 bytes are the base
header, the next 12 bytes are the options.

TCP/IP Protocol Suite 17

Example 7.3
In an IP packet, the value of HLEN is 516 and the value of the total
length field is 002816. How many bytes of data are being carried by
this packet? Slide 9

Solution
The HLEN value is 5, which means the total number of bytes in the
header is 5 × 4 or 20 bytes (no options). The total length is 40
bytes, which means the packet is carrying 20 bytes of data (40 −
20).

TCP/IP Protocol Suite 18

Example 7.4
An IP packet has arrived with the first few hexadecimal digits as
shown below:
Slide 9

How many hops can this packet travel before being dropped? The
data belong to what upper layer protocol? Slide 15

Solution
To find the time-to-live field, we skip 8 bytes (16 hexadecimal
digits). The time-to-live field is the ninth byte, which is 01. This
means the packet can travel only one hop. The protocol field is the
next byte (02), which means that the upper layer protocol is IGMP
(see Table 7.2)

TCP/IP Protocol Suite 19

 7-3 FRAGMENTATION

A datagram can travel through different networks. Each

router decapsulates the IP datagram from the frame it
receives, processes it, and then encapsulates it in
another frame. The format and size of the received
frame depend on the protocol used by the physical
network through which the frame has just traveled. The
format and size of the sent frame depend on the
protocol used by the physical network through which
the frame is going to travel.

TCP/IP Protocol Suite 20

 Topics Discussed in the Section
 Maximum Transfer Unit (MTU)
 Fields Related to Fragmentation

TCP/IP Protocol Suite 21

 Figure 7.6 MTU

IP datagram

Header MTU Trailer

Maximum length of data that can be encapsulated in a frame
Frame

TCP/IP Protocol Suite 22

 Note

Only data in a datagram is fragmented.

TCP/IP Protocol Suite 23

 Figure 7.7 Flags field

Slide 9

TCP/IP Protocol Suite 24

 Figure 7.8 Fragmentation example

Slide 9 Offset = 0000/8 = 0

0000 1399

Offset = 1400/8 = 175

1400 2799

Offset = 2800/8 = 350

2800 3999

TCP/IP Protocol Suite 25

 Figure 7.9 Detailed fragmentation example

1420
14,567 1 000

Bytes 0000–1399 820

14,567 1 175
Fragment 1
4020
14,567 0 000
1420 Bytes 1400–2199
14,567 1 175
Fragment 2.1

Bytes 0000–3999
Bytes 1400–2799
Original datagram Fragment 2

1220
14,567 0 350

Bytes 2800–3999
Fragment 3

TCP/IP Protocol Suite 26

Example 7.5
A packet has arrived with an M bit value of 0. Is this the first
fragment, the last fragment, or a middle fragment? Do we know if
the packet was fragmented?

Solution
If the M bit is 0, it means that there are no more fragments; the
fragment is the last one. However, we cannot say if the original
packet was fragmented or not. A nonfragmented packet is
considered the last fragment.

TCP/IP Protocol Suite 27

Example 7.6
A packet has arrived with an M bit value of 1. Is this the first
fragment, the last fragment, or a middle fragment? Do we know if
the packet was fragmented?

Solution
If the M bit is 1, it means that there is at least one more fragment.
This fragment can be the first one or a middle one, but not the last
one. We don’t know if it is the first one or a middle one; we need
more information (the value of the fragmentation offset). See also
the next example.

TCP/IP Protocol Suite 28

Example 7.7
A packet has arrived with an M bit value of 1 and a fragmentation
offset value of zero. Is this the first fragment, the last fragment, or
a middle fragment?

Solution
Because the M bit is 1, it is either the first fragment or a middle
one. Because the offset value is 0, it is the first fragment.

TCP/IP Protocol Suite 29

Example 7.8
A packet has arrived in which the offset value is 100. What is the
number of the first byte? Do we know the number of the last byte?

Solution
To find the number of the first byte, we multiply the offset value by
8. This means that the first byte number is 800. We cannot
determine the number of the last byte unless we know the length
of the data.

TCP/IP Protocol Suite 30

Example 7.9
A packet has arrived in which the offset value is 100, the value of
HLEN is 5 and the value of the total length field is 100. What is the
number of the first byte and the last byte?
Slide 9

Solution
The first byte number is 100 × 8 = 800. The total length is 100
bytes and the header length is 20 bytes (5 × 4), which means that
there are 80 bytes in this datagram. If the first byte number is 800,
the last byte number must be 879.

TCP/IP Protocol Suite 31

 7-4 OPTIONS

The header of the IP datagram is made of two parts: a

fixed part and a variable part. The fixed part is 20
bytes long and was discussed in the previous section.
The variable part comprises the options, which can be
a maximum of 40 bytes.
Options, as the name implies, are not required for a
datagram. They can be used for network testing and
debugging. Although options are not a required part of
the IP header, option processing is required of the IP
software.

TCP/IP Protocol Suite 32

 Topics Discussed in the Section
 Format
 Option Types

TCP/IP Protocol Suite 33

 Figure 7.10 Option format

8 bits 8 bits Variable length

Type Length Value

Number

Class 00000 End of option

00001 No operation
Copy 00 Datagram control 00011 Loose source route
01 Reserved 00100 Timestamp
0 Copy only in first fragment 10 Debugging and management 00111 Record route
1 Copy into all fragments 11 Reserved 01001 Strict source route

TCP/IP Protocol Suite 34

 Figure 7.11 Categories of options

TCP/IP Protocol Suite 35

 Figure 7.12 No operation option

TCP/IP Protocol Suite 36

 Figure 7.13 Endo-of-option option

TCP/IP Protocol Suite 37

 Figure 7.14 Record-route option

TCP/IP Protocol Suite 38

 Figure 7.15 Record-route concept

7 15 4 7 15 8 7 15 12 7 15 16
140.10.6.3 140.10.6.3 140.10.6.3
200.14.7.9 200.14.7.9
138.6.22.26

67.34.30.6 138.6.25.40
67.14.10.22

138.6.22.26
200.14.7.14
140.10.6.3

140.10.5.4

67.0.0.0/24 140.10.0.0/16 200.14.7.9 200.14.7.0/24 138.6.0.0/16

Network Network Network Network

TCP/IP Protocol Suite 39

 Figure 7.16 Strict-source-route option

TCP/IP Protocol Suite 40

 Figure 7.17 Strict-source-route option

Source: 67.34.30.6 Source: 67.34.30.6 Source: 67.34.30.6 Source: 67.34.30.6

Destination: 67.14.10.22 Destination:140.10.5.4 Destination:200.14.7.14 Destination:138.6.25.40
137 15 4 137 15 8 137 15 12 137 15 16
140.10.5.4 67.14.10.22 67.14.10.22 67.14.10.22
200.14.7.14 200.14.7.14 140.10.5.4 140.10.5.4
138.6.25.40 138.6.25.40 138.6.25.40 200.14.7.14

67.34.30.6 138.6.25.40
67.14.10.22

138.6.22.26
200.14.7.14
140.10.6.3

140.10.5.4

200.14.7.9
67.0.0.0/24 140.10.0.0/16 200.14.7.0/24 138.6.0.0/16
Network Network Network Network

TCP/IP Protocol Suite 41

 Figure 7.18 Loose-source-route option

TCP/IP Protocol Suite 42

 Figure 7.19 Time-stamp option

TCP/IP Protocol Suite 43

 Figure 7.20 Use of flags in timestamp

TCP/IP Protocol Suite 44

 Figure 7.21 Timestamp concept

68 28 5 0 1 68 28 13 0 1 68 28 21 0 1 68 28 29 0 1
140.10.6.3 140.10.6.3 140.10.6.3
36000000 36000000 36000000
200.14.7.9 200.14.7.9
36000012 36000012
138.6.22.26
36000020

67.34.30.6
67.14.10.22

138.6.22.26
200.14.7.14
140.10.6.3

140.10.5.4

200.14.7.9
67.0.0.0/24 140.10.0.0/16 200.14.7.0/24 138.6.0.0/16
Network Network Network Network

TCP/IP Protocol Suite 45

Example 7.10
Which of the six options must be copied to each fragment?

Solution
We look at the first (left-most) bit of the type for each option.

a. No operation: type is 00000001; not copied.

b. End of option: type is 00000000; not copied.
c. Record route: type is 00000111; not copied.
d. Strict source route: type is 10001001; copied.
e. Loose source route: type is 10000011; copied.
f. Timestamp: type is 01000100; not copied.

TCP/IP Protocol Suite 46

Example 7.11
Which of the six options are used for datagram control and which
for debugging and managements?

Solution
We look at the second and third (left-most) bits of the type.
a. No operation: type is 00000001; datagram control.
b. End of option: type is 00000000; datagram control.
c. Record route: type is 00000111; datagram control.
d. Strict source route: type is 10001001; datagram control.
e. Loose source route: type is 10000011; datagram control.
f. Timestamp: type is 01000100; debugging and management
control.

TCP/IP Protocol Suite 47

 7-5 CHECKSUM

The error detection method used by most TCP/IP

protocols is called the checksum. The checksum
protects against the corruption that may occur during
the transmission of a packet. It is redundant
information added to the packet. The checksum is
calculated at the sender and the value obtained is sent
with the packet. The receiver repeats the same
calculation on the whole packet including the
checksum. If the result is satisfactory (see below), the
packet is accepted; otherwise, it is rejected.

TCP/IP Protocol Suite 48

 Topics Discussed in the Section
 Checksum Calculation at the Sender
 Checksum Calculation at the Receiver
 Checksum in the Packet

TCP/IP Protocol Suite 49

 Figure 7.22 Checksum concept

Receiver
Section 1 n bits
Section 2 n bits
..............
Checksum n bits
..............
n bits Section k n bits
Checksum
Packet Sum n bits
Complement
If the result is 0, keep;
n bits otherwise, discard.
Result

TCP/IP Protocol Suite 50

 Note

Checksum in IP covers only the header,

not the data.

TCP/IP Protocol Suite 51

Example 7.17
Figure 7.24 shows an example of a checksum calculation at the
sender site for an IP header without options. The header is divided
into 16-bit sections. All the sections are added and the sum is
complemented. The result is inserted in the checksum field.

TCP/IP Protocol Suite 52

 Figure 7.24 Example of checksum calculation at the sender

5 0
1 0
17
10.12.14.5
12.6.7.9

TCP/IP Protocol Suite 53

Example 7.18
Figure 7.25 shows the checking of checksum calculation at the
receiver site (or intermediate router) assuming that no errors
occurred in the header. The header is divided into 16-bit sections.
All the sections are added and the sum is complemented. Since the
result is 16 0s, the packet is accepted.

TCP/IP Protocol Suite 54

 Figure 7.25 Example of checksum calculation at the receiver

TCP/IP Protocol Suite 55