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.
Related
An IP packet with no options, broken into 3 fragments.
Fragment 1 - offset of 0
Fragment 2 - offset of 358
Fragment 3 - offset of 510 and a total length of 120
How can I calculate how long the original IP packet was?
I think you have some invalid numbers for fragment offsets since IP must be fragmented on 64-bit boundaries.
When in doubt, refer to the RFC (RFC 791, INTERNET PROTOCOL):
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.
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.
I am currently going through my networking slides and was wondering if someone could help me with the concept of fragmentation and reassembly.
I understand how it works, namely how datagrams are split into smaller chunks because network links have a MTU. However the example in the picture is confusing me.
So the first two sections show a length of 1500, because this is the MSU, but shouldn't this mean that the last one should have 1000 (for a total of 4000 bytes) and not 1040? Where did these extra 40 bytes come from? My guess is that because the previous two fragments both had a header of 20 bytes, this extra 40 bytes of data needed to go somewhere, so it will arrive in the last fragment?
Fragflag essentially means that there is another fragment, so all of them will have a Fragflag of 1 except the last fragment which will be at zero. However I don't understand what offset is or how it is calculated. Why is the first offset at zero? Why did we divide the bytes in the datafield (1480) by 8 to get the second offset? Where did this 8 come from? Aside from that, I am assuming that each fragments offset will just increase by this value?
For example, the first fragment will have a offset of 0, the second 185, the third 370 and the fourth 555? (370+185)
Thanks for any help!
There is a 20 byte header in each packet. So the original packet contains 3,980 bytes of data. The fragments contain 1480, 1480, and 1020 bytes of data. 1480 + 1480 + 1020 = 3980
Every bit in the header is precious. Dividing the offset by 8 allows it to fit in 13 bits instead of 16. This means every packet but the last must contain a number of data bytes that is a multiple of 8, which isn't a problem.
The fragmentation and Reassembly has been exclusively explained in the RFC 791. Do go through the Internet Protocol Specification RFC. The RFC has various sections explaining the sample fragmentation and reassembly. All your doubts and questions are well catered in it.
Ans 1: Regarding the lengths of the packet: The original Packet contains 4000 Bytes. This packet is a fully IP packet and hence contains the IP header as well . Thus the payload length is actually 4000 - ( IP Header Length i. e. 20 ).
Actual Payload Length = 4000 - 20 = 3980
Now the packet is fragmented owing to the fact that the length is greater than the MTU ( 1500 Bytes).
Thus the 1st packet contains 1500 Bytes which includes IP header + Payload Fraction.
1500 = 20 ( IP header ) + 1480 ( Data Payload )
Similarly for the other packet.
The third packet shall contain remaining left over data ( 3980 - 1480 -1480 ) = 1020
Thus length of the packet is 20 ( IP Header ) + 1020 ( payload ) = 1040
Ans 2: The offset is the address or the locator from where the data starts with reference to the original data payload. For IP the data payload comprises all the data thats after the IP header and Options header. Thus the system/router takes the payload and divides it into smaller parts and keeps the track of the offset with reference to the original packet so that reassembly can be done.
As given in the RFC Page 12.
"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 fragment offset is measured in Units of 8 bytes each. It has 13 bit field in the IP header. As said in the RFC page 17
"This field indicates where in the datagram this fragment belongs.The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero."
Thus as you asked in the question where did this 8 come from, its the standard thats been defined for IP protocol specification, where 8 octets are taken as one value. This also helps us to transmit large packets via this.
Page 28 of the RFC writes:
*Fragments are counted in units of 8 octets. The fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information (MF = 0, fragment offset =
0). If an internet datagram is fragmented, its data portion must be
broken on 8 octet boundaries. This format allows 2**13 = 8192 fragments of 8 octets each for a
total of 65,536 octets. Note that this is consistent with the the
datagram total length field (of course, the header is counted in the
total length and not in the fragments).*
the offset size is 13 bits in the IP header but we need 16 bits as in worst case. So we use a scaling factor of 8 i.e. (2^16/2^13).
those are not extra bits but the total length of last fragment.
as 1500 is MTU this means there can be 1500 byte of data in one fragment including header. Header is appended with every fragment. this means in fragment we are capable of sending 1500-20 =1480 byte of data.
it is given there is 4000B datagram .datagram is nothing but a packet encapsulation of data at network layer.so the total data we have to send is 4000-20=3980 . then it is fragmented into 3parts (ceil(3980/1480)) each of length 1480,1480,1020 respectively . hence when 20B header is appended to last fragment its length becomes 1020+20=1040 .
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
Suppose I have two hosts, host A and host B, and host A sends a 1500 byte packet to B and there are two routers between them with a MTU of 800 bytes for the first link, and MTU of 500 bytes for the second link between them.
As I understand it the packet will have to be fragmented both times. The packet will have to be fragmented into 3 packets (2 equally sized packets and one smaller one).
Then when we hit this second router we will have each of the first two fragmented packets be fragmented once more. The first two original fragments will produce 1 larger fragment (close to 500 bytes), and one smaller one.
This is where I am confused.
I know that the 'More Fragment' bit should be set to 1 on all of the first 3 fragments except the last indicating that the packets are part of a fragment up to and including the next packet with 'More Fragment' set to 0. However, for the second set of fragments I am not so sure. If this was the first time the packet had been fragmented, the last fragment would have 'More Fragment' of 0, but since this is actually just a fragment somewhere in the middle of the original message, I have a feeling it should be 1.
I am hoping someone with more experience can shed some light on this for me. Is the 'More Fragment' bit used in reassembly? If so I would imagine that when the fragments are fragmented then we do not set the last fragment to 0.
So the algorithm would go:
If fragmenting a packet with 'More Fragment' set to 0,
then set 'More Fragment' to 1 in all fragmented packets except the last.
Else If fragmenting a packet with 'More Fragment' set to 1,
then set 'More Fragment' to 1 in all of the fragmented packets.
Is my assumption here correct?
You are more or less right. Routers besides adding MF (more fragments) flag are doing some more processing:
To fragment/segment a long internet packet, a router (R1 in the figure
below) creates a new IP packet and copies the contents of the IP
header fields from the long packet into the new IP header. The data of
the long packet is then divided into two portions on a 8 byte (64 bit)
boundary, so that the first packet is less than the MTU of the
out-going interface. The more-fragments flag (MF) in the first packet
is set to one (to indicate that more fragments of this packet follow).
The More Flag may already be set in this packet if it has already been
fragmented by another system. This packet is forwarded.
The second created new packet is then processed. The packet header
field is identical to that of the original packet (including the same
value of the packet ID, the total length field, the more-fragments
flag (MF) and the fragment offset field in the original packet). The
packet header field is updated with a new offset field, by adding the
number of payload bytes sent in the first fragment. If this new packet
is larger than the allowed link MTU, the packet is again fragmented.
So in nutshell for already fragmented packets whole IP header is being copied to new packets (smaller fragments of fragment). It means that if IP packet has MF set it will be also copied to last fragmented packet. Thanks to changing offset and packets ID host receiving fragmented packets will be able to reassemble those.