contain a bit that indicates whether the option might change
   (unpredictably) during transit.  For any option for which contents
   may change en-route, the entire "Option Data" field must be treated
   as zero-valued octets when computing or verifying the ICV.  The
   Option Type and Opt Data Len are included in the ICV calculation.
   All options for which the bit indicates immutability are included in
   the ICV calculation.  See the IPv6 specification [DH95] for more
   information.

3.3.3.1.2.3  Extension Headers Not Containing Options

   The IPv6 extension headers that do not contain options are explicitly
   listed in Appendix A and classified as immutable, mutable but
   predictable, or mutable.




 
RFC 2402                IP Authentication Header           November 1998


3.3.3.2  Padding

3.3.3.2.1  Authentication Data Padding

   As mentioned in section 2.6, the Authentication Data field explicitly
   includes padding to ensure that the AH header is a multiple of 32
   bits (IPv4) or 64 bits (IPv6).  If padding is required, its length is
   determined by two factors:

             - the length of the ICV
             - the IP protocol version (v4 or v6)

   For example, if the output of the selected algorithm is 96-bits, no
   padding is required for either IPv4 or for IPv6.  However, if a
   different length ICV is generated, due to use of a different
   algorithm, then padding may be required depending on the length and
   IP protocol version.  The content of the padding field is arbitrarily
   selected by the sender.  (The padding is arbitrary, but need not be
   random to achieve security.)  These padding bytes are included in the
   Authentication Data calculation, counted as part of the Payload
   Length, and transmitted at the end of the Authentication Data field
   to enable the receiver to perform the ICV calculation.

3.3.3.2.2  Implicit Packet Padding

   For some authentication algorithms, the byte string over which the
   ICV computation is performed must be a multiple of a blocksize
   specified by the algorithm.  If the IP packet length (including AH)
   does not match the blocksize requirements for the algorithm, implicit
   padding MUST be appended to the end of the packet, prior to ICV
   computation.  The padding octets MUST have a value of zero.  The
   blocksize (and hence the length of the padding) is specified by the
   algorithm specification.  This padding is not transmitted with the
   packet.  Note that MD5 and SHA-1 are viewed as having a 1-byte
   blocksize because of their internal padding conventions.

3.3.4  Fragmentation

   If required, IP fragmentation occurs after AH processing within an
   IPsec implementation.  Thus, transport mode AH is applied only to
   whole IP datagrams (not to IP fragments).  An IP packet to which AH
   has been applied may itself be fragmented by routers en route, and
   such fragments must be reassembled prior to AH processing at a
   receiver.  In tunnel mode, AH is applied to an IP packet, the payload
   of which may be a fragmented IP packet.  For example, a security
   gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
   implementation (see the Security Architecture document for details)
   may apply tunnel mode AH to such fragments.




 
RFC 2402                IP Authentication Header           November 1998


3.4  Inbound Packet Processing

   If there is more than one IPsec header/extension present, the
   processing for each one ignores (does not zero, does not use) any
   IPsec headers applied subsequent to the header being processed.

3.4.1  Reassembly

   If required, reassembly is performed prior to AH processing.  If a
   packet offered to AH for processing appears to be an IP fragment,
   i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
   the receiver MUST discard the packet; this is an auditable event. The
   audit log entry for this event SHOULD include the SPI value,
   date/time, Source Address, Destination Address, and (in IPv6) the
   Flow ID.

   NOTE: For packet reassembly, the current IPv4 spec does NOT require
   either the zero'ing of the OFFSET field or the clearing of the MORE
   FRAGMENTS flag.  In order for a reassembled packet to be processed by
   IPsec (as opposed to discarded as an apparent fragment), the IP code
   must do these two things after it reassembles a packet.