(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 ESP transport mode positioning for a
   typical IPv4 packet, on a "before and after" basis. (The "ESP
   trailer" encompasses any Padding, plus the Pad Length, and Next
   Header fields.)

                 BEFORE APPLYING ESP
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

                 AFTER APPLYING ESP
            -------------------------------------------------
      IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
            |(any options)| Hdr | TCP | Data | Trailer |Auth|
            -------------------------------------------------
                                |<----- encrypted ---->|
                          |<------ authenticated ----->|


   In the IPv6 context, ESP 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 ESP header depending on the semantics
   desired.  However, since ESP protects only fields after the ESP
   header, it generally may be desirable to place the destination
   options header(s) after the ESP header.  The following diagram
   illustrates ESP transport mode positioning for a typical IPv6 packet.

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













 
RFC 2406           IP Encapsulating Security Payload       November 1998


                     AFTER APPLYING ESP
            ---------------------------------------------------------
      IPv6  | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
            |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
            ---------------------------------------------------------
                                         |<---- encrypted ---->|
                                     |<---- authenticated ---->|

                * = if present, could be before ESP, after ESP, 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.

   Tunnel mode ESP may be employed in either hosts or security gateways.
   When ESP is implemented in a security gateway (to protect subscriber
   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, ESP
   protects the entire inner IP packet, including the entire inner IP
   header. The position of ESP in tunnel mode, relative to the outer IP
   header, is the same as for ESP in transport mode.  The following
   diagram illustrates ESP tunnel mode positioning for typical IPv4 and
   IPv6 packets.

            -----------------------------------------------------------
      IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
            |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
            -----------------------------------------------------------
                                |<--------- encrypted ---------->|
                          |<----------- authenticated ---------->|

            ------------------------------------------------------------
      IPv6  | new* |new ext |   | orig*|orig ext |   |    | ESP   | ESP|
            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer|Auth|
            ------------------------------------------------------------
                                |<--------- encrypted ----------->|
                            |<---------- authenticated ---------->|

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