e-PG Pathshala

Subject : Computer Science

Paper: Computer Networks

Module: IP options and ICMP

Module No: CS/CN/17

Quadrant 1 – e-text

We have looked at many aspects of IP in the last few modules – best-effort service,
fragmentation and reassembly, addressing, subnets, CIDR, address management and
configuration. In this module we will examine one important field in the IP packet that we
have not touched upon so far – IP options. We will then look at ICMP – which is a
companion protocol to IP, and used to report errors and control information for IP.
Learning Objectives:

 To understand the use of the IP options

 To examine the ICMP protocol in detail – messages, formats and uses – error
reporting and others.
17.1 IP options

Let us take a look at the IP datagram format which is reproduced below in Fig. 17.1.

Figure 17.1 IP datagram format – Options expanded

We have seen the functions of all the fields in the header, except IP options. We will
now look at the use of this field. In a sense the IP options field is used to manage or
collect information to manage the flow of IP packets – network control or measurement.
One use of the option field is to enable a source-routing operation wherein a source can
specify the path to be taken by the IP packet to reach its destination, rather than use the
path determined by the routing protocol. Another use is to record the route taken, along
with the time stamps of when the routers are visited.

Thus there are three major options supported : Source routing, Record route and Time-
stamp, as shown in Table 17.1. Depending on the option, the information
specified/collected will vary. Hence the options field has 4 sub-fields : code, length,
pointer, variable data. The code field is a 1 byte field, that identifies the option (using an
option class – 2bits, and an option number – 5 bits). It has one leading bit – called the
copy bit, which determines whether the option field is to be copied into each fragment in
case this IP packet with an option is fragmented. We will see how this is used after we
have discussed the options.
Table 17.1 IP options

Option Option Class Option No. Length

Source Routing

Strict Source Routing 0 (Datagram or n/w 9 Variable

control)

Loose Source Routing 0 3 Variable

Record Route 0 7 Variable

Time Stamp 2 (Debugging & 4 Variable

Measurement)

17.1.1 Source Routing

Source routing is an option in which the source specifies the route – the IP addresses
of the routers through which the packet is to be sent to the destination. If this option is
specified, all that a router has to do on receiving the packet is to use this information in
the packet itself to forward the packet (need not look-up the forwarding table).
There are two variations of source routing – strict source routing and loose source
routing. In strict source routing a complete list of each router to be visited, in order, is
specified. In loose source routing, a partial list of routers to be visited along the path
from the source to the destination are specified. Thus, in the latter, the list of routers
must be visited in the order specified, but other routers may also be visited in between
the ones specified. The format for this option is given in Table 17.2.
Table 17.2 Source Routing & Record Route Option

Length specifies the number of addresses specified, and pointer points to the next
router to be visited. At each router, the pointer is incremented to identify the next router
to be visited.
17.1.2 Record Route option

The format of the record route option is the same as that of source-routing, but the way
it is handled is entirely different. In source routing, all the entries (router addresses) are
filled by the source, whereas in record route, at the source, all the entries are empty,
and the pointer is pointing to the first entry. As each router is visited by the packet, that
IP address is added to the list, and the pointer is incremented. However, the number of
entries is limited to 9, since there is a total size limitation of 60 bytes (20 bytes standard
header + 4 bytes for the options header + 9x4 router addresses). The destination will
thus get a complete record of the route taken, and it can process it as appropriate.
17.1.3 Time Stamp option

The time stamp option has a format as shown in Table 17.3. It is to be interpreted in a
manner similar to the record route option, except that we also have the timestamp
information – in universal time - of when the packet visited each router. Thus, this option
allows us to not only get the list of devices visited, but also the time duration for each
hop along the path.
 Table 17.3 Time stamp option

Code Length Pointer

IP address of first router in the path

Timestamp at first router in the path

IP address of nth router in the path

Timestamp at nth router in the path

Coming to the copy bit in the IP option code field, as we mentioned earlier, this bit
indicates whether the options information is to be copied into each fragment, when a
given IP packet is fragmented along the path. It needs to be copied, if this information is
required for each fragment. It is easy to see that for the source routing option, it must be
copied, because we would like all the fragments to follow the path specified by the
source. But, when it comes to record route, and timestamp, it may be enough if one
fragment records all the path related information. Every fragment need not have this
overhead in processing. Hence the copy bit need not be set for these options.
With this we have covered all details of the IP protocol. We now move to the companion
protocols to IP at the network layer.
17.2 ICMP

