fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Unfragmentable
         Part is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Payload Length of the reassembled packet is computed from
         the length of the Unfragmentable Part and the length and offset
         of the last fragment.  For example, a formula for computing the
         Payload Length of the reassembled original packet is:

           PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

           where
           PL.orig  = Payload Length field of reassembled packet.
           PL.first = Payload Length field of first fragment packet.
           FL.first = length of fragment following Fragment header of
                      first fragment packet.
           FO.last  = Fragment Offset field of Fragment header of
                      last fragment packet.
           FL.last  = length of fragment following Fragment header of
                      last fragment packet.

      The Fragmentable Part of the reassembled packet is constructed
      from the fragments following the Fragment headers in each of the
      fragment packets.  The length of each fragment is computed by
      subtracting from the packet's Payload Length the length of the
      headers between the IPv6 header and fragment itself; its relative
      position in Fragmentable Part is computed from its Fragment Offset
      value.



 
RFC 1883                   IPv6 Specification              December 1995


      The Fragment header is not present in the final, reassembled
      packet.

   The following error conditions may arise when reassembling fragmented
   packets:

      If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment.

      If the length of a fragment, as derived from the fragment packet's
      Payload Length field, is not a multiple of 8 octets and the M flag
      of that fragment is 1, then that fragment must be discarded and an
      ICMP Parameter Problem, Code 0, message should be sent to the
      source of the fragment, pointing to the Payload Length field of
      the fragment packet.

      If the length and offset of a fragment are such that the Payload
      Length of the packet reassembled from that fragment would exceed
      65,535 octets, then that fragment must be discarded and an ICMP
      Parameter Problem, Code 0, message should be sent to the source of
      the fragment, pointing to the Fragment Offset field of the
      fragment packet.

   The following conditions are not expected to occur, but are not
   considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.









 
RFC 1883                   IPv6 Specification              December 1995


4.6  Destination Options Header

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s).  The
   Destination Options header is identified by a Next Header value of 60
   in the immediately preceding header, and has the following format: