Chapter 16

Chapter 16
[Network Layer]
Network Layer Protocols
Dr. Niroj Kumar Pani

[email protected]
Department of Computer Science Engineering & Applications

Indira Gandhi Institute of Technology
Sarang, Odisha
Chapter Outline…
◼ Introduction
◼ IPv4 (Internet Protocol version 4)
◼ IPv6 (Internet Protocol version 6)
◼ Transition From IPv4 To IPv6
◼ ARP (Address Resolution Protocol)
◼ ICMP (Internet Control Message Protocol)
◼ ICMPv6 (Internet Control Message Protocol version 6)
Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.2

Introduction
◼ As we know, the network layer defines / uses the following protocols for
different specified services.
➢ IP (Internet Protocol):
▪ The main protocol of network layer that performs source-to-
destination delivery (one source to one destination delivery - unicasting).
▪ Provides the following services (through which source-to-destination
delivery is achieved):
– Logical addressing
– Packetizing
– Fragmentation & reassembly
▪ Versions: Currently we are using IPv4, and slowly we are
migrating to IPv6.

➢ IGMP (Internet Group Message Protocol): Provides multicasting
(multicast routing).
➢ ARP (Address Resolution Protocol), RARP (Reverse Address Resolution

Protocol), and BOOTP (Bootstrap Protocol ): Provide address
resolution.
➢ ICMP (Internet Control Message Protocol):
▪ Provides error reporting.
▪ Versions: ICMP or ICMPv4 (works with IPv4) and ICMPv6 (works with
IPv6)
➢ Different Routing Protocols (such as RIP, OSPF, BGP etc.): Provides

unicast / multicast routing.

◼ In this Chapter, we discuss three important protocols.
➢ IP (IPv4 and IPv6)
▪ We discuss two of their services “packetizing” and
“fragmentation / reassembly” for both versions.
▪ “Logical addressing” for both versions (IPv4 addressing and IPv6
addressing) has already been discussed in the last chapter.
▪ The other service “routing & forwarding” is identical (with respect
to techniques) for both versions and is discussed in the next
chapter.
➢ ARP
➢ ICMP (ICMPv4 and ICMPv6)
The routing protocols are discussed in the next chapter. We shall not discuss IGMP, RARP,
and BOOTP.

IPv4 (Internet Protocol version 4)
◼ Also known as Internetworking Protocol version 4.
◼ It is the main protocol of network layer that performs source-to-destination

delivery (one source to one destination delivery - unicasting).
◼ It provides the following services (through which unicasting is achieved):

➢ Logical addressing (IPv4 addressing)
➢ Packetizing
➢ Fragmentation & reassembly
◼ It is a connectionless and unreliable protocol - a best-effort delivery service.
[NOTE]: The concept of “Connection-oriented Vs. Connection-less protocols” and “Reliable

Vs. Unreliable protocols” were already discussed in the Chapter “Wired LANs - Ethernet”.

IPv4 Packet (Datagram) Format
◼ Packets in IPv4 are called datagrams.
◼ Fig. 16.1 shows the IPv4 datagram format.
[Fig. 16.1:
IPv4
Datagram
Format]

◼ The datagram is a variable-length packet of 20-65535 bytes consisting of 2 parts:
1. Header (20-60 bytes):

▪ It carries IP protocol specific information.
▪ It contains 13 fields (discussed next). 12 Compulsory fields (20 bytes)
and 1 optional “options & padding” field (0-40 bytes).
▪ The header is 20 bytes if there are no “options & padding” and up
to 60 bytes if it contains “options & padding” .
▪ It is customary in TCP/IP to show the header in 4-byte sections. .

2. Data (0-65515 bytes):
▪ It carries the data from different Transport layer protocols (TCP,
UDP, STCP) or network layer protocols (ICMP, IGMP, and OSPF).
[Fig. 16.2: Encapsulation of Data in IPv4 Datagram]
▪ Data is 0 bytes if the packet is a control packet and can be up to

65515 bytes if the packet is a data packet.
Max. data length = max. IP packet length which is 65535 bytes - min. header
length which is 20 bytes = 655515 bytes

◼ The Fields in the Header:
➢ Version (VER) (4 bits): It defines the version of the IPv4 protocol. For
IPv4, its value is 4.
➢ Header length (HLEN) (4 bits):

▪ It defines the length of the datagram header in 4-byte word (e.g., if
header is 32 bytes, then the value of this field is 8 as 8X4 = 32).
▪ This field is required because the length of the header is variable
(20-60 bytes).
▪ Since the length of the header can be between 20-60 bytes, the
value of this field is between 5 (5 x 4 =20) and 15 (15 x 4 =60).

