3.1.1. Transport Mode

In transport mode, AH is inserted after the IP header and before a next 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 next layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 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  |     |      |
         |(any options)| TCP | Data |
         ----------------------------

               AFTER APPLYING AH
         -------------------------------------------------------
   IPv4  |original IP hdr (any options) | AH | TCP |    Data   |
         -------------------------------------------------------
         |<- mutable field processing ->|<- immutable fields ->|
         |<----- 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 before or after or both before and 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 |
        ------------------------------------------------------------
        |<--- mutable field processing -->|<-- immutable fields -->|
        |<---- authenticated except for mutable fields ----------->|

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

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.

Note that in transport mode, 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.