I'm a beginner of TCP/IP suite.
One field of ip header named HEADER CHECKSUM is formed by treating the header as a sequence of 16 bit integers,adding them together using one's complement arithmetic,and then taking the one's complement of the result.
But the ip header also includes TTL field,which may change in the transmission.
Why would it not lead inconsistence between the sender and receiver?
The checksum is recomputed at every hop
As the TTL field is decremented on each hop, a new checksum must be
computed each time. The method used to compute the checksum is defined
by RFC 1071
Related
While going through IP header checksum i.e. 1's complement of 1's complement sum of 16 bits data, I can't help but think that how come this method can detect error/alteration in data. For example, computer A sends a packet with data (12 and 7) and computer B receives the packet but with data altered (13 and 6). Hence in the receiver, checksum still match however data is altered. Could you please help me to understand if I am missing something in this topic?
Thank you.
Is IP header checksum a full proof method of error detection?
No.
The IP header checksum's purpose is to enable detection of a damaged IP header. It does not protect against manipulation or damage to the data field (which often has its own checksum).
For protection against manipulation a cryptographic method is required.
I am currently going through my networking slides and was wondering if someone could help me with the concept of fragmentation
so i understand the first part till "108 Bytes" but what I don't understand is this "8 Bytes = 13.5 => 13 * 8
Bytes = 104 Bytes"
what are these extra bytes ?
the rest is clear.
You must fragment the packet payload on eight-byte boundaries. With a 128-byte MTU, the largest payload fragment you can have is 104 bytes, which is smaller than simply subtracting the IP header from the MTU (108 bytes). What the text is telling you that subtracting the packet header size (20 bytes) from the MTU, the next smaller fragment size divisible by eight is 104 bytes.
RFC 791, Internet Protocol has a complete description of how IP fragmentation works:
Fragmentation
Fragmentation of an internet datagram is necessary when it originates
in a local net that allows a large packet size and must traverse a
local net that limits packets to a smaller size to reach its
destination.
An internet datagram can be marked "don't fragment." Any internet
datagram so marked is not to be internet fragmented under any
circumstances. If internet datagram marked don't fragment cannot be
delivered to its destination without fragmenting it, it is to be
discarded instead.
Fragmentation, transmission and reassembly across a local network
which is invisible to the internet protocol module is called intranet
fragmentation and may be used [6].
The internet fragmentation and reassembly procedure needs to be able
to break a datagram into an almost arbitrary number of pieces that can
be later reassembled. The receiver of the fragments uses the
identification field to ensure that fragments of different datagrams
are not mixed. The fragment offset field tells the receiver the
position of a fragment in the original datagram. The fragment offset
and length determine the portion of the original datagram covered by
this fragment. The more-fragments flag indicates (by being reset) the
last fragment. These fields provide sufficient information to
reassemble datagrams.
The identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of an
internet datagram sets the identification field to a value that must
be unique for that source-destination pair and protocol for the time
the datagram will be active in the internet system. The originating
protocol module of a complete datagram sets the more-fragments flag to
zero and the fragment offset to zero.
To fragment a long internet datagram, an internet protocol module (for
example, in a gateway), creates two new internet datagrams and copies
the contents of the internet header fields from the long datagram into
both new internet headers. The data of the long datagram is divided
into two portions on a 8 octet (64 bit) boundary (the second portion
might not be an integral multiple of 8 octets, but the first must be).
Call the number of 8 octet blocks in the first portion NFB (for Number
of Fragment Blocks). The first portion of the data is placed in the
first new internet datagram, and the total length field is set to the
length of the first datagram. The more-fragments flag is set to one.
The second portion of the data is placed in the second new internet
datagram, and the total length field is set to the length of the
second datagram. The more-fragments flag carries the same value as
the long datagram. The fragment offset field of the second new
internet datagram is set to the value of that field in the long
datagram plus NFB.
This procedure can be generalized for an n-way split, rather than the
two-way split described.
To assemble the fragments of an internet datagram, an internet
protocol module (for example at a destination host) combines internet
datagrams that all have the same value for the four fields:
identification, source, destination, and protocol. The combination is
done by placing the data portion of each fragment in the relative
position indicated by the fragment offset in that fragment's internet
header. The first fragment will have the fragment offset zero, and
the last fragment will have the more-fragments flag reset to zero.
Per the definition of the Fragment offset field in the IP header:
Fragment offset(13 bits): In case of fragmented IP datagrams, this field contains the offset( in terms of 8 bytes units) from the start of IP datagram. So again, this field is used in reassembly of fragmented IP datagrams.
So even though payload sizes can be whatever, offset values can only be multiple of 8 bytes on IP headers thus payload sizes are 8-byte multiples. The calculation rounds down the IP payload size.
When we sent packets from one router to another router on the network layer and the packet size is greater than the MTU (maximum transferable unit) of the router, we have to fragment the packet. My questions is: suppose we need to add padding bits in last fragment, then where do we add padding bits (in the LSB or MSB) and how does the destination router differentiate between packet bits or padding bits?
I want you to consider the following things before:
Limit on the maximum size of IP data-gram is imposed by data link protocol.
IP is the highest layer protocol that is implemented both at routers and hosts.
Reassembly of original data-grams is only done at destination host. This takes off the extra work that need to be done by the routers present in the network core.
I will use the information from the following image to help you get to the answer with an example.
Here initial length of the packet is 2400 bytes which needs to to fragmented according to MTU limit of 1000 bytes.
There are only 13 bits available for the fragment offset and the offset is given as a multiple of eight bytes. This is why the data fields in first and second fragment has size of 976 bytes (It is the highest number divisible by 8, which is smaller than 1000 - 20 bytes). This makes first and second fragment of total size of 996 bytes. The last fragment contains the remaining of 428 bytes of payload (with 448 bytes of total).
Offset can be calculated as 0; 976/8 = 122 and 1952/8 = 244.
When these fragments reach the destination host, reassembly needs to be done. Host uses identification, flag and fragmentation offset for this task. In order to make sure which fragments belong to which data-gram, host uses source, destination addresses and identification to uniquely identify them. Offset values and more fragment bits are used to determine whether all fragments have arrived or not.
Answer to your question
The need to divide payload into multiples of 8 is only required for non-last fragment. Reason of using offset dividing by 8 helps the host to identify the starting address of the next fragment. The host don't need the address of the next fragment if it encounters the last fragment. Thus, no need to worry about payload being multiple of 8 in case of last fragment. Host checks the more fragment flag to identify the last fragment.
A bit of additional information: It is not the responsibility of the network layer to guarantee the delivery of the data-gram. If it encounters that one or more fragment(s) have not arrived then, it simply discards the whole data-gram. Transport layer, which is working above network layer, will take care of this thing, if it is using TCP, by asking the source to re-transmit the data.
Reference: Computer Networking-A Top Down Approach, James F. Kurose, Keith W. Ross (Fifth Edition)
You don't need to add any padding bits. All bits will be push on down the route until the full frame has been sent.
Given an ip header with header checksum calculated, how can i efficiently recalculate checksum after modifying one of the 16bit words in the header?
It's fully described in RFC 1624.
Normally at SO a mere link is not an answer, but in this case it is.
Why does UDP have the field "UDP Length" twice in its packet? Isn't it redundant? If it is required for some kind of error checking, please provide an example.
Your observation is correct. The length field is redundant because both the IP header and the UDP header has a length field. My only guess about the reason for this redundancy is, that it happened because UDP was designed at a time, where it was not yet clear what the IP protocol suite would look like.
All legitimate UDP packets should have a length field matching exactly what could be derived from the length field in the IP header. If you don't do that, you can't know for sure, what the receiver is going to do with the packet.
UDP packets with inconsistent length fields are seen in the wild on the Internet. I guess they are probing for buffer overflows, which might happen if one length field is used to allocate memory and the other length field is used when copying data to the allocated buffer.
In the newer UDP Lite protocol, the length field has been repurposed. The length field in the UDP Lite header does not indicate how much data there is in the packet, but rather how much of it has been covered by the checksum. The length of the data in a UDP Lite packet is always computed from the length field in the IP header. This is the only difference between the UDP and UDP Lite header formats.
From RFC 768:
Length is the length in octets of this user datagram including
this header and the data. (This means the minimum value of the
length is eight.)
The pseudo header conceptually prefixed to the UDP header contains
the source address, the destination address, the protocol, and
the UDP length. This information gives protection against misrouted
datagrams. This checksum procedure is the same as is used in TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
The REAL answer is that this is a "pseudo header" - that is, it is used for calculating the checksum, but not actually sent. at least that is what I conclude from What is the Significance of Pseudo Header used in UDP/TCP