➢ Services (8 bits):
▪ This field defines what services should be provided to the
datagram (how the datagram should be treated) at each hop that
receives the datagram. The services are defined in terms of two
parameters:
– Priority: Processing priority of the datagram with respect
to other datagrams from the same source in issues such as
congestion.
– Service type: QoS parameters like minimize cost, maximize
reliability, maximize throughput, minimize delay, normal
(treat normally without regarding any of the previous QoS
parameters) etc. Different application programs may request
different service types.

▪ Earlier (in the original design of IP header), this field was called
the Service Type / Types-of-Services (TOS) field which defined 8
priority levels (0-7) and 5 service types (normal, minimize cost,
maximize reliability, maximize throughput, and minimize delay).
▪ In late 1990s, IETF redefined this field to include more service
types and its now called the Differentiated Services field. In this
variation, there are 64 service types including the priority.
➢ Total length (16 bits):

▪ It defines the length of the entire IPv4 datagram (header plus
data) in bytes.
▪ Since the field length is 16 bits, the total length of the IPv4
datagram is limited to 65,535 bytes.
➢ Identification (16 bits), Flags (3 bits), and Fragmentation offset (13 bits):
▪ All these fields are used in fragmentation (discussed in the next
section).

➢ Time to live (TTL) (8 bits):
▪ This field is used to limit the maximum number of hops (routers) a
datagram can travel in its lifetime.
▪ When the source sends a datagram, it stores a number in the TTL
field (which is generally 2 times the maximum number of routers between
the source and the destination). Each router on receiving the
datagram decrements the value of the TTL field by 1. When the
value becomes 0, the datagram is discarded.
▪ TTL filed is commonly use for two purposes:
– Prevent the routing table from being corrupted.
– Limit the journey of the datagram.

➢ Protocol (8 bits):
▪ This field specifies the Transport or Network layer protocol
whose data is encapsulated in the IPv4 datagram.
▪ The value of this filed for each of the protocols is given below:
➢ Header checksum (16 bits): This field contains the checksum (for the
header part only) which is used to detect the presence of any error in
the header part.
[NOTE]: The checksum is calculated by dividing the header part into 16-bit sections,
adding them together, and then complementing the result (sum).

➢ Source IP address (32 bits): It defines the IP address of the source.
➢ Destination IP address (32 bits): It defines the IP address of the

destination.
➢ Options & Padding (0-40 bytes):

▪ This field is optional.
▪ The information present in the “Options” sub-field is used for
network testing and debugging purposes.
▪ The “Padding” sub-field contains extra bits which are used to
make the total length of the datagram a multiple of 4 bytes.

Solved Examples
◼ Example 1: An IPv4 packet has arrived with the first 8 bits: 01000010. The
receiver discards the packet. Why?
Solution: There is an error in this packet.

➢ The 4 leftmost bits (0100) show the version, which is correct.
➢ The next 4 bits (0010) show an invalid header length (2 × 4 = 8). The
minimum number of bytes in the header must be 20. The packet has
been corrupted in transmission.
◼ Example 2: In an IPv4 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 (1000), 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.

◼ Example 3: In an IPv4 packet, the value of HLEN is 5, and the value of the total
length is 0x0028. 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).
◼ Example 4: An IPv4 packet has arrived with the first few hexadecimal digits as:
0x45000028000100000102 . . . How many hops can this packet travel before
being dropped? The data belong to what upper-layer protocol?
Solution: .
➢ To find the number of hops this packet can travel before being dropped,
we have to find the value of the TTL field. To find this, we skip 8 bytes (16
hex digits). The TTL field is the 9th byte, which is 01. This means that the
packet can travel only one hop before being dropped.
➢ The protocol field is the 10th byte which is 02. This means that the upper-
layer protocol is IGMP.

Fragmentation & Reassembly in IPv4
◼ Fragmentation & Reassembly - Why?:

➢ The IPv4 datagram must be encapsulated into a datalink layer frame in
order to travel from one hop to another.
➢ Each frame has its own "Maximum Transfer Unit (MTU)" (the maximum
amount of network layer data that can be encapsulated in a frame) which depends
upon the underlying datalink layer protocol.
MTUs for some protocols is shown below:
➢ Since the length of the IPv4 datagram can be up to 65535 bytes, it must
be divided (fragmented) when it needs to be encapsulated into a frame
whose MTU is less than 65535.
➢ If a datagram is fragmented, it must be reassembled.
◼ Fragmentation & Reassembly - By Whom and How Many Times?
➢ In IPv4, a datagram can be fragmented by the source host or any router
in the path.
➢ A datagram can be fragmented any number of times if required.
However, the source host can disallow fragmentation (by setting the “do
not fragment” bit in the “Flag” field of the header - discussed next).
➢ The reassembling of the datagram is done just once only by the
destination host.
◼ A NOTE: When a datagram is fragmented (by the source or a router), each

