Example configuration for creating IPv6 Fragmented packets on VIAVI Testcenter.

Example configuration for creating IPv6 Fragmented packets on VIAVI Testcenter.

IPv6 Fragmentation Example (click here for video, which has both IPv4 and IPv6) 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.  1. 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. FH=0, offset from start of fragmentable payload (This leaves 150 bytes of data remaining for the next fragments.) 2. 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).  Since the 1st fragment used 120 bytes, FH=15, offset from start of payload (120/8) (This would leave 30 bytes of data remaining for the next fragment.) 3. Third Fragment: The last fragment would contain the 100-byte Unfragmentable Part, a Fragment header and the final 30 bytes of data. Since this is the 3rd fragment and thus two previous fragments, 1st fragment used 120 bytes, 2nd fragment used 120 bytes, FH=30, offset from start of payload (240/8) 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. See 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.