Unit 4

The Internet protocol (IP)

Outline

Internet Layer Overview

This unit explains the fundamental principle of the Internet Protocol (IP), which provides the packet
delivery system, in the TCP/IP protocol suite.
It is important to note that the IP Protocol (IP) is one of the protocols that operate at the Internet Layer of
the TCP/IP protocol suite. The protocols that operate at the Internet Layer of the TCP/IP protocol suite are:

Internet Protocol (IP) provides connectionless, best-effort delivery routing of datagrams. IP is not
concerned with the content of the datagrams. Its job is to move the datagrams to their destinations.
We will study IP in this unit.
ICMP (Internet Control Message Protocol) provides control and messaging capabilities. We will
study ICMP in this unit.
ARP (Address Resolution Protocol) determines the data link layer address for a known IP
address. We looked at how ARP works in the previous section.
RARP (Reverse ARP) determines the IP address when the data link layer address is known.

Characteristics of IP
The Internet Protocol (IP) is characterized as unreliable, connectionless, and best-effort packet delivery
service.

IP is being characterized as an unreliable service because its delivery of packet is not guaranteed.
A packet that the IP protocol is delivering may be lost, delayed, or duplicated. A sequence of IP
packets that the IP protocol is delivering may be delivered out of order. The IP protocol does not
have inherent mechanisms to detect these conditions. As a consequence, the IP protocol does not
have the means to indicate any of these conditions to the sender and/or the intended receiver of the
packets. The IP protocol does however detects when the bits in the header of the IP packet get
corrupted and discards the packets in this case. When the IP protocol discards packets because of
errors, it does not indicate to the source or the intended receiver of the packets that it has discarded
the packets.
IP is being characterized as connectionless service because when delivering a sequence of packets
from one IP device to another IP device, each packet in the sequence is treated independently by
the IP protocol. Packets in the sequence may be transmitted over different paths and crossing
different facilities. Some packets in the sequence are delivered while some may be lost in transit.
IP is being characterized as a best-effort delivery service because it spends its best effort when
attempting to deliver packets. IP does not discard packets intentionally. The unreliability (packet
loss, duplication, delay) occurs when the resources in the system are exhausted or the
underlying network(s) has failed.

To provide the service described above, the IP protocol specification must then specify the following:

The exact format of a data packet as it traverses the underlying network. We will discuss the IP
format next
The IP forwarding mechanism. We had described the IP forwarding decision mechanism in the
previous unit.
The set of rules that specify how hosts (endstations) and routers should process packets. The rules
specify how and when error messages should be generated to indicate what type of error had
occurred. The rules also specify the conditions for discarding packets. ICMP is not an integral part
of the IETF IP specification. However it is considered as a requirement by the IP protocol and
must be included in every implementation. We will study ICMP (Internet Control Message
Protocol) later in this unit.

IP Format
The IP Protocol is specified in RFC 791.
The Figure on the opposite page illustrates the format of an IP packet.