fragment is treated as an independent IPv4 packet having its own header (we
shall see shortly that most of the fields in the header are copied from the original datagram
except a few). Each fragment being an independent IPv4 packet, may follow a
different path and arrive at the destination out of order at different times. It is
the duty of the destination host to reassemble these frames into one unit.

◼ Fields (in IPv4 Header) Related to Fragmentation and Reassembly:
➢ Identification (16 bits):

▪ This field identifies a datagram originating from a source host.
The combination of this field and source IPv4 address uniquely
identifies a datagram.
▪ When a datagram is fragmented, all its fragments must have the
same identification number in their respective headers as of the
parent datagram.
▪ The identification number is used by the destination to
reassemble the datagram (all fragments having the same identification
number are reassembled into one datagram).

➢ Flags (3 bits):
▪ In it the first bit is reserved.
▪ The second bit is called “do not fragment” bit.
– If its value is 1, the machine must not fragment the
datagram. If it cannot pass the datagram through any
available physical network, it discards the datagram and
sends an ICMP error message to the source (ICMP is
discussed later).
– If its value is 0, the datagram can be fragmented if
necessary.
▪ The third bit is called “more fragment” bit.
– If its value is 1, it means the datagram is not the last
fragment; there are more fragments after this one.
– If its value is 0, it means this is the last or only fragment.
[Fig. 16.3: Flags Used in

Fragmentation]

➢ Fragmentation Offset (13 bits): This field defines the relative position of
the current fragment with respect to the whole datagram. It is the offset
of the data (not the header part) in units of 8 bytes (the value of the offset is
measured in units of 8 bytes because the length of the offset field is only 13 bits).
[Fig. 16.4: Calculation of Fragmentation Offset

of datagram with a data size of 4000 bytes
fragmented into three fragments]

◼ How is Fragmentation Done?
The following set of actions are taken by the source or a router when a
datagram needs to be fragmented:
1. The size of the fragments (to be created) are determined depending upon
the MTU. Accordingly, the size of the data part in the fragments are
determined (data size = fragment size - header size).
2. The data from the original datagram is decapsulated, chopped (as per the
determined data size), and re-encapsulated into individual fragments.
3. The headers of these new fragments are formulated by copying all the
fields except the following from the original datagram header
▪ Total length
▪ Flags
▪ Fragmentation offset
▪ Header checksum
▪ Options & padding

4. The fields “Total length”, “Flags”, “Fragmentation offset”, and “Header
checksum” are recalculated for each fragment.
5. The “Options & padding” field may or may not be copied into each
fragment depending upon the requirements.

[Fig. 16.5: A Fragmentation Example]

◼ How is Reassembling Done?
The destination host uses the following strategy to reassemble the original
datagram from the fragments received (if none of them is lost):
1. The first fragment has the "Fragmentation offset" field value of 0.

2. Divide the length of data part (value of the "Total length" field - header length)
of the first fragment by 8. The second fragment has the "Fragmentation
offset" field value equal to this result.
3. Divide the sum of the length of data parts of the first and second
fragment by 8. The third fragment has the "Fragmentation offset" field
value equal to this result.
4. Continue the process until the last fragment is received which has its M
bit (More fragments bit) set to 0.

Solved Examples
◼ Example 1: 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 non-fragmented packet is considered the last fragment.
◼ Example 2: 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).

◼ Example 3: A packet has arrived with an M bit value of 1 and a fragmentation
offset value of 0. 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.
◼ Example 4: 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.

◼ Example 5: 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 are the numbers 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.

IPv6 (Internet Protocol version 6)
◼ Also known as Internetworking Protocol version 6, Internetworking Protocol
next generation (IPng).
◼ IPv6 is slowly replacing IPv4 and becoming the standard for internetworking.
◼ Why IPv6?: As already discussed in the last chapter, IPv6 was proposed mainly
to overcome the following deficiencies in IPv4:
➢ Address depletion.
➢ Lack of accommodation for real-time audio / video transmission.
➢ Lack of encryption and authentication mechanisms.
◼ Services: IPv6 provides all the functionality and services that IPv4 provides.
Moreover, IPv6 provides some additional features like good QoS, security etc.
◼ Like IPv4, IPv6 is also a connectionless and unreliable protocol - a best-effort

delivery service

◼ Changes Made to Other Network Layer Protocols for IPv6:
To be compatible with IPv6
➢ ICMP was modified. Its now called ICMPv6 (discussed later).
➢ ARP and IGMP were included in the ICMPv6.
➢ RARP and BOOTP were dropped from the suite because they were
rarely used.
➢ Routing protocols, such as RIP and OSPF (discussed in the next chapter),
were also slightly modified to accommodate these changes.

IPv4 Vs. IPv6 (Advantages of IPv6 Over IPv4)
The advantages of IPv6 over IPv4 are summarized below:
1. No address depletion problem because of larger address space: An IPv6

