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