Version field specifies the protocol version in use. It is set to four, which is the current version of
the IP protocol that is in use today in the Internet.
Internet Header Length (IHL) field specifies the number of four-byte words in the Packet
header. Alternatively you can say that to determine the IPH value, you divide the length of the
header of the IP packet by 4. Since it is not possible to specify a fraction using binary bits in the
IPH field, the IP header must be padded to a multiple of 4 bytes. The IP header is typically 20
bytes long, although there are certain options specified that can be appended to the end of the
header. Therefore the typical value of the IPH field is 51. The maximum value that can be encoded
in the IHL field is 15, because the IHL field is 4 bits long. Therefore the maximum length of the
IP header is 60 bytes.
Total Length field specifies the length in bytes of the entire IP packet, including the IP header.
Since it is a 2 byte field, the maximum length of an IP packet is 65,535 bytes (216 1). The IP
Protocol is specified in RFC 791. RFC 791 specifies that IP endstations must be capable of
sending and receiving packets with a length of 576 bytes.
Type of Service (TOS) field. Until very recently, this field has not been widely used. However it
has been getting a lot of attention in the last few years within the Internet industry because of
emerging IP-based applications as Voice over IP (VoIP), video- and audio- streaming
applications, etc. which will require new classes of service. Work is under way in the IETF to
define new classes of service that may redefine the ToS field.
Time To Live (TTL) field is used to ensure that packet will not live forever in the network in case
of failure and/or misconfiguration conditions that may result in loops. The idea is that whenever
an IP device injects an IP packet into the network, it sets a value in the TTL field. Each IP device
that processes the packet should decrement the value in this field by one. An IP device must
discard the packet when the value in the TTL field is zero. Since the TTL field is 8 bits long, the
maximum possible value for the TTL field when an IP packet is injected into the network by an IP
device could be 255. However in practice IP devices inject packets with lower initial TTL values.
Protocol field specifies the higher-level protocol that was used to create the message that is being
carried in the Data field of the IP packet. Although most IP traffic uses TCP or UDP, there are
other protocols that can use IP. Each IP header must identify the destination higher-layer protocol
for the IP Packet. Transport Layer protocols are numbered. IP includes the protocol number in the
protocol field. The Table on the opposite page lists the most common values for the protocol field.
For complete list of up to date values, you may need to refer to the Assigned Numbers RFC, that
is RFC 1700 or its successor.
Header Checksum field ensures the integrity of the contents of the header. The checksum does
not apply to the Data field. Note that the Header Checksum value must be recomputed on a hopby-hop basis. The reason is that each router along the IP packet path within the network
decrements the TTL value. Changing the TTL value in the IP header invalidates the previous hop
calculated header checksum. Fragmentation, if performed, will also change the contents of the IP
header, thus forcing the header checksum to recomputed. We will discuss fragmentation next.
Source IP Address and Destination IP Address fields specify the 32-bit IP address of the sender
and intended receiver of the IP packer, respectively. Note that although an IP packet may transit
several routers in the network, the source and destination fields are never changed.

The Options and padding fields will be described later.

Note that efficiency is greatly improved when the IP header length is fixed at 20 bytes because a host or router hardware can take
advantage of this (hardware optimization). The hardware will always look at the same place in the packet to extract the header and
data parts from the IP packet. Note that including options will require more processing of the packet by the host or the router.

Protocol Field

Fragmentation of IP Packets
Assume that an endstation injects IP packets into the network. The Total Packet Length of an injected
packet is 1500 bytes. Also assume that along the path inside the network to the packets ultimate destination,
a transmission facility can only support packets up to 512 bytes long. We refer to the maximum packet
length a transmission facility can support as the facility Maximum Transmission Unit (MTU). In this
example, the MTU of that facility is 512 bytes.
A router can then break a packet into fragments in a way that each fragment will be small enough to be
transmitted across the facility with the smallest MTU. Each fragment will have its own complete IP packet
header, as illustrated in the Figure on the opposite page. Note that we assume in this figure that each
fragment header is 20 bytes long, the typical Internet Header Length. In other words for simplicity we will
assume that the original header does not contain any IP option.
Each fragment will be forwarded independently from the other fragments to the destination, where it will
be ultimately reassembled. The following fields must be included in each fragment header.
The Identification field is a unique 16-bit value that is used by the device that has fragmented the original
packet. The objective of this value is to help the receiver keeping track of the related fragments during the
reassembly process. A sender will pick a different Identification value for each packet that needs
fragmentation. A common implementation is for the sender to increment the Identification field value in
each transmitted packet that needs fragmentation. This will guarantee that the sender will only use the same
value once out of every 65,536 (216) packets it will fragment. However note that all the fragments of the
same original packet must contain the same Identification value. Since it is possible for several separate
senders to pick the same value, the receiver should not depend on the Identification values only when it is
reassembling packets. The receiver should use both the Identification value and the packet source address
when reassembling packets.
The Flags field controls the fragmentation process. It consists of 3 bits:

The most significant bit of these 3 bits must be set to zero.

