|(any options)| TCP | Data |
            ----------------------------

                  AFTER APPLYING AH
            ---------------------------------
      IPv4  |orig IP hdr  |    |     |      |
            |(any options)| AH | TCP | Data |
            ---------------------------------
            |<------- authenticated ------->|
                 except for mutable fields

   In the IPv6 context, AH is viewed as an end-to-end payload, and thus
   should appear after hop-by-hop, routing, and fragmentation extension
   headers.  The destination options extension header(s) could appear
   either before or after the AH header depending on the semantics
   desired.  The following diagram illustrates AH transport mode
   positioning for a typical IPv6 packet.

                       BEFORE APPLYING AH
            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                      AFTER APPLYING AH
            ------------------------------------------------------------
      IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
            |orig IP hdr  |routing, fragment. | AH | opt* | TCP | Data |
            ------------------------------------------------------------
            |<---- authenticated except for mutable fields ----------->|

                 * = if present, could be before AH, after AH, or both






 
RFC 2402                IP Authentication Header           November 1998


   ESP and AH headers can be combined in a variety of modes.  The IPsec
   Architecture document describes the combinations of security
   associations that must be supported.

   Tunnel mode AH may be employed in either hosts or security gateways
   (or in so-called "bump-in-the-stack" or "bump-in-the-wire"
   implementations, as defined in the Security Architecture document).
   When AH is implemented in a security gateway (to protect transit
   traffic), tunnel mode must be used.  In tunnel mode, the "inner" IP
   header carries the ultimate source and destination addresses, while
   an "outer" IP header may contain distinct IP addresses, e.g.,
   addresses of security gateways.  In tunnel mode, AH protects the
   entire inner IP packet, including the entire inner IP header. The
   position of AH in tunnel mode, relative to the outer IP header, is
   the same as for AH in transport mode.  The following diagram
   illustrates AH tunnel mode positioning for typical IPv4 and IPv6
   packets.

          ------------------------------------------------
    IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
          |(any options)| AH | (any options) |TCP | Data |
          ------------------------------------------------
          |<- authenticated except for mutable fields -->|
          |           in the new IP hdr                  |

          --------------------------------------------------------------
    IPv6  |           | ext hdrs*|    |            | ext hdrs*|   |    |
          |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
          --------------------------------------------------------------
          |<-- authenticated except for mutable fields in new IP hdr ->|

           * = construction of outer IP hdr/extensions and modification
               of inner IP hdr/extensions is discussed below.

3.2  Authentication Algorithms

   The authentication algorithm employed for the ICV computation is
   specified by the SA.  For point-to-point communication, suitable
   authentication algorithms include keyed Message Authentication Codes
   (MACs) based on symmetric encryption algorithms (e.g., DES) or on
   one-way hash functions (e.g., MD5 or SHA-1).  For multicast
   communication, one-way hash algorithms combined with asymmetric
   signature algorithms are appropriate, though performance and space
   considerations currently preclude use of such algorithms.  The
   mandatory-to-implement authentication algorithms are described in
   Section 5 "Conformance Requirements".  Other algorithms MAY be
   supported.





 
RFC 2402                IP Authentication Header           November 1998


3.3  Outbound Packet Processing