In transport mode, the sender inserts the AH header after the IP
   header and before an upper layer protocol header, as described above.
   In tunnel mode, the outer and inner IP header/extensions can be
   inter-related in a variety of ways.  The construction of the outer IP
   header/extensions during the encapsulation process is described in
   the Security Architecture document.

   If there is more than one IPsec header/extension required, the order
   of the application of the security headers MUST be defined by
   security policy.  For simplicity of processing, each IPsec header
   SHOULD ignore the existence (i.e., not zero the contents or try to
   predict the contents) of IPsec headers to be applied later.  (While a
   native IP or bump-in-the-stack implementation could predict the
   contents of later IPsec headers that it applies itself, it won't be
   possible for it to predict any IPsec headers added by a bump-in-the-
   wire implementation between the host and the network.)

3.3.1  Security Association Lookup

   AH is applied to an outbound packet only after an IPsec
   implementation determines that the packet is associated with an SA
   that calls for AH processing.  The process of determining what, if
   any, IPsec processing is applied to outbound traffic is described in
   the Security Architecture document.

3.3.2  Sequence Number Generation

   The sender's counter is initialized to 0 when an SA is established.
   The sender increments the Sequence Number for this SA and inserts the
   new value into the Sequence Number Field.  Thus the first packet sent
   using a given SA will have a Sequence Number of 1.

   If anti-replay is enabled (the default), the sender checks to ensure
   that the counter has not cycled before inserting the new value in the
   Sequence Number field.  In other words, the sender MUST NOT send a
   packet on an SA if doing so would cause the Sequence Number to cycle.
   An attempt to transmit a packet that would result in Sequence Number
   overflow is an auditable event.  (Note that this approach to Sequence
   Number management does not require use of modular arithmetic.)

   The sender assumes anti-replay is enabled as a default, unless
   otherwise notified by the receiver (see 3.4.3).  Thus, if the counter
   has cycled, the sender will set up a new SA and key (unless the SA
   was configured with manual key management).






 
RFC 2402                IP Authentication Header           November 1998


   If anti-replay is disabled, the sender does not need to monitor or
   reset the counter, e.g., in the case of manual key management (see
   Section 5.) However, the sender still increments the counter and when
   it reaches the maximum value, the counter rolls over back to zero.

3.3.3  Integrity Check Value Calculation

   The AH ICV is computed over:
           o IP header fields that are either immutable in transit or
             that are predictable in value upon arrival at the endpoint
             for the AH SA
           o the AH header (Next Header, Payload Len, Reserved, SPI,
             Sequence Number, and the Authentication Data (which is set
             to zero for this computation), and explicit padding bytes
             (if any))
           o the upper level protocol data, which is assumed to be
             immutable in transit

3.3.3.1  Handling Mutable Fields

   If a field may be modified during transit, the value of the field is
   set to zero for purposes of the ICV computation.  If a field is
   mutable, but its value at the (IPsec) receiver is predictable, then
   that value is inserted into the field for purposes of the ICV
   calculation.  The Authentication Data field is also set to zero in
   preparation for this computation.  Note that by replacing each
   field's value with zero, rather than omitting the field, alignment is
   preserved for the ICV calculation.  Also, the zero-fill approach
   ensures that the length of the fields that are so handled cannot be
   changed during transit, even though their contents are not explicitly
   covered by the ICV.

   As a new extension header or IPv4 option is created, it will be
   defined in its own RFC and SHOULD include (in the Security
   Considerations section) directions for how it should be handled when
   calculating the AH ICV.  If the IP (v4 or v6) implementation
   encounters an extension header that it does not recognize, it will
   discard the packet and send an ICMP message.  IPsec will never see
   the packet.  If the IPsec implementation encounters an IPv4 option
   that it does not recognize, it should zero the whole option, using
   the second byte of the option as the length.  IPv6 options (in
   Destination extension headers or Hop by Hop extension header) contain
   a flag indicating mutability, which determines appropriate processing
   for such options.