Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
IP Message Fragmentation Process
(Page 1 of 4)
When an IP datagram is too large
for the maximum
transmission unit (MTU) of the underlying
data link layer technology used for the next leg of its journey, it
must be fragmented before it can be sent across the network.
The higher-layer message to be transmitted is not sent in a single IP
datagram but rather broken down into pieces called fragments
that are sent separately. In some cases, the fragments themselves may
need to be fragmented further.
Fragmentation Issues and Concerns
Fragmentation is necessary to implement
a network-layer internet that is independent of lower layer details,
but introduces significant complexity to IP. Remember that IP is an
unreliable, connectionless protocol. IP datagrams can take any of several
routes on their way from the source to the destination, and some may
not even make it to the destination at all. When we fragment a message
we make a single datagram into many, which introduces several new issues
to be concerned with:
- Sequencing and Placement: The fragments
will typically be sent in sequential order from the beginning of the
message to the end, but they won't necessarily show up in the order
in which they were sent. The receiving device must be able to determine
the sequence of the fragments to reassemble them in the correct order.
In fact, some implementations send the last fragment first, so the receiving
device will immediately know the full size of the original complete
datagram. This makes keeping track of the order of segments even more
- Separation of Fragmented Messages: A source
device may need to send more than one fragmented message at a time;
or, it may send multiple datagrams that are fragmented en route. This
means the destination may be receiving multiple sets of fragments that
must be put back together. Imagine a box into which the pieces from
two, three or more jigsaw puzzles have been mixed and you understand
- Completion: The destination device has
to be able to tell when it has received all of the fragments so it knows
when to start reassembly (or when to give up if it didn't get all the
To address these concerns and allow
the proper reassembly of the fragmented message, IP includes several
fields in the IP
format header that convey information
from the source to the destination about the fragments. Some of these
contain a common value for all the fragments of the message, while others
are different for each fragment.
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.