认证头的载荷长度只描述认证头自己：整段头有多少个 32 位字，再减去 2。完整性校验值为 96 位时，这个字段是 4。紧前面那个头取值 51。规范是 2005 年 12 月的 RFC 4302。它不按别的 IPv6 扩展头所用的 64 位字来计量。
字段里写的是字数减 2
一个可独立引用的定义句：认证头的载荷长度是 8 位。它表示整段认证头有多少个 32 位字（4 字节），再减去 2。完整性算法给出 96 位认证值时，这个字段是 4：固定部分 3 个 32 位字，加上 ICV 的 3 个 32 位字，再减去 2（RFC 4302 第 2.2 节）。
固定部分按第 2 节的字节表是：下一个头 1 字节、载荷长度 1 字节、保留 2 字节、SPI 4 字节、序列号低 32 位 4 字节，合计 12 字节，也就是那 3 个字。96 位是 12 字节，再是 3 个字。6 个字乘 4 是 24 字节。原文没有把 12 和 24 印出来。24 能被 8 整除。第 2.2 节接着用小写 must 要求：IPv6 上整段头是 8 个八位组的整数倍。关键词清单列的是大写形式。本文不把这句小写 must 升成大写必须。
同一节的括注写明：IPv6 把认证头算作扩展头，但它的长度按 32 位字计量，不是别的 IPv6 扩展头所用的 64 位字。若把 24 字节误代进「不含前 8 个八位组、以 8 字节为单位」的算法，得到的是 2，不是 4。那套定义在 RFC 8200 第 4.3 节，不在认证头的这个字段里。两套不要相加，也不要互换。
| 字段 | 第 2 节表里的字节 | 是否进入 ICV | 表里的 Xmtd |
|---|---|---|---|
| 下一个头、载荷长度、保留、SPI、序列号低 32 位 | 1、1、2、4、4 | 进入 | plain，明文发出 |
| ICV | 可变。第 2.6 节用小写 must 要求它是 32 位的整数倍 | 计算前先当作 0，结果再填回 | plain |
| 被保护的 IP 数据报 | 可变 | 进入 | plain。隧道模式是整份内层数据报；传输模式是下一个头和数据 |
| 序列号高 32 位 | 4，仅在使用 ESN 时 | 进入 | not xmtd，不发出 |
| 表中的 ICV Padding | 需要时可变 | 进入 | not xmtd |
这一列的原文是 plain 或 not xmtd。plain 表示明文发出。认证头这张表里没有密文一格。最后一行和正文并不同一句。第 2.6 节与第 3.3.3.2.1 节写的是：为了让认证头成为 32 位（IPv4）或 64 位（IPv6）的整数倍，ICV 字段可以带显式填充。这些字节进入 ICV 计算，算进载荷长度，并附在 ICV 末尾发出。96 位时，IPv4 和 IPv6 都不需要这种填充。内容由发送方选择，原文写明不必为了安全做成随机数。超过最小对齐量时，原文用 prohibited，不是大写 MUST NOT。第 2 节总表却把名为 ICV Padding 的一行标成不发出。
第 3.3.3.2.2 节还有一份隐式填充：某些算法要求被计算的字节串是块长的整数倍。不够时在包尾补 0，只参与计算，不随包发出。高 32 位序列号若启用，也是隐式接在载荷之后、这份填充之前。本文不把「附在 ICV 末尾发出」和「不随包发出」收成同一种填充。2026 年 10 月 23 日没有找到把这两句收成一条的已验证勘误。
保留字段是 16 位。发送方必须置 0，接收方应当忽略，但计算 ICV 时仍把它算进去。关键词按 RFC 2119。下文的「必须」对应原文的大写 MUST 或 SHALL，「应当」对应 SHOULD。
协议号是 51，SPI 不得为 0
一个可独立引用的定义句：紧挨在认证头前面的那个头，其协议字段（IPv4）或下一个头字段（IPv6 或扩展头）取值 51。原文用的是 SHALL。SPI 是任意的 32 位值，0 保留给本地实现，不得出现在线上（RFC 4302 第 2 节、第 2.4 节）。
1 到 255 由 IANA 保留，通常不会分配，除非用法写进某份 RFC。单播上，接收方可以用 SPI 自己标出安全关联，也可以再配上协议类型。两种都够用时怎样选，是本地的事；「能把入站流量映射到单播安全关联」这一机制，所有实现都必须支持。多播时的最长匹配检索在同一节，本文不逐条抄那三步。
下一个头是 8 位，从 IANA 的 IP 协议号里取，标识认证头后面的载荷。原文的例子是：4 表示 IPv4，41 表示 IPv6，6 表示 TCP。传输模式还是隧道模式，不写在这个字段的数值里，而写在安全关联上。两种模式差在保护到哪一截，见 传输模式与隧道模式。那一篇的摆放以 ESP 为主。认证头的位置本文只保留 RFC 4302 第 3.1 节已经写明的差别：
| 模式 | 第 3.1 节写的位置 | 保护范围 |
|---|---|---|
| 传输 | IPv4 放在 IP 头和选项之后、下一层之前。IPv6 那句是小写 should：出现在逐跳选项、路由头和分片头之后 | 下一层。前面 IP 头里的可变字段另按第 3.3.3 节处理 |
| 隧道 | 相对外层头的位置与传输模式相同 | 整个内层 IP 包，含内层头。外层头里的可变字段除外 |
「传输」同样不表示只能承载 TCP 和 UDP。目的选项可以在认证头之前、之后，或两边都有。哪些 IP 字段算可变，附录 A 有表。本文没有重抄那张表。NPTv6 在途中改写 IP 头，因此和保护 IP 头完整性的认证头不兼容。那一篇没有把这句收成「所以 ESP 一定不受影响」。本文也不收成这一句。
序列号是无符号 32 位。对单播或单一发送方的多播，发送方必须对每个发出的包把这个字段加 1。安全关联建立时双方计数器置 0，第一包的序列号是 1。字段必须出现，即使接收方不对某个安全关联启用重放保护。发送方必须总是发出它；接收方不必对它采取行动，但实现必须能够做第 3.3.2 节和第 3.4.3 节的处理。重放保护默认开启。开启时，原文先用小写 must 写序列号不得回绕，接着用大写 MUST 要求：在这条安全关联发出第 2^32 个包之前，用新的安全关联和新密钥重置计数器。多个发送方共用一条安全关联时，原文写明认证头提供不了有意义的重放保护。窗口怎样滑动，见 重放保护。本文不另给一个窗口宽度。第 3.4.3 节的窗口宽度本文没有读。
扩展序列号把计数器扩到 64 位，线上仍只传低 32 位，高 32 位进入 ICV、不发出。是否使用必须由安全关联管理协议协商。括注写明：在 IKEv2 里这一协商是隐式的，默认是扩展序列号，除非显式协商 32 位序列号。RFC 7296 的更新者里有 RFC 9827，其标题涉及扩展序列号变换类型的改名。本文没有重读 RFC 9827，因此不判断这句默认有没有被改写。
分片发生在认证之后
一个可独立引用的定义句：在 IPsec 实现内部，若需要 IP 分片，它发生在认证头处理之后。因此传输模式的认证头只用于完整的 IP 数据报，不用于 IP 分片（RFC 4302 第 3.3.4 节）。
已经加上认证头的 IPv4 包，沿途路由器仍可能再拆。这里用小写 must 写：接收方要先重组，再做认证头处理。括号里的一句写明，这不适用于 IPv6，因为 IPv6 没有由路由器发起的分片。隧道模式作用在一份 IP 包上，这份包的载荷本身可以是已经分过片的 IP 包。
2026 年 10 月 23 日下载的正文仍写：对 IPv6，插入栈或插入线路的实现要检查全部扩展头，看有没有分片头，从而判断要不要在 IPsec 处理前重组。已验证勘误 134 认为还应加上「More 标志或分片偏移非零」。勘误没有改写成已经印进正文的句子。分片头的字段见 IP 分片。本文不提供重组步骤。
同一节写，接收方要接收分片来重组，会带来拒绝服务方面的弱点。实现可以不支持分片，也可以把发出的包标上 DF，以便路径 MTU 发现。无论哪种，实现都必须能产生 ICMP 路径 MTU 消息，或在本机实现里给出等价的内部信号。细节指向安全架构文档。本文没有重读那一份，也不展开这种弱点如何被利用。
非 ESP 标记 写的是 UDP 4500 上的四个 0 和 ESP 的 SPI。RFC 3948 的引言把认证头排除在那份封装之外，理由是认证头对外部 IP 地址的保护与 NAT 不相容。看见协议 51，不表示已经做了那份 UDP 封装，也不表示 SPI 可以是 0。ESP 的 SPI 不得为 0 是另一份文件里的句子。两处的 0 不要并成一个字段。
认证头没有版本号。兼容性必须用对等体之间的信令来解决，例子是 IKE，或带外配置。本文不提供配置步骤。
文件头把它标成 Standards Track，并写明取代 RFC 2402。2026 年 10 月 23 日的勘误页没有列出更新者。本文没有重读 RFC 2402，也没有再核对它后来有没有被标成 Internet Standard。已验证勘误只有 134。Held for Document Update 有 4 条。其中 744 转述 RFC 4301 不再要求支持认证头，状态仍是 Held。本文没有重读 RFC 4301，不把那句转述写成 4302 的正文。其余 Held 条目没有读完。
现象对照
| 现象 | 更可能先看什么 |
|---|---|
| 载荷长度是 4，ICV 为 96 位 | 符合第 2.2 节的例子。整段是 6 个 32 位字，不是 4 字节 |
| 把 24 字节按「不含前 8 字节」算成 2 | 那是别的扩展头的单位。认证头这个例子的字段是 4 |
| 协议或下一个头是 51，SPI 为 0 | 与「0 不得出现在线上」不符 |
| 序列号从 0 的第一包开始 | 计数器初值是 0，第一包应是 1 |
| 只有低 32 位在线上，高 32 位却参与校验 | 符合扩展序列号。高 32 位不发出 |
| IPv6 包里有分片头，就在认证前重组 | 正文仍这么写。已验证勘误 134 还要求 More 或偏移非零。两句不要合成一句 |
核对清单
- 载荷长度先减 2：单位是 32 位字。96 位的例子是 4，对应 6 个字。原文没有印出 24 字节；
- IPv6 的 8 字节对齐不改这个单位。别的扩展头用 64 位字。总表里的 ICV Padding 标成不发出，第 3.3.3.2.1 节又写明对齐填充要发出。隐式的块长填充才写明不发出；
- 前面的协议号是 51，SPI 不得为 0。1 到 255 保留。下一个头的 4、41、6 只说明后面是什么，不说明传输还是隧道；
- 序列号必须发出，第一包是 1。重放保护默认开启时，不得发到第 2^32 个包。IKEv2 默认扩展序列号这句没有对照 RFC 9827；
- 分片在认证处理之后。勘误 134 尚未写进下载到的正文。RFC 4301 与 RFC 2402 没有重读。Held 的 4 条没有读完。