The next bit (the middle bit in the Flags field) is called the Dont Fragment bit.
The value of the More Fragments bit is set to one when the fragment is not the last fragment.
The value of the More Fragment bit is set to zero when the fragment is the last fragment.
The least significant bit in the Flags field is called the More Fragments bit.
The value of the Dont Fragment bit is set to one by the sending device when it wishes that the
packet should be transmitted in one piece (no intermediate router should attempt fragmenting the
packet), or not being transmitted at all. In a case of a packet marked with the Dont) fragment bit
encounters a facility with an MTU size less than the packet length, the last router before the
facility will discard the packet and send an error message back to the IP source address in the
packet. The error message is an ICMP packet. In it, the router will indicate the MTU size of the
facility.

The Fragment Offset field specifies the offset in the original IP packet of the data being carried in the
fragment measured in units of 8 octets, starting at offset 0. The Fragment offset values in each fragment
permits the receiver to reassemble the fragments back in order. They also allow the receiver to know when
it has received all the fragments, by using the Fragment Offset value for each fragment and the length of
the Data field in each fragment. (Recall that the length of the Data field in a fragment equals the Total
Length of the fragment minus its Internet Header Length.)

Note on the Figure:

Note that each fragment, with the exception of the last one is 508 bytes, which is less than 512 bytes (the
smallest facility MTU). The reason is that the largest multiple of eight that can fit inside the 512-byte limit
is 488. Considering that the fragment header is 20 bytes, the fragment length is 508 bytes.
The next higher multiple of 8 after 488 is 496, but 496 + 20 = 516, which is larger than the facility MTU.

Homework Exercise:
An intermediate router must not attempt to reassemble the fragments back to the original packet. Could you
explain the reason? Hint: The IP protocol provides an unreliable, connectionless and best-offer service.

IP Options
The IP Options field is not required in every IP packet. Options are included primarily for network testing
and debugging purposes.
The length of the IP Options field varies depending on which options are selected. When options are
present in an IP packet, they appear contiguously with no special separators between them. Some options
are one byte long. In this case, the option consists of a single byte option code. Other options are of variable
length. In this case, the option consists of a one-byte option code, which may be followed by a one byte
indicating the length of the option, and a set of bytes specifying the option.
The encoding of the byte specifying the option code is as follows
0
Copy

1
2
Option Class

4
5
Option Number

The Copy flag controls how routers should treat options during fragmentation.

When the Copy bit value is set to 1, it specifies that the option should be copied in each fragment.
When the Copy bit value is set to 0, it specifies that the option should not be copied into all the
fragments. The option should be copied only into the first fragment.

The encoding of the Option Class field has the following meaning:
Option Class
0
1
2
3

Meaning
Datagram or Network control
Reserved for future use
Debugging and measurement
Reserved for future use

The following table shows the Option Class and Option Number values:
Option Class
0

Option Number
0

Length
1

0
0

2
3

11
variable

0
0

7
9

variable
variable

variable

Description
End of option list. It is used when the
options do not end at the end of the IP
header
No operation. It is used to align bytes in a
list of options.
Security and handling restrictions.
Loose source routing. It is used to route
an IP packet along a specified path
Record route. It is used to trace a route.
Strict source routing. It is used to route an
IP packet along a specified path. The IP
packet must be routed to all the hops that
are listed.
Internet timestamp. It is used to record
timestamps along the route.

The record route option permits the source of the IP packet to create an empty list; each entry in the list is a
32-bit field. Each router that handles the IP packet along its path to the destination adds its IP address to the
list.
The source routing option provides a way for the sender to dictate a path that the IP packet should follow
inside the network on its way to the destination. Including a sequence of IP addresses in the option specifies
the routing path.

The strict routing option means that the IP addresses listed in the option specify the exact path the
IP packet must follow to reach the destination. The path between two successive IP addresses in
the list must consist of a single physical network. An error will result if a router cannot follow the
strict source route.
The loose source routing option means that the IP packet must follow the IP addresses listed in the
option, but permits multiple network hops between two successive IP addresses in the list.

