each router along a packet's path will "process" the packet and
   consequently might change the packet.  This would happen on a hop by
   hop basis as the packet goes from router to router.  Prior to being
   processed by the application to which the option contents are
   directed, e.g., RSVP/IGMP, the packet should encounter AH processing.





 
RFC 2402                IP Authentication Header           November 1998


   However, AH processing would require that each router along the path
   is a member of a multicast-SA defined by the SPI.  This might pose
   problems for packets that are not strictly source routed, and it
   requires multicast support techniques not currently available.

   NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by
   systems along a packet's path conflicts with the classification of
   these IP Options as immutable and is incompatible with the use of
   IPsec.

   NOTE: End of Options List options SHOULD be repeated as necessary to
   ensure that the IP header ends on a 4 byte boundary in order to
   ensure that there are no unspecified bytes which could be used for a
   covert channel.

A2.  IPv6 Extension Headers

   This table shows how the IPv6 Extension Headers are classified with
   regard to "mutability".

Option/Extension Name                  Reference
-----------------------------------    ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
  Routing (Type 0)                    [RFC1883]

BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
  Hop by Hop options                  [RFC1883]
  Destination options                 [RFC1883]

NOT APPLICABLE
  Fragmentation                       [RFC1883]

      Options -- IPv6 options in the Hop-by-Hop and Destination
             Extension Headers contain a bit that indicates whether the
             option might change (unpredictably) during transit.  For
             any option for which contents may change en-route, the
             entire "Option Data" field must be treated as zero-valued
             octets when computing or verifying the ICV.  The Option
             Type and Opt Data Len are included in the ICV calculation.
             All options for which the bit indicates immutability are
             included in the ICV calculation.  See the IPv6
             specification [DH95] for more information.

      Routing (Type 0) -- The IPv6 Routing Header "Type 0" will
             rearrange the address fields within the packet during
             transit from source to destination.  However, the contents
             of the packet as it will appear at the receiver are known
             to the sender and to all intermediate hops.  Hence, the




 
RFC 2402                IP Authentication Header           November 1998


             IPv6 Routing Header "Type 0" is included in the
             Authentication Data calculation as mutable but predictable.
             The sender must order the field so that it appears as it
             will at the receiver, prior to performing the ICV
             computation.

      Fragmentation -- Fragmentation occurs after outbound IPsec
             processing (section 3.3) and reassembly occurs before
             inbound IPsec processing (section 3.4).  So the
             Fragmentation Extension Header, if it exists, is not seen
             by IPsec.

             Note that on the receive side, the IP implementation could
             leave a Fragmentation Extension Header in place when it
             does re-assembly.  If this happens, then when AH receives
             the packet, before doing ICV processing, AH MUST "remove"
             (or skip over) this header and change the previous header's
             "Next Header" field to be the "Next Header" field in the
             Fragmentation Extension Header.

             Note that on the send side, the IP implementation could
             give the IPsec code a packet with a Fragmentation Extension
             Header with Offset of 0 (first fragment) and a More
             Fragments Flag of 0 (last fragment).  If this happens, then
             before doing ICV processing, AH MUST first "remove" (or
             skip over) this header and change the previous header's
             "Next Header" field to be the "Next Header" field in the
             Fragmentation Extension Header.

References