in the packet, for any option whose data may change en-route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.



 
RFC 1883                   IPv6 Specification              December 1995


      0 - Option Data does not change en-route

      1 - Option Data may change en-route

   Individual options may have specific alignment requirements, to
   ensure that multi-octet values within Option Data fields fall on
   natural boundaries.  The alignment requirement of an option is
   specified using the notation xn+y, meaning the Option Type must
   appear at an integer multiple of x octets from the start of the
   header, plus y octets.  For example:

       2n    means any 2-octet offset from the start of the header.
       8n+2  means any 8-octet offset from the start of the header,
             plus 2 octets.

   There are two padding options which are used when necessary to align
   subsequent options and to pad out the containing header to a multiple
   of 8 octets in length.  These padding options must be recognized by
   all IPv6 implementations:


   Pad1 option  (alignment requirement: none)

       +-+-+-+-+-+-+-+-+
       |       0       |
       +-+-+-+-+-+-+-+-+

       NOTE! the format of the Pad1 option is a special case -- it does
             not have length and value fields.

       The Pad1 option is used to insert one octet of padding into the
       Options area of a header.  If more than one octet of padding is
       required, the PadN option, described next, should be used,
       rather than multiple Pad1 options.


   PadN option  (alignment requirement: none)

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
       |       1       |  Opt Data Len |  Option Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

       The PadN option is used to insert two or more octets of padding
       into the Options area of a header.  For N octets of padding,
       the Opt Data Len field contains the value N-2, and the Option
       Data consists of N-2 zero-valued octets.


   Appendix A contains formatting guidelines for designing new options.



 
RFC 1883                   IPv6 Specification              December 1995


4.3  Hop-by-Hop Options Header

   The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.
   The Hop-by-Hop Options header is identified by a Next Header value of
   0 in the IPv6 header, and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Hdr Ext Len  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   .                                                               .
   .                            Options                            .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header          8-bit selector.  Identifies the type of header
                        immediately following the Hop-by-Hop Options
                        header.  Uses the same values as the IPv4
                        Protocol field [RFC-1700 et seq.].

   Hdr Ext Len          8-bit unsigned integer.  Length of the
                        Hop-by-Hop Options header in 8-octet units,
                        not including the first 8 octets.

   Options              Variable-length field, of length such that the
                        complete Hop-by-Hop Options header is an integer
                        multiple of 8 octets long.  Contains one or
                        more TLV-encoded options, as described in
                        section 4.2.

   In addition to the Pad1 and PadN options specified in section 4.2,
   the following hop-by-hop option is defined: