IP Packet Format

IP Packets Product Documentation contains the main data transmission protocol used in a variety of packet formats, packet example. By IP Packets Product Documentation, be able to enhance understanding of various protocol packets.

IPSec ESP

The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6.

Packet Format

Figure 3-69 ESP Header Format

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data* (variable)                   |
~                                                               ~
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |     Padding (0-255 bytes)                     |
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |  Pad Length   | Next Header   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Integrity Check Value-ICV   (variable)                |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field	Length	Description
Security Parameters Index (SPI)	32 bits	Used by a receiver to identify the SA to which an incoming packet is bound.
Sequence Number	32 bits	Contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number.
Payload Data*	Variable	Payload Data is a variable-length field containing data (from the original IP packet) described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length.
Padding	0–255 bytes	Two primary factors require or motivate use of the Padding field. 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, Padding, Pad Length, and Next Header fields) to the size required by the algorithm. Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figures above, to ensure that the ICV field (if present) is aligned on a 4-byte boundary.
Pad Length	8 bits	Indicates the number of pad bytes immediately preceding it in the Padding field. The range of valid values is 0 to 255, where a value of zero indicates that no Padding bytes are present. As noted above, this does not include any TFC padding bytes.
Next Header	8 bits	Identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP.
Integrity Check Value-ICV	Variable	This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits (IPv4 or IPv6) in length.

Packet Example

Figure 3-70 IPsec Packet

Frame 3: 154 bytes on wire (1232 bits), 154 bytes captured (1232 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Jan  1, 1970 08:00:00.047394000 
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 0.047394000 seconds
    [Time delta from previous captured frame: -0.046496000 seconds]
    [Time delta from previous displayed frame: -0.046496000 seconds]
    [Time since reference or first frame: -0.051482000 seconds]
    Frame Number: 3
    Frame Length: 154 bytes (1232 bits)
    Capture Length: 154 bytes (1232 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:esp]
Ethernet II, Src: 00:00:00_11:00:24 (00:00:00:11:00:24), Dst: HuaweiTe_f7:04:54 (54:89:98:f7:04:54)
    Destination: HuaweiTe_f7:04:54 (54:89:98:f7:04:54)
        Address: HuaweiTe_f7:04:54 (54:89:98:f7:04:54)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 00:00:00_11:00:24 (00:00:00:11:00:24)
        Address: 00:00:00_11:00:24 (00:00:00:11:00:24)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
    Trailer: 9fed06cc
Internet Protocol Version 4, Src: 48.1.1.2, Dst: 49.1.1.2
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 136
    Identification: 0x0006 (6)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 254
    Protocol: Encap Security Payload (50)
    Header Checksum: 0x5938 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 48.1.1.2
    Destination Address: 49.1.1.2
Encapsulating Security Payload
    ESP SPI: 0x6c414f3e (1816219454)
    ESP Sequence: 6

Reference

Standard	Description
RFC 4302	IP Authentication Header
RFC 4303	IP Encapsulating Security Payload (ESP)

Protocol Stack

ESP may be applied alone, in combination with AH , or in a nested fashion.

The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode).

The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header shall contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field.

Figure 3-71 ESP Encapsulation

Transport mode:
             |<------ Authentication Fields -------->|
                      |<---- Encryption Fields ----->|
   +---------+--------+-----------+--------+---------+-------+
   | IP/IPv6 |  ESP   |  TCP/UDP  |  Data  |   ESP   |  ESP  |
   | Header  | Header |   Header  |        |  Tailer |  Auth |
   +---------+--------+-----------+--------+---------+-------+

Tunnel mode:
   |<-------------------- Authentication Fields -------------------->|
                          |<----------- Encryption Fields ---------->|
   +-------------+--------+-----------+-----------+--------+---------+-------+
   | New IP/IPv6 |  ESP   |  IP/IPv6  |  TCP/UDP  |  Data  |   ESP   |  ESP  |
   |    Header   | Header |   Header  |   Header  |        |  Tailer |  Auth |
   +-------------+--------+-----------+-----------+--------+---------+-------+

Figure 3-72 AH and ESP Encapsulation

Transport mode:
   |<-------------------    AH Authentication Fields    ------------------->|
   |                        |<----  ESP Authentication Fields  ---->|       |
   |                                  |<-- ESP Encryption Fields -->|       |
   +---------------+--------+---------+--------------------+----------------+
   |   IP Header   |   AH   |   ESP   |  TCP/UDP  |  Data  |   ESP  |  ESP  |
   | (protocol=51) | Header |  Header |   Header  |        | Tailer |  Auth |
   +---------------+--------+---------+--------------------+----------------+

Tunnel mode:
   |<----------------------    AH Authentication Fields    --------------------->|
   |                        |<------  ESP Authentication Fields  ------->|       |
   |                                  |<---- ESP Encryption Fields ----->|       |
   +---------------+--------+---------+--------+---------+------+--------+-------+
   | New IP Header |   AH   |   ESP   |   IP   | TCP/UDP | Data |   ESP  |  ESP  |
   | (protocol=51) | Header |  Header | Header |  Header |      | Tailer |  Auth |
   +---------------+--------+---------+--------+---------+------+--------+-------+

For information about AH Encapsulation, see IPSec AH or RFC 4302.

Translation

Favorite

Download

Update Date：2025-08-12

Document ID：EDOC1100174721

Downloads：1056

Average rating：3.0Points

Digital Signature File

digtal sigature tool

IP Packet Format

IP Packets Product Documentation contains the main data transmission protocol used in a variety of packet formats, packet example. By IP Packets Product Documentation, be able to enhance understanding of various protocol packets.

IP Packets Product Documentation contains the main data transmission protocol used in a variety of packet formats, packet example. By IP Packets Product Documentation, be able to enhance understanding of various protocol packets.

IPSec ESP

Packet Format

Packet Example

Reference

Protocol Stack

Related Documents

Digital Signature File

Share