The SPI value of zero (0) is reserved for local, implementation-
   specific use and MUST NOT be sent on the wire.  For example, a key
   management implementation MAY use the zero SPI value to mean "No
   Security Association Exists" during the period when the IPsec
   implementation has requested that its key management entity establish
   a new SA, but the SA has not yet been established.

2.2  Sequence Number

   This unsigned 32-bit field contains a monotonically increasing
   counter value (sequence number).  It is mandatory and is always
   present even if the receiver does not elect to enable the anti-replay
   service for a specific SA.  Processing of the Sequence Number field
   is at the discretion of the receiver, i.e., the sender MUST always
   transmit this field, but the receiver need not act upon it (see the
   discussion of Sequence Number Verification in the "Inbound Packet
   Processing" section below).

   The sender's counter and the receiver's counter are initialized to 0
   when an SA is established. (The first packet sent using a given SA
   will have a Sequence Number of 1; see Section 3.3.3 for more details
   on how the Sequence Number is generated.)  If anti-replay is enabled




 
RFC 2406           IP Encapsulating Security Payload       November 1998


   (the default), the transmitted Sequence Number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.

2.3  Payload Data

   Payload Data is a variable-length field containing data described by
   the Next Header field. The Payload Data field is mandatory and is an
   integral number of bytes in length.  If the algorithm used to encrypt
   the payload requires cryptographic synchronization data, e.g., an
   Initialization Vector (IV), then this data MAY be carried explicitly
   in the Payload field.  Any encryption algorithm that requires such
   explicit, per-packet synchronization data MUST indicate the length,
   any structure for such data, and the location of this data as part of
   an RFC specifying how the algorithm is used with ESP. If such
   synchronization data is implicit, the algorithm for deriving the data
   MUST be part of the RFC.

   Note that with regard to ensuring the alignment of the (real)
   ciphertext in the presence of an IV:

           o For some IV-based modes of operation, the receiver treats
             the IV as the start of the ciphertext, feeding it into the
             algorithm directly.  In these modes, alignment of the start
             of the (real) ciphertext is not an issue at the receiver.
           o In some cases, the receiver reads the IV in separately from
             the ciphertext.  In these cases, the algorithm
             specification MUST address how alignment of the (real)
             ciphertext is to be achieved.

2.4  Padding (for Encryption)

   Several factors require or motivate use of the Padding field.

           o If an encryption algorithm is employed that requires the
             plaintext to be a multiple of some number of bytes, e.g.,
             the block size of a block cipher, the Padding field is used
             to fill the plaintext (consisting of the Payload Data, Pad
             Length and Next Header fields, as well as the Padding) to
             the size required by the algorithm.

           o Padding also may be required, irrespective of encryption
             algorithm requirements, to ensure that the resulting
             ciphertext terminates on a 4-byte boundary. Specifically,







 
RFC 2406           IP Encapsulating Security Payload       November 1998


             the Pad Length and Next Header fields must be right aligned
             within a 4-byte word, as illustrated in the ESP packet
             format figure above, to ensure that the Authentication Data
             field (if present) is aligned on a 4-byte boundary.

           o Padding beyond that required for the algorithm or alignment
             reasons cited above, may be used to conceal the actual
             length of the payload, in support of (partial) traffic flow
             confidentiality.  However, inclusion of such additional
             padding has adverse bandwidth implications and thus its use
             should be undertaken with care.

   The sender MAY add 0-255 bytes of padding.  Inclusion of the Padding
   field in an ESP packet is optional, but all implementations MUST