address is 128 bits long as compared to the 32-bit address of IPv4. This is a
huge 296 increase in the address space.
2. Better header format: IPv6 uses a new header format in which options are
separated from the base header and inserted, when needed, between the base
header and the upper-layer data. This simplifies and speeds up the routing
process because most of the options do not need to be checked by routers.
3. New options: IPv6 has new options to allow for additional functionalities.
4. Allowance for extension: IPv6 is designed to allow the extension of the protocol
if required by new technologies or applications.

5. Support for resource allocation: In IPv6, the “Services” field has been
removed, and a mechanism (called flow label) has been added to enable the
source to request special handling of the packet. This mechanism can be used
to support traffic such as real-time audio and video.
6. Support for more security: The encryption and authentication options in IPv6
provide confidentiality and integrity of the packet.

IPv6 Packet (Datagram) Format
◼ IPv6 packet format is shown in Fig. 16.6.
[Fig. 16.6: IPv6

Datagram Format]
◼ The packet is composed of two parts:

1. Base header (40 bytes): This is the mandatory part having 8 fields
(discussed next).
2. Payload (can be up to 65535 bytes): It again consists of two parts:
▪ Extension headers (optional) (discussed next).
▪ Data from an upper layer.

◼ The Base Header:
The fields in the base header are shown in Fig. 16.7.
[Fig. 16.7: IPv6

Base Header
Format]

➢ Version (VER) (4 bits): It defines the version of the IPv6 protocol. For
IPv6, the value is 6.
➢ Priority (PRI) (4 bits): It defines the priority of the packet with respect to
other packets from the same source in case of traffic congestion. For
example, if one of two consecutive datagrams must be discarded due to
congestion, the datagram with the lower packet priority is discarded.
➢ Flow level (24 bits):

▪ This field is designed to handle a “flow of packets”.
In IPv6, a sequence of packets, sent from a particular source to a
particular destination, that needs special handling by routers is called a
"flow of packets".
The combination of the source address and the value of the flow
label uniquely defines a “flow of packets”.

▪ This field is generally used to speed up the processing of packets
by a router. When a router receives a packet, instead of
consulting the routing table and going through a routing
algorithm to define the address of the next hop, it can easily look
in a flow label table for the next hop.
▪ In its more sophisticated form, this field can be used to support
the transmission of real-time audio and video.
▪ For effective use of this filed, 3 rules have been defined:
1. The flow label is assigned to a packet by the source host. Its a random
number between 1 and 224 - 1. This number can't be reused for a new
flow while the existing flow is still active.
2. If a source host does not support the flow label, it sets this field to
zero. If a router does not support the flow label, it simply ignores it.
3. All packets belonging to the same flow have the same source, same
destination, same priority, and same options.

➢ Next header (8 bits):
▪ Same as the “protocol” field in IPv4.
▪ It is either one of the optional "extension headers" used by IPv6
or the header of an encapsulated packet such as UDP or TCP.
▪ Next header values are shown below.
➢ Hop limit (8 bits): Same as the TTL field in IPv4.
➢ Source address (16 bytes / 128 bits): It is the IPv6 address of the source.
➢ Destination address (16 bytes / 128 bits): It is the IPv6 address of the
destination.

Comparison Between IPv4 and IPv6 Packet Headers :

◼ The Extension Headers:
In order to give greater functionality to the IPv6 datagram, the base header can
be followed by up to six extension headers. Many of these headers are
"options" in IPv4. The six types of base headers are shown in Fig. 16.8.
[Fig. 16.8: IPv6

Extension Header
Types]

➢ Hop-by-Hop Option:
▪ This extension header is used when the source needs to pass
some information to all the routers visited by the datagram.
▪ There are three variations:
1. Pad1: Used when the information is up to 1 byte.
2. PadN: Used when the information is between 1-65,535
bytes.
3. Jumbo payload: Used when the information is more than
65,535 bytes.
➢ Source Routing: This extension header combines the concepts of the

strict source route and the loose source route options of IPv4.
➢ Fragmentation:
▪ This extension header contains fragmentation related
information when an IPV6 datagram is fragmented.

▪ The concept of fragmentation (and reassembly) in IPv6 is the
same as that in IPv4. However, by whom the fragmentation
occurs differs.
▪ In IPv4, the fragmentation is done by the source, or a router. In
IPv6, only the original source can fragment.
▪ A source uses a path MTU discovery technique to find the
smallest MTU supported by any network (datalink layer protocol)
on the path. The source then fragments using this knowledge.
➢ Authentication: This extension header has a dual purpose: it validates

the message sender and ensures the integrity of data.
➢ Encrypted Security Payload: This extension header provides

confidentiality and guards against eavesdropping.
➢ Destination Option: This extension header is used when the source