The timestamp option permits the source of the IP packet to create an empty list; each entry in the list
consists of two 32-bit fields. Each router that handles the IP packet along its path to the destination adds its
IP address in one field and a 32-bit integer timestamp.

Internet Control Message Protocol (ICMP)

The Internet Control Message Protocol (ICMP) is specified in RFC 792.
ICMP is an error reporting mechanism. It provides a way for routers that encounter an error to report the
error back to the original source. ICMP cannot be used to inform intermediate routers about error
conditions. In many cases, the original source may not have responsibility for the problem or control over a
misbehaved router along the path inside the network. The source may not be able to determine which router
along the path is causing the problem.
The reason that ICMP does not report error conditions to intermediate routers is the result of the way the IP
protocol is specified. Recall that an IP packet only contains fields that specify the original source and
ultimate destination of the packet. The IP packet does not contain a complete record of its path inside the
network (except in the rare cases where the record route option described earlier is used). In addition there
is no global knowledge of all the routes inside the network. Each router can establish and change its own
routing table. Therefore when a router detects a problem, that router cannot for certain determine the set of
intermediate routers that had handled the IP packet on its way and as a consequence cannot inform them of
the problem. Instead of silently discarding the IP packet, the router reports the problem back to the source
using ICMP. It is expected that the endstation/host administrator and the administrators of the network or
networks along the path will cooperate to locate and repair the problem.
The use of ICMP is not restricted to routers. Any IP device can send an ICMP message to any other IP
device.

ICMP Message Encapsulation

An ICMP message is encapsulated inside the data portion of an IP packet. Recall that an IP packet is also
encapsulated inside the data portion of a data link frame. IP packets carrying ICMP messages are routed the
same way as IP packets carrying user data. There are no additional reliability or priority specified for IP
packets carrying ICMP messages. As a result, ICMP messages may be lost, delayed, corrupted or
discarded. However there is an exception to the error handling procedures if an IP packet carrying an ICMP
message causes an error. No ICMP message is generated to report an error condition that is caused by IP
packets carrying ICMP messages.
Although ICMP messages are encapsulated and sent using IP, ICMP is not considered a higher level
protocol. ICMP is actually an integral part of the IP protocol. Every implementation of IP must support
ICMP.
The Figure on the opposite page shows ICMP in the context of the IP protocol stack.

ICMP Message Format

0

7
Type

15
Code
Checksum
Additional Information or unused
IP Header + First 64 data bits

Each ICMP message begins with the same three fields:

The Type field identifies the message.

The Code field provides additional information about the message type.

31

The Checksum field ensures the integrity of the ICMP message.

An ICMP message that reports an error condition always include the header and the first 64 data bits of the
IP packet that has caused the error condition. This will provide the recipient of the ICMP message (i.e., the
sender of the original IP packet) with information on which protocol(s) and which application program
were part of the IP packet that is responsible for the error condition.
The Table on the opposite page lists some of the more common ICMP messages
Type
0
3

8
9
10
11

ICMP Message
Echo Reply
Destination Unreachable
Codes for ICMP Type 3
0 Network Unreachable
1 Host Unreachable
2 Protocol Unreachable
3 Port Unreachable
4 Fragmentation Needed and but Dont Fragment Bit was Set
5 Source Route Failed
6 Destination Network Unknown
7 Destination Host Unknown
8 Source Host Isolated
9 Communication with Destination Network Administratively Prohibited
10 Communication with Destination Host Administratively Prohibited
11 Network Unreachable for Type of Service
12 Host Unreachable for Type of Service
13 Communication Administratively Prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
Redirect
Codes for ICMP Type 5
0 Redirect IP packet for the Network (or subnet)
1 Redirect IP packet for the Host
2 Redirect IP packet for the Type of Service and Network
3 Redirect IP packet for the Type of Service and Host
Echo
Router Advertisement
Router Selection
Time Exceeded
Codes for ICMP Type 11
0 Time to Live exceeded in transit
1 Fragment Reassembly Time Exceeded

