Download Module 4 unit 3, 4

Unit 3: Internet Protocol (IP)
Internet Protocol (IP) is the principal set (or communications
protocol) of digital message formats and rules for exchanging
messages between computers across a single network or a series
of interconnected networks, using the Internet Protocol Suite
(often referred to as TCP/IP). Messages are exchanged as
datagrams, also known as data packets or just packets.
IP is the primary protocol in the Internet Layer of the
Internet Protocol Suite, which is a set of communications
protocols consisting of four abstraction layers: link layer
(lowest), Internet layer, transport layer and application
layer (highest).
The IPv4 datagram is conceptually divided into two parts: the
header and the payload. The header contains addressing and
control fields, while the payload carries the actual data to be
sent over the internetwork. Unlike some message formats, IP
datagrams do not have a footer following the payload.
In networking IP Payload Compression Protocol, or
IPComp, is a low level compression protocol
for IP datagrams defined in RFC 3173. The intent is to
reduce the size of data transmitted over congested or slow
network connections, thereby increasing the speed of such
networks without losing data.
Each packet comprises a mandatory base header, followed by
the payload. The payload consists of two parts: optional
extension headers and data from an upper layer. The base
header occupies 40 bytes, while the extension headers and data
from the upper layer contain up to 65,535 bytes.
IP header format
The IP datagram header contains the following fields:
•Version: Identifies the version of IP used to generate the
datagram. For IPv4, this is of course the number 4. The purpose of
this field is to ensure compatibility between devices that may be
running different versions of IP. In general, a device running an
older version of IP will reject datagrams created by newer
implementations based on the assumption that the older version
may not be able to interpret newer datagrams correctly.
•Internet Header Length (IHL): This field specifies the length of the
IP header, in 32-bit words. This includes the length of any options
fields and padding. The normal value of this field when no options
are used is 5 (5 32-bit words = 5 × 4 = 20 bytes).
•Total Length: This field specifies the length of the entire
IP packet (including the IP header and the IP payload). It
specifies the total length of the IP datagram, in bytes.
Since this field is 16 bits wide, the maximum length of an
IP datagram is 65,535 bytes, though most are much
smaller.
•Type Of Service (TOS): A field designed to carry
information to provide quality of service features, such
as prioritised delivery, for IP datagrams. It was never
widely used as originally defined, and its meaning has
been subsequently redefined for use by a technique
called Differentiated Services (DS).
Identification: If the IP packet is fragmented during transmission,
all the fragments contain the same identification number to
identify the original IP packet they belong to. This field contains a
16-bit value that is common to each of the fragments belonging to
a particular message.
For datagrams originally sent unfragmented, it is still filled in so
that it can be used if the datagrams must be fragmented by a
router during delivery. This field is used by the recipient to
reassemble messages without accidentally mixing fragments from
different messages. This is needed because fragments may arrive
from multiple messages mixed together, since IP datagrams can
be received out of order from any device.
•Flags: As required by the network resources, if the IP packet is
too large to handle, these ‘flags’ indicate whether it can be
fragmented. In this 3-bit flag, the MSB(most significant bit) is
always set to 0.
•Fragment Offset: This offset tells the exact position of the
fragment in the original IP packet. When fragmentation of a
message occurs, this field specifies the offset, or position, in the
overall message where the data in this fragment goes. It is
specified in units of 8 bytes (64 bits). The first fragment has an
offset of 0.
•Time To Live (TTL): To avoid looping in the network,
every packet is sent with some TTL value set, which tells
the network how many routers (hops) it (the packet) can
cross. At each hop, its value is decremented by one, and
when the value reaches zero, the packet is discarded.
•Protocol: This field tells the network layer at the
destination host which protocol the packet belongs to,
i.e. the next level protocol. For example, if the protocol
number of ICMP is 1, TCP will be 6 and UDP will be 17.
•Header Checksum: This field is used to keep the checksum
value of the entire header which is then used to check if the
packet is received error-free. A checksum is computed over
the header to provide basic protection against corruption in
transmission.
•This is not the more complex cyclic redundancy check (CRC)
code typically used by data link layer technologies such as
Ethernet; it is just a 16-bit checksum. It is calculated by
dividing the header bytes into words (a word is two bytes)
and then adding them together. The data is not
checksummed, only the header. At each hop, the device
receiving the datagram does the same checksum calculation,
and in the event of a mismatch, discards the datagram as
damaged.
•Source Address: This field contains the 32-bit address of the
sender (or source) of the packet, i.e. the 32-bit IP address of the
originator of the datagram. Note that even though
intermediate devices such as routers may handle the datagram,
they do not normally put their address into this field – the
address always belongs to the device that originally sent the
datagram.
•Destination Address: This field contains the 32-bit address of
the receiver (or destination) of the packet, i.e. the 32-bit IP
address of the intended recipient of the datagram. Again, even
though devices such as routers may be the intermediate targets
of the datagram, this field is always for the ultimate
destination.
Options: This is an optional field which is used if the value
of the IHL is greater than 5. This field may contain values
for options such as Security, Record Route, Time Stamp,
etc.
Comparison between IPv4 and IPv6 headers
The following points detail the differences between IPv4 and IPv6
headers.
•The Header Length field is eliminated in IPv6 because the length
of the header is fixed in this version.
•The Type Of Service (TOS) field is eliminated in IPv6. The Traffic
Class and Flow Label fields together take over the function of the
TOS field.
•The Total Length field is eliminated in IPv6 and replaced by the
Payload Length field.
•The Identification, Flags and Fragment Offset fields are eliminated
from the base header in IPv6 and are, instead, included in the
fragmentation extension header.
•The TTL field is called the Hop Limit field in IPv6.
•The Protocol field is replaced by the Next Header field.
•The Header Checksum field is eliminated because the checksum is
provided by upper layer protocols; it is therefore not needed at this
level.
• The Options fields in IPv4 are implemented as extension headers
in IPv6.
Unit 4: Internet Control Message Protocol (ICMP)
Introduction
Internet Control Message Protocol, or ICMP, was designed to send
control messages between routers and hosts. For example, an ICMP
packet may be sent when a router is experiencing congestion or
when a destination host is unavailable.
An ICMP packet has a slightly different structure to those we have
seen before. In an IP packet, the ICMP header follows the IP header,
but it is not considered a layer 4 header like TCP or UDP. Instead,
ICMP is considered an integral part of IP; in fact, every vendor’s
implementation of IP is required to include ICMP.
•Type: ICMP has many messages that are identified by a “Type”
field.
•Code: Many of these ICMP types have a “Code” field. The Code
field contains either a zero (0) or a one (1), which can be
denoted as follows:
o 0 = time to live exceeded in transit;
o 1 = fragment reassembly time exceeded.
Checksum: The checksum is the 16-bit one’s complement of the
one’s complement sum of the ICMP message, starting with the
ICMP Type field. When computing the checksum, the Checksum
field should be zero. This checksum may be replaced in the
future.
Internet Header + 64 bits of Data Datagram: The Internet header
and first 64 bits of the original datagram’s data are used by the
host to match the message to the appropriate process. If a
higher level protocol uses port numbers, these port numbers are
assumed to be in the first 64 data bits of the original datagram’s
data.