needs to pass information to the destination only. Intermediate routers
are not permitted access to this information.

Transition From IPv4 to IPv6
◼ Because the number of systems (nodes) on the Internet is huge, the transition
from IPv4 to IPv6 cannot happen suddenly. It must be smooth (hence time
taking) to prevent any problem between IPv4 and IPv6 systems.
◼ Three strategies have been devised by the IETF for the transition::
1. Dual stack
2. Tunneling
3. Header Translation
◼ Dual Stack: According to this strategy,

it is recommended that all the hosts
on the Internet must run
IPv4 and IPv6 simultaneously
until all the Internet uses IPv6.
[Fig. 16.9: Dual stack]

◼ Tunneling:
➢ Tunneling is used when two computers using IPv6 want to communicate
with each other, and the packet must pass through a region that uses
IPv4.
➢ In this strategy, the IPv6 packet is encapsulated in an IPv4 packet when
it enters the region, and it leaves its capsule when it exits the region.
➢ To make it clear that the IPv4 packet is carrying an IPv6 packet as data,
the protocol field in the IPv4 packet is set to 41.
[Fig. 16.10: Tunneling]

◼ Header Translation:
➢ Header is used when the sender wants to use IPv6, but the receiver
does not understand IPv6 or vice versa.
➢ In this strategy, the header of the IPv6 packet is converted to an IPv4
header (the procedure is given in Table. 16.1, next slide).
[Fig. 16.11: Header Translation]

[Table. 16.1: Header Translation Procedure / Rules]

ARP (Address Resolution Protocol)
ARP - Why & What?
◼ In TCP/IP, the delivery of a packet from a source host to a destination host

requires two levels of addressing:
➢ Logical / IP address of the destination, and
➢ Physical address of the next hop (at each hop on the path to the destination)
◼ The IP address of the destination is obtained (by the source) from the DNS. But
how does each hop on the path to the destination find the physical address of
its next hop? For this, the ARP is used.
◼ The ARP is a network layer protocol that finds (discovers) the physical address
of a node from its IP address dynamically (i.e., as and when required). This process
is called address resolution.

◼ The source and each hop on the path to the destination uses the ARP to obtain
the physical address of its next hop from its IP address (a node knows the IP
address of its next hop from its routing table).
[NOTE 1]: The reverse process, i.e., obtaining logical address from physical address is called
“reverse address resolution”. For this, the protocols RARP and BOOTP are used.
[NOTE 2]: ARP, RARP and BOOTP are used only with IPv4. In IPv6, the functionality of
ARP is integrated with ICMPv6 and the protocols RARP and BOOTP are dropped because
reverse address resolution is rarely required.

Cases Where ARP is Used (Address Resolution is Required)
◼ There can be four cases (shown in Fig. 16.12) where ARP is used (i.e., address
resolution is required).
[Fig. 16.12: Four Cases

Where ARP is Used]

ARP Operation / Mechanism
The following steps are involved in an ARP process.
1. The sender (the source or a router on the path to destination) prepares an “ARP
request” packet. The packet (the packet format is discussed next) includes (among
other information) the physical address of the sender, the IP addresses of the
sender, and the IP address of the target (the next hop) (the sender finds the IP
address of its next hop from its routing table).
2. This packet is broadcasted over the network (to which the sender belongs).
3. Every host or router in the network receives the ARP request packet. However,
all machines except the target, drop the packet. The target machine
recognizes its IP address.
4. The target replies with an “ARP reply” packet. It includes (among other
information) the physical address of the target, the IP addresses of the target,
the physical address of the sender, and the IP address of the sender.
5. The packet is unicasted directly to the source.

6. The sender on receiving the “ARP reply” packet from the target, knows
physical address of the target.
7. For better efficiency, a node that receives an ARP reply stores the logical to
physical address mapping in the cache memory and keeps it for 20 to 30
minutes unless the space in the cache is exhausted. Before sending an ARP
request, the node first checks its cache to see if it can find the mapping.
[Fig. 16.13: ARP Operation]

ARP Packet Format
◼ Fig. 16.14 shows the ARP request / reply packet format.
◼ It contains 9 fields (discussed next).
[Fig. 16.14: ARP

Packet Format]

➢ Hardware type (16 bits): It defines the type of the network (LAN) on
which ARP is running (ARP can be used on any physical network). Each
LAN has been assigned an integer based on its type. For example,
Ethernet is given type 1.
➢ Protocol type (16 bits): It defines the network layer protocol for which
the ARP request is intended. For IPv4 protocol, this field has the value
Ox0800.
➢ Hardware length (8 bits): It defines the length of the physical address

supported by the network in bytes. For example, for Ethernet the value
of this field is 6.
➢ Protocol length (8 bits): It defines the length of the logical address in

