This 16-bit field is reserved for future use.  It MUST be set to
   "zero." (Note that the value is included in the Authentication Data
   calculation, but is otherwise ignored by the recipient.)

2.4  Security Parameters Index (SPI)

   The SPI is an arbitrary 32-bit value that, in combination with the
   destination IP address and security protocol (AH), uniquely
   identifies the Security Association for this datagram.  The set of
   SPI values in the range 1 through 255 are reserved by the Internet
   Assigned Numbers Authority (IANA) for future use; a reserved SPI
   value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  It is ordinarily selected
   by the destination system upon establishment of an SA (see the
   Security Architecture document for more details).

   The SPI value of zero (0) is reserved for local, implementation-
   specific use and MUST NOT be sent on the wire.  For example, a key
   management implementation MAY use the zero SPI value to mean "No
   Security Association Exists" during the period when the IPsec
   implementation has requested that its key management entity establish
   a new SA, but the SA has not yet been established.




 
RFC 2402                IP Authentication Header           November 1998


2.5  Sequence Number

   This unsigned 32-bit field contains a monotonically increasing
   counter value (sequence number).  It is mandatory and is always
   present even if the receiver does not elect to enable the anti-replay
   service for a specific SA.  Processing of the Sequence Number field
   is at the discretion of the receiver, i.e., the sender MUST always
   transmit this field, but the receiver need not act upon it (see the
   discussion of Sequence Number Verification in the "Inbound Packet
   Processing" section below).

   The sender's counter and the receiver's counter are initialized to 0
   when an SA is established.  (The first packet sent using a given SA
   will have a Sequence Number of 1; see Section 3.3.2 for more details
   on how the Sequence Number is generated.)  If anti-replay is enabled
   (the default), the transmitted Sequence Number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.

2.6  Authentication Data

   This is a variable-length field that contains the Integrity Check
   Value (ICV) for this packet.  The field must be an integral multiple
   of 32 bits in length.  The details of the ICV computation are
   described in Section 3.3.2 below.  This field may include explicit
   padding.  This padding is included to ensure that the length of the
   AH header is an integral multiple of 32 bits (IPv4) or 64 bits
   (IPv6).  All implementations MUST support such padding.  Details of
   how to compute the required padding length are provided below.  The
   authentication algorithm specification MUST specify the length of the
   ICV and the comparison rules and processing steps for validation.

3.  Authentication Header Processing

3.1  Authentication Header Location

   Like ESP, AH may be employed in two ways: transport mode or tunnel
   mode.  The former mode is applicable only to host implementations and
   provides protection for upper layer protocols, in addition to
   selected IP header fields.  (In this mode, note that for "bump-in-
   the-stack" or "bump-in-the-wire" implementations, as defined in the
   Security Architecture document, inbound and outbound IP fragments may
   require an IPsec implementation to perform extra IP
   reassembly/fragmentation in order to both conform to this
   specification and provide transparent IPsec support.  Special care is
   required to perform such operations within these implementations when
   multiple interfaces are in use.)




 
RFC 2402                IP Authentication Header           November 1998


   In transport mode, AH is inserted after the IP header and before an
   upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
   IPsec headers that have already been inserted.  In the context of
   IPv4, this calls for placing AH after the IP header (and any options
   that it contains), but before the upper layer protocol.  (Note that
   the term "transport" mode should not be misconstrued as restricting
   its use to TCP and UDP.  For example, an ICMP message MAY be sent
   using either "transport" mode or "tunnel" mode.)  The following
   diagram illustrates AH transport mode positioning for a typical IPv4
   packet, on a "before and after" basis.

                  BEFORE APPLYING AH
            ----------------------------
      IPv4  |orig IP hdr  |     |      |