IPv6の仕様（IPv6拡張ヘッダ）

   In IPv6, optional internet-layer information is encoded in separate
   headers that may be placed between the IPv6 header and the upper-
   layer header in a packet.  There are a small number of such extension
   headers, each identified by a distinct Next Header value.  As
   illustrated in these examples, an IPv6 packet may carry zero, one, or
   more extension headers, each identified by the Next Header field of
   the preceding header:

   +---------------+------------------------
   |  IPv6 header  | TCP header + data
   |               |
   | Next Header = |
   |      TCP      |
   +---------------+------------------------


   +---------------+----------------+------------------------
   |  IPv6 header  | Routing header | TCP header + data
   |               |                |
   | Next Header = |  Next Header = |
   |    Routing    |      TCP       |
   +---------------+----------------+------------------------


   +---------------+----------------+-----------------+-----------------
   |  IPv6 header  | Routing header | Fragment header | fragment of TCP
   |               |                |                 |  header + data
   | Next Header = |  Next Header = |  Next Header =  |
   |    Routing    |    Fragment    |       TCP       |
   +---------------+----------------+-----------------+-----------------

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.
   There, normal demultiplexing on the Next Header field of the IPv6
   header invokes the module to process the first extension header, or
   the upper-layer header if no extension header is present.  The
   contents and semantics of each extension header determine whether or
   not to proceed to the next header.  Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header.

   If, as a result of processing a header, a node is required to proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, it should discard the packet and send an
   ICMP Parameter Problem message to the source of the packet, with an
   ICMP Code value of 2 ("unrecognized Next Header type encountered")
   and the ICMP Pointer field containing the offset of the unrecognized
   value within the original packet.  The same action should be taken if
   a node encounters a Next Header value of zero in any header other
   than an IPv6 header.

   Each extension header is an integer multiple of 8 octets long, in
   order to retain 8-octet alignment for subsequent headers.  Multi-
   octet fields within each extension header are aligned on their
   natural boundaries, i.e., fields of width n octets are placed at an
   integer multiple of n octets from the start of the header, for n = 1,
   2, 4, or 8.

   A full implementation of IPv6 includes implementation of the
   following extension headers:

           Hop-by-Hop Options
           Routing (Type 0)
           Fragment
           Destination Options
           Authentication
           Encapsulating Security Payload

   The first four are specified in this document; the last two are
   specified in [RFC-1826] and [RFC-1827], respectively.