bytes. For example, for IPv4 the value of this field is 4.
➢ Operation (16 bits): It defines the type of ARP packet. For ARP request
packet the value of this field is 1 and for ARP reply packet it is 2.

➢ Sender hardware address (32 bits): It defines the physical address of
the node sending the ARP request / reply packet.
➢ Sender protocol address (32 bits): It defines the IP address of the node
sending the ARP request / reply packet.
➢ Target hardware address (32 bits): It defines the physical address of the
node for which the ARP request / reply packet is intended. In an ARP
request packet, this field is not filled.
➢ Target protocol address (32 bits): It defines the IP address of the node
for which the ARP request / reply packet is intended.

Encapsulation
◼ Unlike some other network layer protocol (such as ICMP, IGMP, OSPF etc.)
whose packets are encapsulated in an IP packet and the IP packet is
encapsulated in a data link layer frame, an ARP packet is encapsulated directly
into a data link frame.
For example, Fig. 16.15 shows the encapsulation of an ARP packet in an

Ethernet frame.
[Fig. 16.15: Encapsulation of ARP Packet in an Ethernet Frame]

Proxy ARP
◼ A technique that creates a subnetting kind of effect.
◼ A proxy ARP is an ARP that acts on behalf of a set of hosts.
◼ Whenever a router running a proxy ARP receives an ARP request looking for
the IP address of one of these hosts, the router sends an ARP reply announcing
its own hardware (physical) address. After the router receives the actual IP
packet, it sends the packet to the appropriate host or router.
[Fig. 16.16:
Proxy ARP]

ICMP (Internet Control Message Protocol)
◼ Also known as ICMPv4 (Internet Control Message Protocol version 4).
ICMP - Why & What?
◼ The IP has two deficiencies:

1. IP is a connection-less & unreliable protocol; it has no error correcting
or reporting mechanism. What happens if an error occurs? For example,
▪ What happens if a router must discard a datagram because it
cannot find a router to the final destination, or because the TTL
field in the datagram is zero?
▪ What happens if the final destination must discard all fragments
of a datagram because it has not received all fragments within a
predetermined time limit?
These are examples of situations where an error has occurred, and the
IP protocol has no built-in mechanism to notify the source.

2. The IP has no query mechanism, for example, a host or a network admin
may want to know whether a particular host or router is alive or not.
◼ The ICMP has been designed to compensate for the above two deficiencies.
◼ The ICMP is a companion to the IPv4 protocol that provides error reporting (not
error correcting) and query services in the network layer.

ICMP Messages - Overview
◼ ICMP provides its services (error reporting & query) through different messages.
◼ In accordance with the services, the ICMP messages are divided into two
broad categories: (I) Error-reporting messages (II) Query messages. The detail
classification is shown below.
◼ Each category has its own message types and packet formats.
ICMP Messages
Error-Reporting Messages Query Messages
Destination unreachable (Type: 3) Echo request & reply (Type: 8 and 0)

Source quench (Type: 4) Router solicitation & advertisement (Type: 10 & 9)
Redirection (Type: 5) Timestamp request & reply (Type: 13 & 14)
Time exceeded (Type: 11) Address-mask request & reply (Type: 17 & 18)
Parameter problems (Type: 12)

I. Error-Reporting Messages
◼ Use: These messages are used to report different errors to the source host that
a router or the destination host may encounter when it processes an IP packet.
◼ Types: There are 5 types of error-reporting messages (5 types of errors are

reported to the source). Each type is identified by an integer.
1. Destination unreachable (Type: 3): This message is sent to the source

when a router cannot route a datagram, or a host cannot deliver a
datagram and hence the datagram is discarded.
2. Source quench (Type: 4): This message is sent to the source when a
router or a host discards the datagram due to congestion (the input queue
/ buffer of the router or host is already filled). This message informs the source
two things:
a) The datagram is discarded.
b) There is a congestion somewhere in the path and the source
should slow down (quench) the sending process.

3. Redirection (Type: 5): This message is sent to the source when a router
receives a datagram from the source destined for a network to which
the router doesn’t address. In such case, the router that receives the
datagram forwards the datagram to the correct router. However, it
sends a redirection message to the source so that the source can
update its routing table.
4. Time exceeded (Type: 11): This message is sent to the source in two
cases:
a) When a router discards a datagram because its TTL field has
reach the value 0.
b) When the destination host discards all fragments of a datagram
because it has not received all fragments within a predetermined
time limit.
5. Parameter problem (Type: 12): This message is sent to the source when
a router or the destination discards a datagram because of some
ambiguity or missing values in the header part.
◼ Some Important Points about ICMP Error-Reporting Messages.
▪ ICMP only reports error (never corrects it).

