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

TCP/IP Protocol Suite 9

10
 Note

The total length field defines the total

length of the datagram including the
header.

TCP/IP Protocol Suite 11

 Figure 7.4 Encapsulation of a small datagram in an Ethernet frame

TCP/IP Protocol Suite 12

 Figure 7.5 Multiplexing

TCP/IP Protocol Suite 13

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

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 15

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?

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 16

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?

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 17

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

How many hops can this packet travel before being

dropped? The data belong to what upper layer protocol?

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 18

 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 19

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

TCP/IP Protocol Suite 20

 Figure 7.6 MTU

TCP/IP Protocol Suite 21

 Note

Only data in a datagram is fragmented.

TCP/IP Protocol Suite 22

 Figure 7.7 Flags field

TCP/IP Protocol Suite 23

IP Fragmentation
MTU =
2000 host
router
router MTU = 1500
host
MTU = 4000

■ Every Network has Own Maximum Transmission

Unit (MTU)
■ Largest IP datagram it can carry within its own packet
frame
■ E.g., Ethernet is 1500 bytes
■ Don’t know MTUs of all intermediate networks in advance
■ IP Solution
■ When hit network with small MTU, fragment packets
■ Might get further fragmentation as proceed farther
Lecture 9: 2-8-05 24
Reassembly
■ Where to do reassembly?
■ End nodes or at routers?

■ End nodes
■ Avoids unnecessary work where large packets
are fragmented multiple times
■ If any fragment missing, delete entire packet

■ Dangerous to do at intermediate nodes

■ How much buffer space required at routers?
■ What if routes in network change?
■ Multiple paths through network
■ All fragments only required to go through
destination
Lecture 9: 2-8-05 25
Fragmentation Related
Fields
■ Length
■ Length of IP fragment
■ Identification
■ To match up with other fragments
■ Flags
■ Don’t fragment flag
■ More fragments flag
■ Fragment offset
■ Where this fragment lies in entire IP datagram
■ Measured in 8 octet units (13 bit field)
Lecture 9: 2-8-05 26
IP Fragmentation Example
#1
router
host
MTU = 4000

Length = 3820, M=0

IP IP
Header Data

Lecture 9: 2-8-05 27
IP Fragmentation Example
#2 MTU =
2000
router
router
Length = 2000, M=1, Offset = 0
Length = 3820, M=0
IP IP
IP IP Header Data
Header Data

1980 bytes
3800 bytes
Length = 1840, M=0, Offset = 1980

IP IP
Header Data

1820 bytes

Lecture 9: 2-8-05 28
 IP Fragmentation Example
#3 Length = 1500, M=1, Offset = 0
host IP IP
router
MTU = 1500 Header Data

Length = 2000, M=1, Offset = 0 1480 bytes

IP IP Length = 520, M=1, Offset = 1480
Header Data
IP IP
Header Data
1980 bytes Length = 1500, M=1, Offset = 1980
500 bytes
Length = 1840, M=0, Offset = 1980 IP IP
Header Data Length = 360, M=0, Offset = 3460
IP IP IP IP
Header Data Header Data
1480 bytes

1820 bytes 340 bytes

Lecture 9: 2-8-05 29
IP Reassembly
Length = 1500, M=1, Offset = 0
■ Fragments might arrive out-
IP IP
Header Data of-order
■ Don’t know how much memory
Length = 520, M=1, Offset = 1480
required until receive final
IP IP fragment
Header Data
■ Some fragments may be
Length = 1500, M=1, Offset = 1980 duplicated
IP IP ■ Keep only one copy
Header Data
■ Some fragments may never
Length = 360, M=0, Offset = 3460 arrive
IP IP ■ After a while, give up entire
Header Data process
IP IP IP IP
Data Data Data Data

Lecture 9: 2-8-05 30
Fragmentation and
Reassembly Concepts
■ Demonstrates many Internet concepts
■ Decentralized
■ Every network can choose MTU
■ Connectionless
■ Each (fragment of) packet contains full routing
information
■ Fragments can proceed independently and along
different routes
■ Best effort
■ Fail by dropping packet
■ Destination can give up on reassembly
■ No need to signal sender that failure occurred
■ Complex endpoints and simple routers
■ Reassembly at endpoints
Lecture 9: 2-8-05 31
 Figure 7.8 Fragmentation example

TCP/IP Protocol Suite 32

 Figure 7.9 Detailed fragmentation example

TCP/IP Protocol Suite 33

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 34

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 35

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 36

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 37

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?

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 38

 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 39
 Topics Discussed in the Section
✔ Format
✔ Option Types

TCP/IP Protocol Suite 40

 Figure 7.10 Option format

TCP/IP Protocol Suite 41

 Figure 7.11 Categories of options

TCP/IP Protocol Suite 42

 Figure 7.12 No operation option

TCP/IP Protocol Suite 43

 Figure 7.13 Endo-of-option option

TCP/IP Protocol Suite 44

 Figure 7.14 Record-route option

TCP/IP Protocol Suite 45

 Figure 7.15 Record-route concept

