IP

The IP is the internetworking protocol that offers a service with the following
characteristics [4, 5]:
• It is connectionless, so units of network layer data protocol, denominated
datagrams in the IP context, are dealt with in an individual
way from the source host up to the destination host.
• It is not reliable. The datagrams can be lost, duplicated, or disordered,
and the network does not detect or report this problem.
As for the IP functionality, two basic functions are carried out by the
IP: addressing and fragmentation. The IP entities use the IP address to transmit
the datagrams toward their destination. The selection of the path to be
followed is called routing. In the same way, the IP entities use particular fields
of the header of the datagrams for fragmentation and reassembly when
necessary.
The IP datagram has the structure shown in Figure 3.1. The IP datagram data field transports the information belonging to the
protocols of higher layers, while the IP datagram header field transports the
information that the IP entities really handle and therefore determine the
previously mentioned functionalities. The format of the IP header, shown in
Figure 3.2, It contains a fixed part of 20 bytes and an optional part of
between 0 and 40 bytes.
The version field allows the unambiguous coexistence, in the same
network, of packets of different versions of IP; the version currently being
used (corresponding to the structure of the datagram that we are seeing) is
version 4.
The HLen field specifies the length of the header, given that it can vary
due to the presence of optional fields. It is specified in words of 32 bits. The
minimum length is five and the maximum is 15, the equivalent of which is
40 bytes of optional information. The length of the header must always be a
TCP/IP Protocol Stack 65
Figure 3.1 IP datagram format.
Figure 3.2 IP header format. whole number of words of 32 bits. If the length of the optional fields is not
an exact multiple of 32 bits, a padding is added to the end of the header.
The type of service field is used to indicate to the network the desired
QoS [6]. This field, made up of 8 bits, has evolved over time in terms of its
structure, although not in its fundamental aim, in such a way that it is now
used to support what is known as differentiated services or DiffServ. To be
exact, these 8 bits are assigned to two fields, one of 6 bits called differentiated
services codepoint (DSCP), which allows the handling of up to 64 levels, and
another of 2 bits of reserved use.
The total length field specifies the length of the whole datagram
(including header) in bytes. The maximum value is 65,535 bytes.
The next four fields, identification, don’t fragment (DF), more fragments
(MF), and fragment offset, are related to the fragmentation of datagrams,
which will be explained later.
The time to live (TTL) field allows the discarding of a datagram when it
has made an excessive number of hops or has passed an excessive time traveling
in the network and is presumed useless. It is a regressive counter that
indicates the remaining lifetime of the datagram measured in seconds, in
such a way that the datagram must be discarded if its value reaches zero. Its
purpose is to avoid the production of loops due to a routing problem and to
prevent a datagram from remaining indefinitely in the network. It is not trivial
to precisely calculate the time that the datagram takes to travel between
two gateways; therefore, in practice what is done is to subtract one from the
TTL for each hop, and if the datagram waits more than one second at a gateway
to subtract one for each second of waiting time. As the datagrams hardly
ever stay at a gateway more than one second, in practice, this parameter
works as a hop counter. If fragmentation takes place, the receiver host can
retain datagrams for several seconds while it waits for all of the fragments to
arrive. In this case, the host subtracts one from the TTL for each second
waiting and can even discard datagrams for this reason. Values of TTL of 32
or 64 are habitual.
The protocol field specifies which transport-level protocol the datagram
corresponds to. Table 3.1 shows some of the possible values of this field.
The checksum field is for detecting errors produced in the header of the
datagram. It is obtained from the one’s complement of the header taken in
fields of 16 bits (including the optional fields if there are any). The sum of
one’s complement of all of these blocks gives the result. The checksum
enables the protection of the datagram from an alteration in some field of the
header, which could be produced, for example, by a hardware problem at a
gateway. Note that the checksum only covers the header of the datagram, not the data. The checksum field must be calculated in each hop, because the
TTL, at least, changes. At gateways with a lot of traffic, the recalculation of
the checksum is a drawback from the point of view of performance.
The source address and destination address fields correspond to IP
addresses in accordance with the format we will see later.
The optional fields of the header are not always supported at the gateways
and are rarely used; of these, the following can be highlighted:
• Record route. This option requests each gateway that the datagram
goes through to write its address in the header in order to provide a
trace of the route followed for tests or diagnosis of problems.
• Timestamp. This option acts in a similar way to a record route, but
as well as noting the IP address of each gateway. It notes in another
32-bit field the instant at which the datagram passes through the
gateway.
• Source routing. It allows the emitter to specify the route that the
datagram must follow to the destination. There are two variants.
Strict source routing specifies the exact route hop by hop in such a
way that if in any case the route specified is not possible for any reason,
an error will be produced. Its functionality is equivalent to that
of bridges with routing from the source. With loose source routing,
the gateways the datagram should pass through are specified, but the network has freedom to use other unspecified intermediate gateways
when it is considered necessary.
The use of optional IP header fields generally leads to problems of performance,
given that the implementations of the gateways optimize the code
for normal situations (i.e., for datagrams without optional fields).