ICMP (cntd)

ICMP Applications
MTU Path Discovery an Application for ICMP
Most IP implementations attempt to avoid sending IP packets that will require fragmentation by
intermediate routers. RFC 1911 describes a technique to discover the Path MTU, which involves sending
packets as large as the local link will permit and setting the Dont fragment bit in the IP header of these
packets. If these packets are successfully delivered to the destination, then the sender knows that it need not
send smaller packets. Otherwise, an ICMP error message is received as follows: ICMP Destination
Unreachable, Type 3, Code 4 Fragmentation Needed but Dont Fragment Bit was Set. In this case, the
sender will attempt smaller size packets.
Despite initial efforts to send packets that will not require fragmentation, there may be a network topology
change along the path to the destination that forces the packets to be sent over a facility with a smaller
MTU. In this case, an intermediate router may attempt to fragment the packets to the destination. However
if the Path MTU Discovery feature is enabled (i.e., the sender has set the Dont Fragment bit in the IP
header), fragmentation will not be permitted to occur. The intermediate router will send back to the sender
an ICMP error message Type 3, Code 4. When received, the sender will attempt retransmission with a
smaller packet size.
Ping: Application of ICMP
Ping is one of the most frequently used debugging tools. Ping uses the ICMP Echo Request and Echo Reply
messages. A host or a router sends an ICMP Echo request message to a specified destination. Any IP
device that receives an Echo Request must respond back to the original sender with an Echo Reply. The
request contains an optional data field. If data is included in the request, the reply will then contain a copy
of the data that was sent in the request.
Most ping implementations measure the round-trip delay between the source and destination. Often three or
five echo requests are sent in a row. The sender starts a timer that runs until the matching Echo Response
arrives. Each of the attempts is measured, and the program output typically includes the minimum,
maximum and average round-trip times.
A successful ping implicitly indicates that a working path exists both to and from the destination. Ping is
actually indicating the following when it is successful:

There is a functioning path from the source to the destination.

The IP device with the destination IP address is up.
There is a functioning path from the destination back to the source.

An unsuccessful ping may have failed because:

there is no available path to the destination,

the destination is down, or
there is no return path from the destination.

Therefore an unsuccessful ping does not always mean that the destination is down.

Traceroute: An Application for ICMP

A series of UDP packets are sent towards some destination in such a way that each UDP sent generates an
error message from a different router along the path to the destination.
The initial UDP packet to the destination is sent with TTL =1. The first router receives that packet and
decrements the TTL, making it 0. This will cause the router to discard the UDP packet and send back to the
sender an ICMP error message with Type 11 Time Exceeded. The router will send the ICMP message
from the interface on which the UDP packet has arrived. The sender now knows the IP address of the first
router interface along the path to the destination.
The sender sends an identical UDP packet as the initial one to the destination, but this time with TTL = 2.
The first router will receive the UDP packet, decrement the TTL and forward it to the next hop. The nexthop router will receive the packet and decrement the TTL, which is 0 by now. This next-hop router will
then send back to the source an ICMP error message with Type 11 Time Exceeded. Again the ICMP
packet is sent from the interface on which the UDP packet has arrived. The sender now knows the IP
address of the second router interface along the path to the destination.
The procedure is repeated by incrementing the TTL by one each time, until the UDP packet reaches the
destination. Each router along the path has identified itself by means of ICMP messages. At the same time,
the sender is able to collect the round trip time at each hop.
Once the sender has incremented the TTL value in the UDP packet high enough that the UDP packet can
reach the IP address of the destination, the destination will attempt to deliver the UDP packet to the port
indicated in the packet. The traceroute program selects a high UDP port number when sending the UDP
packets to maximize the chance that there will be no matching open socket for the UDP packet at the
destination. Recall that the objective is for the destination to send an ICMP error message. If true, the
destination will send back to the source an ICMP error message with Type 5 Destination Unreachable
and Code 3 Port Unreachable.