TCP/IP Protocol Suite 46

 Figure 7.16 Strict-source-route option

TCP/IP Protocol Suite 47

 Figure 7.17 Strict-source-route option

TCP/IP Protocol Suite 48

 Figure 7.18 Loose-source-route option

TCP/IP Protocol Suite 49

 Figure 7.19 Time-stamp option

TCP/IP Protocol Suite 50

 Figure 7.20 Use of flags in timestamp

TCP/IP Protocol Suite 51

 Figure 7.21 Timestamp concept

TCP/IP Protocol Suite 52

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 53

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
TCP/IP Protocol Suite 54
Example
7.12
One of the utilities available in UNIX to check the traveling
of the IP packets is ping. In the next chapter, we talk about
the ping program in more detail. In this example, we want to
show how to use the program to see if a host is available.
We ping a server at De Anza College named fhda.edu. The
result shows that the IP address of the host is 153.18.8.1.
The result also shows the number of bytes used.

TCP/IP Protocol Suite 55

Example
7.13
We can also use the ping utility with the -R option to
implement the record route option. The result shows the
interfaces and IP addresses.

TCP/IP Protocol Suite 56

Example
7.14
The traceroute utility can also be used to keep track of the
route of a packet. The result shows the three routers
visited.

TCP/IP Protocol Suite 57

Example
7.15
The traceroute program can be used to implement loose
source routing. The -g option allows us to define the
routers to be visited, from the source to destination. The
following shows how we can send a packet to the fhda.edu
server with the requirement that the packet visit the router
153.18.251.4.

TCP/IP Protocol Suite 58

Example
7.16
The traceroute program can also be used to implement
strict source routing. The -G option forces the packet to
visit the routers defined in the command line. The following
shows how we can send a packet to the fhda.edu server
and force the packet to visit only the router 153.18.251.4.

TCP/IP Protocol Suite 59

 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 60
 Topics Discussed in the Section
✔ Checksum Calculation at the Sender
✔ Checksum Calculation at the Receiver
✔ Checksum in the Packet

TCP/IP Protocol Suite 61

 Figure 7.22 Checksum concept

TCP/IP Protocol Suite 62

 Figure 7.23 Checksum in one’s complement arithmetic

TCP/IP Protocol Suite 63

 Note

Checksum in IP covers only the header,

not the data.

TCP/IP Protocol Suite 64

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 65

 Figure 7.24 Example of checksum calculation at the sender

TCP/IP Protocol Suite 66

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 67

 Figure 7.25 Example of checksum calculation at the receiver

TCP/IP Protocol Suite 68

 Note

Appendix D gives an algorithm for

checksum calculation.

TCP/IP Protocol Suite 69

 7-6 IP OVER ATM
In the previous sections, we assumed that the
underlying networks over which the IP datagrams
are moving are either LANs or point-to-point WANs.
In this section, we want to see how an IP datagram
is moving through a switched WAN such as an
ATM. We will see that there are similarities as well
as differences. The IP packet is encapsulated in
cells (not just one). An ATM network has its own
definition for the physical address of a device.
Binding between an IP address and a physical
address is attained through a protocol called
ATMARP.
TCP/IP Protocol Suite 70
 Topics Discussed in the Section
✔ ATM WANs
✔ Routing the Cells

TCP/IP Protocol Suite 71

 Figure 7.26 An ATM WAN in the Internet

TCP/IP Protocol Suite 72

 Note

The AAL layer used by the IP protocol is

AAL5.

TCP/IP Protocol Suite 73

 Figure 7.27 Entering-point and exiting-point routers

TCP/IP Protocol Suite 74

 Figure 7.28 Address binding in IP over ATM

TCP/IP Protocol Suite 75

 7-7 SECURITY

The IPv4 protocol, as well as the whole Internet,

was started when the Internet users trusted each
other. No security was provided for the IPv4
protocol. Today, however, the situation is
different; the Internet is not secure any more.
Although we discuss network security in general
and IP security in particular in Chapters 29 and
30, we give a brief idea about the security issues
in IP protocol and the solution.

TCP/IP Protocol Suite 76

 Topics Discussed in the Section
✔ Security Issues
✔ IPSec

TCP/IP Protocol Suite 77

 7-8 IP PACKAGE

In this section, we present a simplified example

of a hypothetical IP package. Our purpose is to
show the relationships between the different
concepts discussed in this chapter.

TCP/IP Protocol Suite 78

 Topics Discussed in the Section
✔ Header-Adding Module
✔ Processing Module
✔ Queues
✔ Routing Table
✔ Forwarding Module
✔ MTU Table
✔ Fragmentation Module
✔ Reassembly Table
✔ Reassembly Module

TCP/IP Protocol Suite 79

 Figure 7.29 IP components

TCP/IP Protocol Suite 80

TCP/IP Protocol Suite 81
TCP/IP Protocol Suite 82
TCP/IP Protocol Suite 83
TCP/IP Protocol Suite 84
 Figure 7.30 Reassembly table

TCP/IP Protocol Suite 85

TCP/IP Protocol Suite 86