▪ ICMP always reports error messages to the original source.
▪ No ICMP error message is generated in response to a datagram carrying an ICMP
error message.
▪ No ICMP error message is generated for a fragmented datagram that is not the first
fragment.
▪ No ICMP error message is generated for a datagram having a multicast address.
▪ No ICMP error message is generated for a datagram having a special address such
as 127.0.0.0 or 0.0.0.0.

◼ ICMP Error-Reporting Message Format: Fig. 16.17 shows the format for the ICMP
error-reporting messages.
[Fig. 16.17:
ICMP Error-reporting
Message Format]
The packet has two parts:

➢ Header (64 bits): It consists of four fields
▪ Type (8 bits): Defines the type of the message (3, 4, 5, 11, or 12).
▪ Code (8 bits): Specifies the reason for a particular message type.
▪ Checksum (8 bits): Checksum over entire message (header + data).
▪ Rest of the header (32 bits): Carries different information for
different error-reporting messages.
➢ Data section (variable size): In error-reporting messages, this section
carries information about the original IPv4 packet that had the error.
◼ Encapsulation of ICMP Error-Reporting Messages: Fig. 16.18 shows the
encapsulation process.
[Fig. 16.18:
Encapsulation of ICMP
Error-reporting
Messages]
➢ The ICMP error-reporting message, in its “data section”, contains a part

of the original IPv4 packet (the header part and the first 8 bytes from the data
part) that had error.
➢ The error-reporting message itself is encapsulated in a IPv4 packet and
sent to the source host.

II. Query Messages
◼ Use: These messages are used by a host or a network manager to get specific
information about a router or another host. For example: the ping command.
◼ Types: There are 4 types of query messages (4 types of queries can be made).
Each type is identified by an integer.
1. Echo request & reply (Type: 8 and 0):

▪ The echo-request (type 8) and echo-reply (type 0) messages are
designed for network diagnostic purposes.
▪ The combination of echo-request and echo-reply messages
determines whether two systems (hosts or routers) can
communicate with each other or not.
▪ A common example of this is the ping command. This command
provides a series (instead of just one) of echo-request and echo-
reply messages.

2. Router solicitation & advertisement (Type: 10 and 9):
▪ The router solicitation (type 10) and router advertisement (type 9)
messages helps a host to know if the routers are alive and
functioning or not.
▪ A host can broadcast (or multicast) a router-solicitation
message.
▪ The router or routers that receive the solicitation message
broadcast their routing information using the router-
advertisement message.
3. Timestamp request & reply (Type: 13 and 14):
▪ Two machines (hosts or routers) can use the timestamp request
(type 13) and timestamp reply (type 14) messages to determine
the round-trip time needed for an IP datagram to travel between
them.
▪ It can also be used to synchronize the clocks in two machines.

4. Address-mask request & reply (Type: 17 and 18):
▪ A host may know its IP address, but it may not know the
corresponding mask. The address-mask request (type 17) and
address-mask reply (type 18) messages helps the host to get its
mask.
▪ To obtain its mask, a host sends an address-mask-request
message to a router on the LAN.
▪ The router responds with an address-mask-reply message,
providing the necessary mask for the host.

◼ ICMP Query Message Format: Fig. 16.19 shows the format for the ICMP query
messages.
[Fig. 16.19:
ICMP Query Message
Format]
Like the error-reporting messages this packet has also two parts:
➢ Header (64 bits): It consists of four fields
▪ Type (8 bits), Code (8 bits), and Checksum (8 bits): Have the same
functionality as that of the error-reporting messages.
▪ Identifier (16 bits) and Sequence number (16 bits): Carries
different information for different query messages.
➢ Data section (variable size): In query messages, this section carries extra
information based on the type of query.

◼ Encapsulation of ICMP Query Messages: Fig. 16.20 shows the encapsulation
process.
[Fig. 16.20:
Encapsulation of ICMP
Query Messages]
The query message is encapsulated in a IPv4 packet and sent to the target.

ICMPv6 (Internet Control Message Protocol version 6)
ICMPv6 - Why & What?
◼ ICMPv4 was not suitable for IPv6. Therefore, some of its features were
modified, and it is called ICMPv6. Fig. 16.21 compares the network layers of
version 4 and version 6.
[Fig. 16.21:
Comparison
of Network
Layer in v4
and v6]
◼ The ICMPv6 is designed to provide the services of ICMPv4, ARP, and IGMP
combined.
◼ The protocols RARP and BOOTP were dropped from the suite because they
were rarely used.

ICMPv6 Messages
◼ The working principle of ICMPv6 is exactly same as ICMPv4; the services (of
ICMPv4, ARP, and IGMP) are provided through the error-reporting and query
messages. However, in order to address the new services, some new message
types are added, and some existing message types are eliminated in each
category in comparison to the ICMPv4.
◼ Error-Reporting Messages:
In ICMPv6, 5 types of errors are reported (to the source). The table below
compares the error-reporting messages of ICMPv4 and ICMPv6.
Types of Error-Reporting Messages ICMPv4 ICMPv6

