IPv4 Header Structure and Functionality
IPv4 Header Structure and Functionality
32 Bit
Source address
Destination address
By marking the datagram with the DF bit, the transmitter knows that the data will arrive like this.
how they were transmitted, that is in one piece, even if this means imposing on the
datagram to avoid a small packet network placed on the best path, to follow-
but rather a non-optimal path. Any computer must accept fragments with
size of 576 bytes, but it can also accept shorter ones. MF is the acronym for More
Fragments, or rather more fragments. All the fragments, except the last one, have this bit set-
It is essential to know when all the fragments of a datagram have arrived.
Fragment offset indicates the position of the fragment in the datagram.
all fragments except the last in a datagram must be multiples of 8 bytes, which
is the size of the elementary fragment. Since 13 bits are available, there can be
a maximum of 8,192 fragments per datagram, consequently the maximum length of
a datagram is equal to 65,536 bytes, one more than the total length field. The field to live
(time to live) is a counter used to limit the life of a packet. It is assumed
that the count is expressed in seconds, so the maximum duration is 255 sec. The counter-
should be decreased at every jump, or if it remains for a long time acco-
data in a router (in this case, it should be decremented multiple times). In reality,
however, the value reflects only the number of hops. When it reaches zero, the packet is unloaded.
This is a notification packet sent to the source host. This feature prevents the
datagrams spinning forever, an event that could happen in case of dan-
routing table management. When it has assembled a complete datagram, it
strato network needs to know what to do with it. The campoprotocol (protocol) indicates
which transport process is waiting for that data. TCP is one possibility, but there are also
UDP and other solutions. The numbering of protocols is valid globally on the Internet. I
protocol numbers and the other assigned numbers have been listed in the past in the docu-
mento RFC 1700, but today they are contained in an online database that can be downloaded.
to the site [Link]. The header checksum (header checksum) verifies
it's just the header. This checksum helps to detect errors generated by allocations of
defective memory in the router. The algorithm sums all the half words of 16 bits just
arrive, using one’s complement arithmetic, and then take the one’s complement of
result. For the purposes of this algorithm, it is assumed that the header checksum is zero at the
rivo. This algorithm is more robust than a normal sum. Note that header checksum
it must be recalculated at each jump, because at least one field always changes (the field
time to live), but some tricks allow for faster processing. Source address
(source address) edestination address(destination address) indicate the number of
network and the number of hosts; Internet addresses are examined in the next paragraph. The field
options was intended as an escape route to provide for the subsequent versions of pro-
I allow the possibility of including information not present in the original project, to the hopes-
testers of new ideas and designers to avoid assigning header bits
all information used more rarely. The options are of variable length. Each one starts with
a 1-byte code that identifies it; some are followed by an option length field (length-
option length) of 1 byte that precedes one or more bytes of data. The options field is filled
with multiples of four bytes. Originally, five options were defined, listed in Figure
5.54; subsequently, new ones have been added.