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.
IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly
(Page 4 of 4)
IPv6 Fragmentation Example
Let's take an example to illustrate
how IPv6 fragmentation works (see Figure 110).
Suppose we have an IPv6 datagram exactly 370 bytes wide, consisting
of a 40-byte IP header, four 30-byte extension headers, and 210 bytes
of data. Two of the extension headers are unfragmentable, while two
are fragmentable. (In practice we would never need to fragment such
a small datagram but I am trying to keep the numbers simple.) Suppose
we need to send this over a link with an MTU of only 230 bytes. We would
actually require three fragments, not the two you might expect, because
of the need to put the two 30-byte unfragmentable extension headers
in each fragment, and the requirement that each fragment be a length
that is a multiple of 8. Here is how the fragments would be structured:
Figure 110: IPv6 Datagram Fragmentation
In this illustration, a 370-byte IPv6 datagram, containing four 30-byte extension headers, is broken into three fragments. The sizes of the fields are shown to scale. The Unfragmentable Part, shown in blue, begins each fragment, followed by the Fragment header (abbreviated as FH in the figure). Then, portions of the Fragmentable Part are placed into each fragment in sequence. The Authentication and Destination Options extension headers are part of the Fragmentable Part so they appear as part of the first fragment.
- First Fragment: The first fragment
would consist of the 100-byte Unfragmentable Part, followed by
an 8-byte Fragment header and the first 120 bytes of the Fragmentable
Part of the original datagram. This would contain the two fragmentable
extension headers and the first 60 bytes of data. This leaves 150 bytes
of data to send.
- Second Fragment: This would
also contain the 100-byte Unfragmentable Part, followed by a
Fragment header and 120 bytes of data (bytes 60 to 179). This
would leave 30 bytes of data remaining.
- Third Fragment: The last fragment
would contain the 100-byte Unfragmentable Part, a Fragment
header and the final 30 bytes of data.
The M (More Fragments)
flag would be set to one in the first two fragments and zero in the
third, and the Fragment Offset values would be set appropriately.
the topic on IPv4 fragmentation for more on how these fields are used.
The receiving device reassembles
by taking the Unfragmentable Part from the first fragment and
then assembling the Fragment data from each fragment in sequence.
|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.