Security Payload (ESP) [KA97b], or in a nested fashion through the
   use of tunnel mode (see "Security Architecture for the Internet
   Protocol" [KA97a], hereafter referred to as the Security Architecture
   document).  Security services can be provided between a pair of
   communicating hosts, between a pair of communicating security
   gateways, or between a security gateway and a host.  ESP may be used
   to provide the same security services, and it also provides a
   confidentiality (encryption) service.  The primary difference between
   the authentication provided by ESP and AH is the extent of the
   coverage.  Specifically, ESP does not protect any IP header fields




 
RFC 2402                IP Authentication Header           November 1998


   unless those fields are encapsulated by ESP (tunnel mode).  For more
   details on how to use AH and ESP in various network environments, see
   the Security Architecture document [KA97a].

   It is assumed that the reader is familiar with the terms and concepts
   described in the Security Architecture document.  In particular, the
   reader should be familiar with the definitions of security services
   offered by AH and ESP, the concept of Security Associations, the ways
   in which AH can be used in conjunction with ESP, and the different
   key management options available for AH and ESP.  (With regard to the
   last topic, the current key management options required for both AH
   and ESP are manual keying and automated keying via IKE [HC98].)

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [Bra97].

2.  Authentication Header Format

   The protocol header (IPv4, IPv6, or Extension) immediately preceding
   the AH header will contain the value 51 in its Protocol (IPv4) or
   Next Header (IPv6, Extension) field [STD-2].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header   |  Payload Len  |          RESERVED             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Security Parameters Index (SPI)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sequence Number Field                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                Authentication Data (variable)                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following subsections define the fields that comprise the AH
   format.  All the fields described here are mandatory, i.e., they are
   always present in the AH format and are included in the Integrity
   Check Value (ICV) computation (see Sections 2.6 and 3.3.3).











 
RFC 2402                IP Authentication Header           November 1998


2.1  Next Header

   The Next Header is an 8-bit field that identifies the type of the
   next payload after the Authentication Header.  The value of this
   field is chosen from the set of IP Protocol Numbers defined in the
   most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
   Numbers Authority (IANA).

2.2  Payload Length

   This 8-bit field specifies the length of AH in 32-bit words (4-byte
   units), minus "2".  (All IPv6 extension headers, as per RFC 1883,
   encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word)
   from the header length (measured in 64-bit words).  AH is an IPv6
   extension header.  However, since its length is measured in 32-bit
   words, the "Payload Length" is calculated by subtracting 2 (32 bit
   words).)  In the "standard" case of a 96-bit authentication value
   plus the 3 32-bit word fixed portion, this length field will be "4".
   A "null" authentication algorithm may be used only for debugging
   purposes.  Its use would result in a "1" value for this field for
   IPv4 or a "2" for IPv6, as there would be no corresponding
   Authentication Data field (see Section 3.3.3.2.1 on "Authentication
   Data Padding").

2.3  Reserved