One of the important companion protocols to IP is ICMP – Internet Control Message

Protocol, which is essentially a control and error reporting or messaging protocol.
Remember that IP is a best effort service protocol. So it tries, but it may drop packets
for various reasons, and it does not provide any feedback to the senders. This feedback
is meant to be provided by ICMP. In that sense it is an error reporting protocol. Also, it
provides a facility to check if packets are getting through the network, the latency
incurred etc. In that sense, it is a control or status reporting protocol. Thus ICMP
monitors the status of IP at the intermediate routers and the end hosts, and reports
errors, and is considered as a network layer protocol.
Although it is a Layer-3 protocol, it runs over IP; i.e., we have an L3-ICMP packet
encapsulated in an L3-IP packet, as shown in Fig. 17.2

Figure 17.2 ICMP packet encapsulated in IP

17.2.1 ICMPv4 Packet Format

The ICMP header consists of two 32-bit words. The first word has three fields – Type,
Code, and checksum. Type and code are used to identify the type of message or error
event. The checksum is calculated on the ICMP message, using 16-bit 1’s complement
addition as in the IP protocol. The second word has fields related to the type of
message, and varies. This is followed by the data. The data field in most cases,
consists of the IP header plus minimum - the first 64 bits of the packet that caused the
ICMP message to be sent (as per RFC 792, “Internet Control Message Protocol” ) to as
much of the original datagram as possible without the length of the ICMP datagram
exceeding 576 bytes (as per RFC 1812, "Requirements for IP Version 4 Routers”).
17.2.2 ICMP Types

There are a number of ICMP message types as shown in Table 17.4.

Table 17.4 ICMP Message types

Type Code Description

0 0 Echo reply (ping)

3 0 Destination network unreachable

3 1 Destination host unreachable

3 2 Destination protocol unreachable

3 3 Destination port unreachable

3 4 Fragmentation needed and DF set

3 5 Source route failed

3 6 Destination network unknown

3 7 Destination host unknown

4 0 Source quench (congestion control)

5 0 Redirect (destination network)

5 1 Redirect (host)

8 0 Echo request (ping)

9 0 Route advertisement

10 0 Router discovery

11 0 TTL expired

12 0 Bad IP header

We will examine these messages under a few categories.

Echo Request and Reply Messages:

This set of messages is used to check if the path from a source to destination is
available, and if the destination is active. To do so, the source sends an echo request
(type=8) to a destination, and the destination is expected to respond with an echo reply
(type=0). Some optional data may be sent along with the request. If it is sent, then t he
data received is echoed back (entirely included) in the Echo Reply – thus justifying the
name of echo request and reply.

The format of this pair of messages shown in Fig. 17.3.

 Figure 17.3 ICMP Echo Request and Reply
The identifier and sequence number are used to match the echo request and reply
messages.
The ping command which is used to check if a destination is up and available, uses
echo request and reply.
Destination Unreachable messages (type=3):

The destination may be unreachable for various reasons. The network itself may be
unreachable. Or the network may be reachable, but the desired host may be
unreachable. The host also may be reachable, but the protocol or similarly the port may
be unreachable. The destination unreachable message has information to identify
whether it is a network, host, or port that is unreachable.

In addition to this, there is also another situation where the destination is unreachable –
that is, when fragmentation is req uired at an intermediate router (due to MTU) but the
‘do not fragment’ bit in the IP header is set. Code 4 of type 3 message is used to report
this situation. The next-hop MTU field gives the reason for the fragmentation. The
format of this message is shown in Fig.17.4.

Figure 17.4 ICMP destination unreachable

This message is sent by the router/device at which the problem is encountered, and
sent to the source.

Source Quench:
This message is used to signal congestion in the network – at a router. When buffer
overflows and the packet is dropped, the router sends a source quench (type=4) to the
source asking it to quench – reduce its flow of data. Information about the dropped
packet is given in the data part of the ICMP packet. The format of this message is
shown in Fig. 17.5.

Figure 17.5 ICMP Source Quench

Route redirect:

If a host forwards a packet to a wrong router, router sends a redirect (type=5, code=0 or
1, (network/ host)) ICMP message to source , asking it to go via a different router. The
routers IP address is mentioned in the ICMP message (Fig. 17.6).

Figure 17.6 ICMP Route redirect

Time Exceeded Message:

When the TTL of a packet goes to zero at a router, and is dropped, a Time exceeded
message is sent by the router to the source. The message format is the same as that of
the source quench message(Fig. 17.5).

Time stamp request and reply messages:

This message is sent by the source to the destination to which it needs to find the
transmission time. The reply message is sent back to the source by the destination
along with time stamps as shown in Fig. 17.7.

Type Code Checksum

Identifier Sequence number

Originate Timestamp

Receive Timestamp

Transmit Timestamp

Figure 17.7 ICMP Time Stamp Messages

The identifier and sequence number are used to match the request message and the
reply message. The request message has the originate timestamp field filled in. It is
copied back in the response message along with the time at which the request was
received (receive timestamp), and the time at which the response was transmitted by
the destination (transmit timestamp). This pair of messages is useful in calculating the
RTT.

Other ICMP Messages:

Parameter problem: If there is an error in any of the parameters in the IP header of a
packet, it cannot be processed, and this ICMP message is generated. For example, we
could have an IP header error, such as wrong option field (type=12). The code value
may give more details such as ‘ IP header is invalid’ (Code=0) or ‘a required option is
missing’ (Code=1).

Information Request/Reply, Address Mask Request/Reply are other messages used to

obtain some information or the address mask from a router.
17.2.3 ICMP – Some interesting applications

Other than the fact that ICMP messages give feedback when something goes wrong
with IP forwarding, these messages can be used to build some interesting utilities to
check out the network status.
As was mentioned earlier, ‘ping’ is a command that is build using the echo request and
reply messages.

Another very interesting utility is a trace-route command to trace the complete path from
the source to the destination (with the source getting that information – unlike using the
IP option of trace-route). This command can be built by triggering the time-exceeded
message. This can be done by setting appropriate values in the TTL field of the IP
packet being sent. An echo request packet can be sent.

Initially, TTL is set to 1. As soon as the packet reaches the first router, its TTL is
decremented to 0, and a time-exceeded ICMP message is generated by the router and
sent to the source. We have now got the address of the first router (in the source
address of this ICMP message). Now another packet is sent with a TTL value of 2. This
packet will go up to the second router in the path, where its TTL will become 0, and a
time exceeded message will be generated by that router. We now have the address of
the second router. We can proceed in this manner by sending packets with increasing
TTL values, until the packet reaches the destination, when we will get a echo reply
message. If we compile all the time-exceeded messages generated in-between, we
have the complete path!

Instead of sendi ng a series of echo request messages, a series of UDP messages can
also be sent with an unlikely port number. The same result can be obtained. The final
destination will send back a destination (port) unreachable message. When each ICMP
message arrives, the source can also calculate the RTTs to the respective routers.
Useful for user-level trouble-shooting !!
17.2.4 ICMPv6

With the shift towards IPv6, the companion protocol also has shifted to ICMPv6. This
protocol has many new message types and codes added to cater to the new
environment that IPv6 is used for. It is also organized better with separation of error-
reporting, and informational messages. Some of these are just mentioned below. We
will defer the discussion of these until we have discussed the IPv6 protocol.

New type and code

Type 0..127: error report

1: Destination unreachable
2: Packet too big

3: Time Exceeded
4: Parameter problem
Type 128..255: informational

128, 129: Echo request & reply (RFC 2463)

130, 131, 132: Multicast group membership management (RFC 2710)
133,134: Router solicitation and advertisement (RFC 2461)
135, 136: Neighbor solicitation and advertisement (RFC2461)

137: Redirect (RFC 2461)

138: Router renumbering (RFC 2894)

139, 140: node information query/response (draft, name-lookups)

141, 142: Inverse ND solicitation/ Adv message (RFC 3122)
150, 151: Home agent address discovery request/reply (draft)

152, 153: Mobile prefix solicitation/advertisement

We can see that there is support for mobile IP, multicasting etc. in this version.
17.3 Summary

To summarize, we have looked at the details of IP Options: Source Routing, Record

Route, and Time Stamp. We have looked at the different messages of ICMP, their
formats and their uses.
References:

1. Computer Networking: A Top Down Approach Featuring the Internet, 6th edition.
Jim Kurose, Keith Ross
Addison-Wesley, 2012.

2. Computer Networks: A systems Approach, 4 th edition, David Peterson, Davie,

Morgan Kauffman, 2012.
3. Computer Networks An Open Source Approach, Ying-Dar Lin, Ren-Hung Hwang,
Fred Baker, McGraw Hill, 2012.