Destination unreachable Yes Yes
Source quench Yes No
Redirection Yes Yes
Time exceeded Yes Yes
Parameter problems Yes Yes
Packet too big No Yes

➢ The messages types “destination unreachable”, “redirection”, “time
exceeded”, and “parameter problems” are identical to the ones in
ICMPv4.
➢ The “source quench” message is eliminated in ICMPv6 because the

“priority” and the “flow label” fields in IPv6 datagram allow the router to
control congestion and discard the least important messages.
Therefore, in this version, there is no need to inform the sender to slow
down (quench).
➢ The “packet too big” is a new type of error-reporting message added to

ICMPv6. The message is added because in IPv6, fragmentation is the
responsibility of the source host. If the source does not make the right
packet size and the packet size becomes larger than the MTU then the
router has to drop the datagram. In such case, a packet-too-big error
message is sent to the source.

◼ Query Messages:
In ICMPv6, 4 types of queries are handled. The table below compares the query
messages of ICMPv4 and ICMPv6.
Types of Query Messages ICMPv4 ICMPv6

Echo request & reply Yes Yes
Router solicitation & advertisement Yes Yes
Timestamp request & reply Yes No
Address-mask request & reply Yes No
Neighbor solicitation & advertisement ARP Yes
Group membership IGMP Yes
➢ The messages types “echo request & reply” and “router solicitation &
advertisement ” are identical to the ones in ICMPv4.
➢ The "timestamp request and reply" messages are eliminated because

they are implemented in other protocols such as TCP and because they
were rarely used in the past.

➢ The “address-mask request and reply” messages are eliminated
because in IPv6, the subnet section of an address allows the subscriber
to use up to 232 - 1 subnets. Therefore, subnet masking, as defined in
IPv4, is not needed here.
➢ The “neighbor solicitation & advertisement” is a new type of query

message added to ICMPv6. This message addresses the service of ARP.
The working principle is exactly the same, i.e., in IPv6, whenever an address
resolution functionality is needed the source broadcast “neighbor solicitation”
message instead of an “ARP request” packet to which the target respond with an
“neighbor advertisement” message unicasted to the source.
➢ The “group membership” is another new type of query message added

to ICMPv6. This message addresses the service of IGMP.

End of Chapter 16

Chapter 16 - Network Layer Protocols

Uploaded by

Copyright:

Available Formats

Chapter 16 - Network Layer Protocols

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 16 - Network Layer Protocols

Uploaded by

Copyright:

Available Formats

Network Layer Protocols

Dr. Niroj Kumar Pani

Department of Computer Science Engineering & Applications

◼ IPv4 (Internet Protocol version 4)

◼ IPv6 (Internet Protocol version 6)

◼ Transition From IPv4 To IPv6

◼ ARP (Address Resolution Protocol)

◼ ICMP (Internet Control Message Protocol)

◼ ICMPv6 (Internet Control Message Protocol version 6)

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.2

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.3

➢ ARP (Address Resolution Protocol), RARP (Reverse Address Resolution

➢ Different Routing Protocols (such as RIP, OSPF, BGP etc.): Provides

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.4

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.5

◼ It is the main protocol of network layer that performs source-to-destination

◼ It provides the following services (through which unicasting is achieved):

◼ It is a connectionless and unreliable protocol - a best-effort delivery service.

[NOTE]: The concept of “Connection-oriented Vs. Connection-less protocols” and “Reliable

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.6

◼ Packets in IPv4 are called datagrams.

◼ Fig. 16.1 shows the IPv4 datagram format.

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.7

1. Header (20-60 bytes):

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.8

[Fig. 16.2: Encapsulation of Data in IPv4 Datagram]

▪ Data is 0 bytes if the packet is a control packet and can be up to

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.9

➢ Header length (HLEN) (4 bits):

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.10

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.11

➢ Total length (16 bits):

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.12

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.13

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.14

➢ Destination IP address (32 bits): It defines the IP address of the

➢ Options & Padding (0-40 bytes):

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.15

Solution: There is an error in this packet.

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.16

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.17

◼ Fragmentation & Reassembly - Why?:

◼ A NOTE: When a datagram is fragmented (by the source or a router), each

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.19

➢ Identification (16 bits):

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.20

[Fig. 16.3: Flags Used in

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.21

[Fig. 16.4: Calculation of Fragmentation Offset

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.22

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.23

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.24

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.25

1. The first fragment has the "Fragmentation offset" field value of 0.

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.26

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.27

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.28

Dr. N. K. Pani, Dept. of CSEA, IGIT Sarang | 16.29

◼ Like IPv4, IPv6 is also a connectionless and unreliable protocol - a best-effort