PCAPNG下一代转储文件格式 PCAP-DumpFileFormat
pcapng与pcap抓包格式比较图
本备忘录的状态
本文档是Internet草案，完全符合RFC 2026第10节的所有规定。
Internet-Drafts是Internet工程任务组（IETF）及其工作组的工作文档。请注意，其他组也可能将工作文档分发为Internet-Drafts。
互联网草案是有效期最长为六个月的草案文件，可能随时被其他文件更新，替换或废弃。使用互联网草稿作为参考资料或引用它们而不是“正在进行的工作”是不恰当的。
可以在http://www.ietf.org/ietf/1id-abstracts.txt上访问当前Internet草案列表 。
可以在http://www.ietf.org/shadow.html上访问Internet-Draft Shadow目录列表 。
此互联网草案将于2004年9月2日到期。
版权声明
版权所有©互联网协会（2004年）。版权所有。
抽象
本文档描述了将捕获的数据包转储到文件上的格式。这种格式是可扩展的，目前建议在libpcap / WinPcap数据包捕获库中实现。
更新
- [2009年7月27日] Guy Harris：在附录B中添加了一些缺少保留的块类型。
- [2009年7月27日] Guy Harris：修正了附录B中的拼写错误。标准化块的范围在0x00000000-0x7FFFFFFF范围内。
- [2008年2月8日] Gianluca Varenni：更好的时间戳格式文档。将if_tsaccur选项重命名为if_tsresol。
- [2007年10月22日] Gianluca Varenni：添加了与64位对齐相关的注释。指定选项长度字段是没有填充的长度。这里和那里都有错别字。添加了一些选项示例。
- [2007年10月17日] Ulf Lamping：主要评论：“ISB”中的“接口ID”现在为32位。isb_starttime / isb_endtime取决于if_tsaccur。很多其他编辑......
- [2007年10月8日] Ulf Lamping：修正了几个拼写错误。将块类型分为强制，可选，实验，过时。
- [2006年9月14日] Gianluca Varenni：在AFDX封装信息块中添加了Arinc 429的块类型代码
- [2006年5月23日] Gianluca Varenni：添加了IRIG时间戳块的块类型代码
- [2006年4月23日] Gianluca Varenni：稍微清理了附录C：我们应该使用libpcap中的LINKTYPE_xxx值，而不是DLT_xxx值。修复了附录的介绍并添加了一些注释。
- [2006年3月21日] Gianluca Varenni：添加了附录C的初步版本，详细说明了标准化链接类型。
- [2006年3月21日] Gianluca Varenni：添加了附录B的初步版本，详细说明了标准块类型代码。
- [2006年3月21日] Gianluca Varenni：在2.2节中添加了增强数据包块。修复了列表中的拼写错误：它是接口统计信息块，而不是捕获统计信息块。
- [2006年3月21日] Gianluca Varenni：修正了文件中的一些小错字。
- [2006年3月21日] Gianluca Varenni：修复了数据包阻止中的错误：选项pack_hash应该包含代码3。
- [2006年3月21日] Gianluca Varenni：增加了增强数据包块的定义。
- [2006年3月12日] Gianluca Varenni：在接口描述块中添加了选项if_tsoffset。
目录
1. 目标
2. 一般文件结构
2.1。 一般块结构
2.2。 块类型
2.3。 逻辑块层次结构
2.4。 物理文件布局
2.5。 选项
2.6。 数据格式
3. 块定义
3.1。 Section Header Block（强制性）
3.2。 接口说明块（强制）
3.3。 增强数据包块（可选）
3.4。 简单数据包块（可选）
3.5。 数据包阻止（已过时！）
3.6。 名称解析块（可选）
3.7。 接口统计块（可选）
4。 实验块（值得进一步调查）
4.1。 替代数据包块（实验性）
4.2。 压缩块（实验）
4.3。 加密块（实验）
4.4。 固定长度块（实验）
4.5。 目录块（实验）
4.6。 交通统计和监测区块（实验）
4.7。 事件/安全块（实验性）
5。 推荐文件名扩展名：.pcapng
6. 如何添加供应商/域特定扩展名
7. 结论
附录A. 数据包块标志字
附录B. 标准化块类型代码
附录C. 标准化链路类型代码
附录D. 链路层标头
§ 作者地址
§ 知识产权和版权声明
| TOC |
1.目标
交换数据包跟踪的问题每天变得越来越重要; 遗憾的是，目前还没有针对此任务的标准解决方案。最受欢迎的数据包交换格式之一是由libpcap定义的格式，它相当陈旧，不适合某些现在的应用程序，特别是从可扩展性的角度来看。
本文档提出了一种用于转储数据包跟踪的新格式。正在实现以下目标：
- 可扩展性：除了一些常见的功能之外，第三方应该能够使用专有扩展来丰富文件中嵌入的信息，这些扩展将被无法理解的工具忽略。
- 可移植性：捕获跟踪必须包含独立于进行捕获的计算机的网络，硬件和操作系统读取数据所需的所有信息。
- 合并/附加数据：应该可以在给定文件的末尾添加数据，并且生成的文件仍然必须是可读的。
| TOC |
2.一般文件结构
| TOC |
2.1。一般块结构
捕获文件按块组织，彼此相互附加以形成文件。所有块共享一种通用格式，如图1所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Block Body /
/ /* variable length, aligned to 32 bits */ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 1: Basic block structure. |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块类型 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 块体 /
/ /* 可变长度，对齐32位 */ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 图1：基本块结构。 |
这些字段具有以下含义：
- 块类型（32位）：标识块的唯一值。最高有效位（MSB）等于1的值保留供本地使用。它们允许将私有数据保存到文件中并扩展文件格式。当前定义的类型列表可以在附录B中找到
- 块总长度：此块的总大小（以字节为单位）。例如，没有主体的块的长度是12个字节。
- 块体：块的内容。
- 块总长度：此块的总大小（以字节为单位）。该字段是重复的，允许后向文件导航。
这种结构在所有块之间共享，可以轻松处理文件并跳过不需要的或未知的块。一些块可以包含其他块（嵌套块）。某些块是必需的，即转储文件如果不存在则无效，其他是可选的。
通用块结构允许在需要时定义其他块。不理解它们的解析器可以简单地忽略它们的内容。
| TOC |
2.2。块类型
目前标准化的块类型代码在附录B中规定，它们分为以下四类：
MANDATORY块必须在每个文件中至少出现一次：
- Section Header Block：它定义了捕获文件的最重要特征。
- 接口说明块：它定义了用于捕获流量的接口的最重要特征。
可选块可以出现在文件中：
- 增强型数据包阻止：它包含单个捕获的数据包或其中的一部分。它代表了原始数据包块的演变。
- 简单数据包阻止：它包含一个捕获的数据包或其中的一部分，只有一小部分信息。
- 名称解析块：它定义数据包转储中存在的数字地址和规范名称对应的映射。
- 接口统计信息块：它定义了如何存储一些统计数据（例如丢包等），这对于解决捕获的条件非常有用。
OBSOLETE块不应出现在新写入的文件中（但留待此处参考）：
- 数据包阻止：它包含一个捕获的数据包或其中的一部分。它应该被认为是OBSOLETE，并被增强型数据包块取代。
实验块被认为是有趣的，但作者认为在定义之前它们应该得到更深入的讨论：
- 替代数据包块
- 压缩块
- 加密块
- 固定长度块
- 目录块
- 流量统计和监控块
- 事件/安全块
| TOC |
2.3。逻辑块层次结构
这些块在它们相互引用时构建逻辑层次结构。图2以“树视图”的形式显示了当前定义的块的逻辑层次结构：
Section Header
|
+- Interface Description
| +- Simple Packet
| +- Enhanced Packet
| +- Interface Statistics
|
+- Name Resolution
| Figure 2: Logical block Hierarchy of a pcapng file. |
Section Header
|
+ - 接口说明
| + - 简单数据包
| + - 增强数据包
| + - 接口统计
|
+ - 名称解析
| 图2：pcapng文件的逻辑块层次结构。 |
例如：每个捕获的数据包指的是特定的捕获接口，接口本身指的是特定的部分。
| TOC |
2.4。物理文件布局
该文件必须以Section Header Block开头。但是，转储中可以存在多个Section Header Block，每个块覆盖其后的数据，直到下一个（或文件末尾）。Section包括由两个Section Header Blocks（或Section Header Block和文件末尾）分隔的数据，包括第一个Section Header Block。
如果应用程序因版本号不同而无法读取Section，则必须跳过所有内容，直到下一个Section Header Block。请注意，为了正确跳过块直到下一节，所有块必须在开头有字段Type和Length。这是必须在块格式的未来版本中维护的强制性要求。
图3显示了典型的文件配置，其中包含一个覆盖整个文件的Section Header。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB v1.0 | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3: File structure example: Typical configuration with a single Section Header Block. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB v1.0 | 数据|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 图3：文件结构示例：具有单个Section Header Block的典型配置。 |
图4显示了一个包含三个标头的文件，通常是文件串联的结果。仅了解文件格式1.0版的应用程序会跳过中间节并在第三个节标题后重新开始处理数据包。
|-- 1st Section --|-- 2nd Section --|-- 3rd Section --|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4: File structure example: three Section Header Blocks in a single file. |
| - 第1部分 - | - 第2部分 - | - 第3部分 - |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB v1.0 | 数据| SHB V1.1 | 数据| SHB V1.0 | 数据|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 图4：文件结构示例：单个文件中的三个Section Header Blocks。 |
图5显示了一个与“经典libpcap”文件相当的文件 - 一个有用的捕获文件的最小值。它包含单个段头块（SHB），单个接口描述块（IDB）和一些增强包块（EPB）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB | IDB | EPB | EPB | ... | EPB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 5: File structure example: a pcapng file similar to a classical libpcap file. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB | IDB | EPB | EPB | ...... | EPB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 图5：文件结构示例：类似于经典libpcap文件的pcapng文件。 （请参考最开始的pcapng与pcap对比图） |
图6显示了一个复杂的示例文件。除了上面的最小文件之外，它还包含从三个接口捕获的数据包，还包括一些名称解析块（NRB）和接口统计数据块（ISB）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB | IDB | IDB | IDB | EPB | EPB | NRB | ... | EPB | ISB | NRB | EPB | EPB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 6: File structure example: more complex pcapng file. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHB | IDB | IDB | IDB | EPB | EPB | NRB | ...... | EPB | ISB | NRB | EPB | EPB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 图6：文件结构示例：更复杂的pcapng文件。 |
最后一个例子应该表明，与传统的libpcap格式相比，块结构使文件格式非常灵活。
| TOC |
2.5。选项
所有块体都可以嵌入可选字段。可选字段可用于插入在读取数据时可能有用的一些信息，但这并不是数据包处理所必需的。因此，每个工具都可以读取可选字段的内容（如果有的话），或者跳过其中一些甚至是一次性的。
一次跳过所有可选字段很简单，因为大多数块由具有固定格式的第一部分和第二部分可选部分组成。因此，块长度字段（存在于通用块结构中，参见第2.1节）可用于跳过下一个块之前的所有内容。
选项是类型 - 长度 - 值字段的列表，每个字段包含一个值：
- 选项类型（2字节）：它包含指定当前TLV记录类型的代码。最高有效位等于1的选项类型保留供本地使用; 因此，无法保证所使用的代码在所有捕获文件（由其他应用程序生成）中是唯一的。如果必须唯一标识供应商特定的扩展，则供应商必须请求其MSB等于零的选项代码。
- 选项长度（2个字节）：它包含以下“选项值”字段的实际长度，不包含填充字节。
- 选项值（可变长度）：它包含给定选项的值，与32位边界对齐。该字段的实际长度（即没有填充字节）由Option Length字段指定。
选项可能会重复多次（例如，有几个与之关联的IP地址的接口）TODO：如果每个选项可以/不应该出现多次，则提及每个选项。选项列表由选项终止，该选项使用特殊的“选项结束”代码（opt_endofopt）。
可选字段的格式如图7所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Option Value /
/ /* variable length, aligned to 32 bits */ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ . . . other options . . . /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code == opt_endofopt | Option Length == 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 7: Options 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 选项代码| 期权长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/选项值/
/ / *可变长度，对齐32位* / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ 。。。其他选择。。。/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 选项代码== opt_endofopt | 选项长度== 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 图7：选项格式。 |
以下代码始终存在于任何可选字段中：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| opt_endofopt | 0 | 0 | 它分隔可选字段的结尾。在给定的选项列表中不能重复此块。 | |
| opt_comment | 1 | 变量 | 包含与当前块关联的注释的UTF-8字符串。 | “这个数据包是我们所有问题的开始”/“数据包17-23显示伪造的TCP重传，如bugzilla条目1486中所报告的那样！” /“在南部工厂捕获”/“我再次检查，现在它正常工作”/ ... |
| TOC |
2.6。数据格式
字节序
每个部分中包含的数据将始终根据倾卸机的特性（小端/大端）保存。这指的是保存为数字且跨越两个或更多字节的所有字段。
使每个部分以生成主机的本机格式保存的方法更有效，因为它避免了在主机本身上读/写时的数据转换，这是生成/处理捕获转储时最常见的情况。
请注意：字节标题块表示字节序列。由于此块可以在pcapng文件中多次出现，因此单个文件可以包含两个endianess变体！
对准
本规范的大多数（全部？）字段使用16位和32位值的正确对齐。如果使用内存映射文件等技术，则可以更轻松，更快速地读取/写入文件内容。
对齐字节（在本文档中标记，例如“对齐到32位”）应该用零字节填充（TODO：为了性能，这个要求是个好主意/我们想在这里允许虚假字节吗？）。
请注意：64位值未与64位边界对齐。这是因为文件自然只与32位边界对齐。在阅读和书写这些价值观时应特别小心。TODO：规范与64位值的保存方式不太一致。在数据包块中，我们清楚地指定了应该保存64位时间戳的低32位和高位的位置。在SHB中，我们在保存截面长度时使用机器的endianess。
TODO - 也许我们必须在这里指定更多内容。我们所说的足以避免任何歧义吗？
| TOC |
3.块定义
本节详细介绍了当前定义的块体的格式。
| TOC |
3.1。部分标题块（必填）
Section Header Block是强制性的。它标识捕获转储文件的一部分的开头。Section Header Block不包含数据，而是标识逻辑相关的块（接口，数据包）列表。其格式如图8所示。
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
+---------------------------------------------------------------+
0 | Block Type = 0x0A0D0D0A |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Byte-Order Magic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Major Version | Minor Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | |
| Section Length |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 / /
/ Options (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 8: Section Header Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x0A0D0D0A |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Byte-Order Magic |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
12 | 主要版本| 次要版本|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | |
| 截面长度|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 / /
/选项（变量）
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图8：节标题块格式。 |
字段的含义是：
- 块类型：段头块的块类型是对应于4字符串“\ r \ n \ n \ r”（0x0A0D0D0A）的整数。使用此特定值有两个原因：
- 此编号用于检测文件是否已通过FTP或HTTP从机器传输到另一台具有不适当的ASCII转换的文件。在这种情况下，此字段的值将不同于标准字段（“\ r \ n \ n \ r”），并且阅读器可以检测到可能已损坏的文件。
- 此值是回文，因此无论截面的字节顺序如何，读者都能够识别截面标题块。通过读取块类型之后的8个字节的字节顺序魔术来识别字节顺序。
- 块总长度：该块的总大小，如第2.1节所述。
- Byte-Order Magic：幻数，其值为十六进制数0x1A2B3C4D。此数字可用于区分已保存在little-endian计算机上的部分与保存在big-endian计算机上的部分。
- 主要版本：格式的当前市长版本的编号。当前值为1.如果格式以可读取新格式的工具无法读取旧格式的方式更改，则此值应更改（即，代码必须检查版本号以便能够读取这两种格式）。
- 次要版本：格式的当前次要版本的编号。当前值为0.如果格式发生变化，以便可以读取新格式的工具仍然可以自动读取新格式，但只能读取旧格式的代码无法读取新格式，则此值应该更改。
- Section Length：64位值，指定以下部分的字节长度，不包括Section Header Block本身。此字段可用于跳过该部分，以便在大文件中更快地导航。Section Length -1（0xFFFFFFFFFFFFFFFF）表示未指定节的大小，跳过该节的唯一方法是解析它包含的块。请注意，如果此字段有效（即不为-1），则其值始终与32位对齐，因为所有块都与32位边界对齐。此外，在访问此字段时应特别小心：由于文件中所有块的对齐方式均为32位，因此无法保证此字段与64位边界对齐。这可能是64位工作站上的问题。
- 选项：可选地，可以存在选项列表（根据第2.5节中定义的规则格式化）。
添加新的块类型或选项不一定要求更改主要编号或次要编号，因为不知道块类型或选项的代码可能只是跳过它; 仅当跳过块或选项不起作用时才应更改次要版本号。
除了第2.5节中定义的选项外，以下选项在此块中有效：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| shb_hardware | 2 | 变量 | 一个UTF-8字符串，包含用于创建此部分的硬件描述。 | “x86个人电脑”/“Sun Sparc工作站”/ ... |
| shb_os | 3 | 变量 | 一个UTF-8字符串，包含用于创建此部分的操作系统的名称。 | “Windows XP SP2”/“openSUSE 10.2”/ ... |
| shb_userappl | 4 | 变量 | 一个UTF-8字符串，包含用于创建此部分的应用程序的名称。 | “dumpcap V0.99.7”/ ... |
| TOC |
3.2。接口说明块（必填）
接口描述块是必需的。需要此块来指定已进行捕获的网络接口的特征。为了将捕获的数据正确地关联到相应的接口，必须在使用它的任何其他块之前定义接口描述块; 因此，该块通常紧接在Section Header Block之后。
接口描述块仅在其所属的部分内有效。接口描述块的结构如图9所示。
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
+---------------------------------------------------------------+
0 | Block Type = 0x00000001 |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | LinkType | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | SnapLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 / /
/ Options (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 9: Interface Description Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x00000001 |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | LinkType | 保留|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | SnapLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 / /
/选项（变量）
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图9：接口描述块格式。 |
字段的含义是：
- 块类型：接口描述块的块类型为1。
- 块总长度：该块的总大小，如第2.1节所述。
- LinkType：定义此接口的链接层类型的值。附录C中提供了标准化链路层类型代码列表。
- SnapLen：从每个数据包转储的最大字节数。超过此值的每个数据包的部分将不会存储在文件中。（TODO：是否需要发出“无限制”信号？）
- 选项：可选地，可以存在选项列表（根据第2.5节中定义的规则格式化）。
接口ID：写入/读取捕获文件的工具将渐进的16位数字（从“0”开始）与每个接口定义块相关联。此编号在每个部分中是唯一的，并唯一标识接口（在当前部分内）; 因此，两个Sections可以具有由相同标识符标识的接口。该唯一标识符由其他块（例如，分组块）引用以指出该块所指的接口（例如，用于捕获分组的接口）。（TODO - 定义“无效接口ID”会很好，例如0xFFFFFFFF）
除了第2.5节中定义的选项外，以下选项在此块中有效：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| if_name | 2 | 变量 | UTF-8字符串，包含用于捕获数据的设备的名称。 | “eth0”/“\ Device \ NPF_ {AD1CE675-96D0-47C5-ADD0-2504B9126B68}”/ ... |
| if_description | 3 | 变量 | UTF-8字符串，包含用于捕获数据的设备的描述。 | “Broadcom NetXtreme”/“第一个以太网接口”/ ... |
| if_IPv4addr | 4 | 8 | 接口网络地址和网络掩码。当为接口分配多个IPv4地址时，可以在同一接口描述块中多次重复此选项。 | 192 168 1 1 255 255 255 0 |
| if_IPv6addr | 五 | 17 | 接口网络地址和前缀长度（存储在最后一个字节中）。当为接口分配了多个IPv6地址时，可以在同一接口描述块中多次重复此选项。 | 2001：0db8：85a3：08d3：1319：8a2e：0370：7344/64写成（以十六进制表示）为“20 01 0d b8 85 a3 08 d3 13 19 8a 2e 03 70 73 44 40” |
| if_MACaddr | 6 | 6 | 接口硬件MAC地址（48位）。 | 00 01 02 03 04 05 |
| if_EUIaddr | 7 | 8 | 接口硬件EUI地址（64位）（如果有）。 | TODO：举一个很好的例子 |
| if_speed | 8 | 8 | 接口速度（以bps为单位）。 | 100000000 100Mbps |
| if_tsresol | 9 | 1 | 解决时间戳。如果最高有效位等于零，则其余位指示时间戳的分辨率，如负功率10（例如，6表示微秒分辨率，时间戳是自1970年1月1日以来的微秒数）。如果最高有效位等于1，则剩余位表示分辨率为2的负功率（例如10表示1/1024秒）。如果此选项不存在，则假定分辨率为10 ^ -6（即时间戳具有与标准“libpcap”时间戳相同的分辨率）。 | 6 |
| if_tzone | 10 | 4 | GMT支持的时区（TODO：指定更好）。 | TODO：举一个很好的例子 |
| if_filter | 11 | 变量 | 用于捕获流量的过滤器（例如“仅捕获TCP流量”）。选项数据的第一个字节保留所使用的过滤器的代码（例如，如果这是一个libpcap字符串，或BPF字节码，等等）。有关此格式的更多详细信息将在附录XXX（TODO）中介绍。（TODO：更好地为不同的字段使用不同的选项？例如if_filter_pcap，if_filter_bpf，...） | 00“tcp端口23和主机10.0.0.5” |
| if_os | 12 | 变量 | 一个UTF-8字符串，包含安装此接口的计算机操作系统的名称。这可能与Section Header Block（第3.1节）中包含的相同信息不同，因为捕获可以在远程计算机上完成。 | “Windows XP SP2”/“openSUSE 10.2”/ ... |
| if_fcslen | 13 | 1 | 一个整数值，指定此接口的帧校验序列的长度（以位为单位）。对于FCS长度可在时间内更改的链路层，可以使用数据包块标志字（参见附录A）。 | 4 |
| if_tsoffset | 14 | 8 | 一个64位整数值，指定必须添加到每个数据包的时间戳以获取数据包的绝对时间戳的偏移量（以秒为单位）。如果缺少该选项，则必须将存储在数据包中的时间戳视为绝对时间戳。可以使用选项if_tzone指定偏移的时区。TODO：对于高度同步的捕获系统，小数秒偏移的if_tsoffset_low不会有用吗？ | 1234 |
| TOC |
3.3。增强的数据包块（可选）
增强型数据包块是用于存储来自网络的数据包的标准容器。增强数据包块是可选的，因为可以通过此块或简单数据包块存储数据包，这可用于加速转储生成。增强型数据包的格式如图10所示。
增强型数据包块是对原始数据包块的改进：
- 它将接口标识符存储为32位整数值。当捕获存储来自大量接口的数据包时，这是一项要求
- 与分组块不同，捕获系统在该分组与前一分组之间丢弃的分组的数量不存储在头部中，而是存储在块本身的选项中。
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
+---------------------------------------------------------------+
0 | Block Type = 0x00000006 |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Timestamp (High) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | Timestamp (Low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Captured Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Packet Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 / /
/ Packet Data /
/ /* variable length, aligned to 32 bits */ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Options (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 10: Enhanced Packet Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x00000006 |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 接口ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 时间戳（高）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 时间戳（低）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 捕获Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | 包Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 / /
/分组数据/
/ / *可变长度，对齐32位* / /
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/选项（变量）
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图10：增强的数据包块格式。 |
增强数据包块具有以下字段：
- 块类型：增强型数据包块的块类型为6。
- 块总长度：该块的总大小，如第2.1节所述。
- 接口ID：它指定该数据包来自的接口; 正确的接口将是其接口描述块（在文件的当前部分内）由该字段的相同编号（参见第3.2节）标识的接口。
- 时间戳（高）和时间戳（低）：表示时间戳的64位数量的高32位和低32位。时间戳是一个64位无符号整数，表示自1970年1月1日以来的单位数。解释此字段的方式由此数据包引用的“接口描述”块的“if_tsresol”选项（参见图9）指定。请注意，与libpcap文件格式不同，时间戳不会保存为两个32位值，这些值占自1970年1月1日以来的秒和微秒。它们保存为单个64位数量，保存为两个32位字。
- 捕获的Len：从数据包捕获的字节数（即分组数据字段的长度）。它将是实际数据包长度和快照长度（在图9中定义）中的最小值。该字段的值不包括在分组数据字段末尾添加的填充字节，以将分组数据字段与32位边界对齐
- Packet Len：数据包在网络上传输时的实际长度。如果用户只想要数据包的快照，它可能与捕获的Len不同。
- 分组数据：来自网络的数据，包括链路层报头。该字段的实际长度为Captured Len。链路层报头的格式取决于接口描述块中指定的LinkType字段（参见第3.2节），并在附录D中指定。
- 选项：可选地，可以存在选项列表（根据第2.5节中定义的规则格式化）。
除了第2.5节和数据包块中定义的选项外，以下选项在此块中有效：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| epb_flags | 2 | 4 | 包含链接层信息的标记字。允许标志的完整规范可以在附录A中找到。 | 0 |
| epb_hash | 3 | 变量 | 此选项包含数据包的哈希值。第一个字节指定散列算法，而后面的字节包含实际散列，其大小取决于散列算法，因此取决于第一个位中的值。散列算法可以是：2s补码（算法字节= 0，大小= XXX），XOR（算法字节= 1，大小= XXX），CRC32（算法字节= 2，大小= 4），MD-5（算法字节= 3，size = XXX），SHA-1（算法字节= 4，大小= XXX）。哈希仅涵盖数据包，而不是捕获驱动程序添加的标头：这使得可以在网卡内计算它。哈希允许更容易地比较/合并不同的捕获文件，以及数据采集系统和捕获库之间的可靠数据传输。（TODO：上面的文字使用“第一位”，但这不应该是“第一个字节”？！ | TODO：举一个很好的例子 |
| epb_dropcount | 4 | 8 | 一个64位整数值，指定此数据包与前一个数据包之间丢失的数据包数（通过接口和操作系统）。 | 0 |
| TOC |
3.4。简单数据包块（可选）
Simple Packet Block是一个轻量级容器，用于存储来自网络的数据包。它的存在是可选的。
简单数据包模块类似于数据包模块（参见第3.5节），但它更小，更易于处理，并且只包含一组最小的信息。当性能或占用空间是关键因素时，例如在持续的流量转储应用中，该块优于标准分组块。捕获文件可以包含数据包块和简单数据包块：例如，当硬件资源变得严重时，捕获工具可以从数据包块切换到简单数据包块。
简单数据包块不包含接口ID字段。因此，必须假设所有简单数据包块都已在先前在第一个接口描述块中指定的接口上捕获。
图11显示了简单数据包块的格式。
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
+---------------------------------------------------------------+
0 | Block Type = 0x00000003 |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Packet Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 / /
/ Packet Data /
/ /* variable length, aligned to 32 bits */ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 11: Simple Packet Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x00000003 |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 包Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 //
/ Packet Data /
/ / *可变长度，对齐32位* / /
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图11：简单数据包块格式。 |
简单数据包块具有以下字段：
- 块类型：简单数据包块的块类型为3。
- 块总长度：该块的总大小，如第2.1节所述。
- Packet Len：数据包在网络上传输时的实际长度。如果数据包已被捕获进程截断，则可以与捕获的len不同。
- 分组数据：来自网络的数据，包括链路层报头。该字段的长度可以从块头中存在的块总长度中导出，并且它是SnapLen（存在于接口描述块中）和包Len（存在于该头中）中的最小值。
简单数据包块不包含时间戳，因为这通常是PC上最昂贵的操作之一。此外，有些应用程序不需要它; 例如，入侵检测系统对数据包感兴趣，而不是它们的时间戳。
由于无法引用正确的接口ID字段（因此不包含任何接口ID字段），因此简单数据包块不能出现在具有多个接口的节中。
简单数据包块在磁盘空间方面非常有效：长度为100字节的快照只需要16字节的开销，这相当于超过86％的效率。
| TOC |
3.5。数据包块（已过时！）
数据包块已标记为已过时，请更好地使用增强数据包块！
数据包块是用于存储来自网络的数据包的标准容器。数据包块是可选的，因为可以通过此块或简单数据包块存储数据包，这可用于加速转储生成。数据包块的格式如图12所示。
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
+---------------------------------------------------------------+
0 | Block Type = 0x00000002 |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Interface ID | Drops Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Timestamp (High) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | Timestamp (Low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Captured Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Packet Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 / /
/ Packet Data /
/ /* variable length, aligned to 32 bits */ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Options (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 12: Packet Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x00000002 |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 接口ID | 滴数|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 时间戳（高）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 时间戳（低）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 捕获Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | 包Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 / /
/分组数据/
/ / *可变长度，对齐32位* / /
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/选项（变量）
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图12：数据包块格式。 |
数据包块具有以下字段：
- 块类型：数据包块的块类型为2。
- 块总长度：该块的总大小，如第2.1节所述。
- 接口ID：它指定该数据包来自的接口; 正确的接口将是其接口描述块（在文件的当前部分内）由该字段的相同编号（参见第3.2节）标识的接口。
- 滴数：本地掉落计数器。它指定此数据包与前一个数据包之间丢失的数据包数（通过接口和操作系统）。值xFFFF（十六进制）保留给那些信息不可用的系统。
- 时间戳（高）和时间戳（低）：数据包的时间戳。时间戳的格式与增强型数据包块（第3.3节）中已定义的格式相同。
- 捕获的Len：从数据包捕获的字节数（即分组数据字段的长度）。它将是实际数据包长度和快照长度（图9中定义的SnapLen ）中的最小值。该字段的值不包括在分组数据字段末尾添加的填充字节，以将分组数据字段与32位边界对齐
- Packet Len：数据包在网络上传输时的实际长度。如果用户只想要数据包的快照，则可以与捕获的Len不同。
- 分组数据：来自网络的数据，包括链路层报头。链路层报头的格式取决于接口描述块中指定的LinkType字段（参见第3.2节），并在附录D中指定。该字段的实际长度为Captured Len。
- 选项：可选地，可以存在选项列表（根据第2.5节中定义的规则格式化）。
除了第2.5节中定义的选项外，以下选项在此块中有效：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| pack_flags | 2 | 4 | 与增强包块的epb_flags相同。 | 0 |
| pack_hash | 3 | 变量 | 与增强数据包块的epb_hash相同。 | TODO：举一个很好的例子 |
| 表格1 |
| TOC |
3.6。名称解析块（可选）
名称解析块用于支持数字地址（存在于捕获的数据包中）与其对应的规范名称的关联，并且它是可选的。将文字名称保存在文件中，这可以防止在延迟时间内需要名称解析，此时名称和地址之间的关联可能与捕获时使用的名称和地址之间的关联不同。此外，名称解析块避免了每次打开跟踪捕获时发出大量DNS请求的需要，并且在使用未连接到网络的计算机读取捕获时也允许具有名称解析。
名称解析块通常位于文件的开头，但不能对其位置进行任何假设。名称解析块可以通过处理文件的工具（如网络分析器）再次添加。
名称解析块的格式如图13所示。
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
+---------------------------------------------------------------+
0 | Block Type = 0x00000004 |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Record Type | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 / Record Value /
/ /* variable length, aligned to 32 bits */ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. . . . other records . . . .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type == end_of_recs | Record Length == 00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Options (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 13: Name Resolution Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x00000004 |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 记录类型| 记录长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 /记录值/
// *可变长度，对齐32位* / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
。。
。。。。其他记录。。。。
。。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 记录类型== end_of_recs | 记录长度== 00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/选项（变量）/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图13：名称解析块格式。 |
名称解析块包含以下字段：
- 块类型：名称解析块的块类型为4。
- 块总长度：该块的总大小，如第2.1节所述。
接下来是一个以零终止的记录列表（TLV格式），每个记录包含网络地址和名称之间的关联。有三种可能的记录类型：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| nres_endofrecord | 0 | 0 | 它分隔名称解析记录的结尾。需要此记录来确定名称解析记录列表何时结束以及某些选项（如果有）开始。 | |
| nres_ip4record | 1 | 变量 | 指定IPv4地址（包含在前4个字节中），后跟一个或多个以零结尾的字符串，其中包含该地址的DNS条目。 | 127 0 0 1“localhost” |
| nres_ip6record | 2 | 变量 | 指定IPv6地址（包含在前16个字节中），后跟一个或多个以零结尾的字符串，其中包含该地址的DNS条目。 | TODO：举一个很好的例子 |
| 表2 |
每个记录值都与32位边界对齐。相应的记录长度反映了记录值的实际长度。
在名称解析记录列表之后，可选地，可以存在选项列表（根据第2.5节中定义的规则格式化）。
除了第2.5节中定义的选项外，以下选项在此块中有效：
| 名称 | 码 | 长度 | 描述 | 例子） |
|---|---|---|---|---|
| ns_dnsname | 2 | 变量 | 一个UTF-8字符串，包含用于执行名称解析的计算机名称（DNS服务器）。 | “our_nameserver” |
| ns_dnsIP4addr | 3 | 4 | DNS服务器的IPv4地址。 | 192 168 0 1 |
| ns_dnsIP6addr | 4 | 16 | DNS服务器的IPv6地址。 | TODO：举一个很好的例子 |
TODO：如果名称解析仅对特定接口有效，则添加“接口ID”选项？
TODO：这里有两个“可选机制”（记录与选项）是否有意义？
| TOC |
3.7。接口统计块（可选）
接口统计信息块包含给定接口的捕获统计信息，并且是可选的。统计信息被引用到Interface ID字段标识的当前Section中定义的接口。接口统计信息块通常位于文件的末尾，但不能对其位置进行任何假设 - 对于同一接口，它甚至可以出现多次。
接口统计模块的格式如图14所示。
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
+---------------------------------------------------------------+
0 | Block Type = 0x00000005 |
+---------------------------------------------------------------+
4 | Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Timestamp (High) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | Timestamp (Low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 / /
/ Options (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 14: Interface Statistics Block 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
+ ------------- -------------------------------------------------- +
0 | 块类型= 0x00000005 |
+ ------------------------------------------------- -------------- +
4 | 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | 接口ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | 时间戳（高）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | 时间戳（低）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 / /
/选项（变量）
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图14：接口统计数据块格式。 |
这些字段具有以下含义：
- 块类型：接口统计块的块类型为5。
- 块总长度：该块的总大小，如第2.1节所述。
- 接口ID：指定这些统计引用的接口; 正确的接口将是其接口描述块（在文件的当前部分内）由该字段的相同编号（参见第3.2节）标识的接口。请注意：在本文档的前几个版本中，此字段仅为16位。因为这与它在本文档的其他地方的用法不同，并且因为此块在之前并未“在野外”使用（至于作者的知识），将其更改为32位似乎是合理的！
- 时间戳：此统计信息引用的时间。时间戳的格式与增强型数据包块（第3.3节）中已定义的格式相同。
- 选项：可选地，可以存在选项列表（根据第2.5节中定义的规则格式化）。
所有统计字段都定义为选项，以便处理没有完整统计数据集的系统。因此，对于第2.5节中定义的选项，以下选项在此块中有效：
| 名称 | 码 | 长度 | 描述 | TODO：举一个很好的例子 |
|---|---|---|---|---|
| isb_starttime | 2 | 8 | 捕获开始的时间; 时间将存储在两个块中，每个块包含四个字节。时间戳的格式与增强型数据包块（第3.3节）中已定义的格式相同。 | TODO：举一个很好的例子 |
| isb_endtime | 3 | 8 | 捕获结束的时间; ; 时间将存储在两个块中，每个块包含四个字节。时间戳的格式与增强型数据包块（第3.3节）中已定义的格式相同。 | TODO：举一个很好的例子 |
| isb_ifrecv | 4 | 8 | 从捕获开始开始从物理接口接收的数据包数。 | 100 |
| isb_ifdrop | 五 | 8 | 由于缺少从捕获开始的资源而被接口丢弃的数据包数。 | 0 |
| isb_filteraccept | 6 | 8 | 从捕获开始到过滤器接受的数据包数。 | 100 |
| isb_osdrop | 7 | 8 | 操作系统从捕获开始时丢弃的数据包数。 | 0 |
| isb_usrdeliv | 8 | 8 | 从捕获开始开始传递给用户的数据包数。此字段中包含的值可能与值'isb_filteraccept - isb_osdrop'不同，因为捕获结束时某些数据包仍可能位于OS缓冲区中。 | 0 |
引用数据包计数器的所有字段都是64位值，用当前节的字节顺序表示。访问这些字段时必须特别小心：由于所有块都与32位边界对齐，因此不保证这些字段在64位边界上对齐。
| TOC |
4.实验块（值得进一步调查）
| TOC |
4.1。替代数据包块（实验性）
一些其他数据包块（除了前面段落中描述的那些）是否有用？
| TOC |
4.2。压缩块（实验）
压缩块是可选的。文件可以包含任意数量的这些块。正如名称所示，压缩块用于存储压缩数据。其格式如图15所示。
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
+---------------------------------------------------------------+
| Block Type = ? |
+---------------------------------------------------------------+
| Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compr. Type | |
+-+-+-+-+-+-+-+-+ |
| |
| Compressed Data |
| |
| /* variable length, byte-aligned */ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 15: Compression Block 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
+ ------------- -------------------------------------------------- +
| 块类型=？|
+ ------------------------------------------------- -------------- +
| 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| COMPR。输入 |
+-+-+-+-+-+-+-+-+
| |
| 压缩数据|
| |
| / *可变长度，字节对齐* / |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图15：压缩块格式。 |
这些字段具有以下含义：
- 块类型：尚未分配压缩块的块类型。
- 块总长度：该块的总大小，如第2.1节所述。
- 压缩类型：指定压缩算法。该字段的可能值为0（未压缩），1（Lempel Ziv），2（Gzip），其他?? 对某些类型的流量（例如web）来说，某种愚蠢和快速压缩算法可能会有效，但是哪种？
- 压缩数据：该块的数据。解压缩后，它由其他块组成。
| TOC |
4.3。加密块（实验）
加密块是可选的。文件可以包含任意数量的这些块。加密块用于存储加密数据。其格式如图16所示。
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
+---------------------------------------------------------------+
| Block Type = ? |
+---------------------------------------------------------------+
| Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encr. Type | |
+-+-+-+-+-+-+-+-+ |
| |
| Encrypted Data |
| |
| /* variable length, byte-aligned */ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 16: Encryption Block 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
+ ------------- -------------------------------------------------- +
| 块类型=？|
+ ------------------------------------------------- -------------- +
| 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENCR。输入 |
+-+-+-+-+-+-+-+-+
| |
| 加密数据|
| |
| / *可变长度，字节对齐* / |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图16：加密块格式。 |
这些字段具有以下含义：
- 块类型：尚未分配加密块的块类型。
- 块总长度：该块的总大小，如第2.1节所述。
- 加密类型：指定加密算法。该字段的可能值是??? （TODO）注意：此块可能包含其他字段，具体取决于加密算法。准确定义。
- 加密数据：此块的数据。一旦被描述，它就会产生其他块。
| TOC |
4.4。固定长度块（实验）
固定长度块是可选的。文件可以包含任意数量的这些块。固定长度块可用于优化对文件的访问。其格式如图17所示。固定长度块存储具有恒定大小的记录。它包含一组块（通常是数据包块或简单数据包块），它指定大小。先验地知道这个大小有助于扫描文件并加载它的一些部分而不截断块，并且对于像ATM这样的基于单元的网络特别有用。
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
+---------------------------------------------------------------+
| Block Type = ? |
+---------------------------------------------------------------+
| Block Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cell Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Fixed Size Data |
| |
| /* variable length, byte-aligned */ |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Total Length |
+---------------------------------------------------------------+
| Figure 17: Fixed Length Block 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
+ ------------- -------------------------------------------------- +
| 块类型=？|
+ ------------------------------------------------- -------------- +
| 块总长度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 细胞大小 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| 固定尺寸数据|
| |
| / *可变长度，字节对齐* / |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 块总长度|
+ ------------------------------------------------- -------------- +
| 图17：固定长度块格式。 |
这些字段具有以下含义：
- 块类型：尚未分配固定长度块的块类型。
- 块总长度：该块的总大小，如第2.1节所述。
- 单元大小：数据字段中包含的块的大小。
- 固定大小数据：此块的数据。
| TOC |
4.5。目录块（实验）
如果存在，则此块包含以下信息：
- 索引包数（N）
- 包含任何索引数据包的位置和长度的表（N个条目）
目录块后面必须至少有N个数据包，否则必须将其视为无效。它可用于有效地将文件的一部分加载到内存并支持对内存映射文件的操作。由于文件处理，可以通过网络分析器等工具添加此块。
| TOC |
4.6。交通统计和监测区块（实验）
可以定义一个或多个块以包含网络统计或流量监视信息。它们可用于存储从RMON或Netflow探针或其他网络监视工具收集的数据。
| TOC |
4.7。事件/安全块（实验）
该块可用于存储事件。事件可能包含通用信息（例如网络负载超过50％，服务器已关闭...）或安全警报。一个事件可能是：
- 跳过，如果应用程序不知道如何处理它
- 由数据包独立处理。换句话说，应用程序会跳过数据包并仅处理警报
- 与数据包相关的处理：例如，安全工具只能加载安全警报附近的文件包; 监视工具可以跳过服务器关闭时捕获的数据包。
| TOC |
5.推荐的文件扩展名：.pcapng
本文档中指定的“PCAP下一代转储文件格式”的推荐文件扩展名为“.pcapng”。
至少在“Windows世界”中，文件通过文件名的扩展名来区分。从技术上讲，这种扩展实际上并不需要，因为应用程序应该能够通过文件开头的“魔术字节”自动检测pcapng文件格式。但是，使用名称扩展名可以更轻松地处理文件（例如，可视化区分文件格式），因此建议使用.pcapng作为遵循此规范的文件的名称扩展名（尽管不是必需的）。
请注意：为避免混淆（如当前使用的.cap用于不同捕获文件格式的pletora），应避免使用除.pcapng之外的其他文件扩展名！
| TOC |
6.如何添加供应商/域特定扩展
TODO - 更详细地解释为现有块添加新块类型和新选项的首选方法。
| TOC |
7.结论
本文档中提出的文件格式应该非常通用，并且可以满足广泛的应用。在最简单的情况下，它可以包含网络数据的原始转储，由一系列简单数据包块组成。在最复杂的情况下，它可以用作异构信息的存储库。在每种情况下，文件仍然易于解析，应用程序总是可以跳过它不感兴趣的数据; 同时，不同的应用程序可以共享该文件，并且每个应用程序都可以从其他应用程序生成的信息中受益。可以连接两个或多个文件，获取另一个有效文件。
| TOC |
附录A.数据包块标志字
Packet Block Flags Word是一个32位值，包含有关数据包的链路层信息。
这些位的含义如下：
| 位号 | 描述 |
|---|---|
| 0-1 | 入站/出站数据包（00 =信息不可用，01 =入站，10 =出站） |
| 2-4 | 接收类型（000 =未指定，001 =单播，010 =多播，011 =广播，100 =混杂）。 |
| 5-8 | FCS长度，以字节为单位（如果此信息不可用，则为0000）。此值将覆盖接口描述块的if_fcslen选项，并与那些FCS长度可在时间内更改的链路层（例如PPP）一起使用。 |
| 9-15 | 保留（必须设置为零）。 |
| 16-31 | 链路层相关的错误（位31 =符号错误，位30 =前导码错误，位29 =开始帧定界符错误，位28 =未对齐帧错误，位27 =错误的帧间间隙错误，位26 =包太短错误，位25 =包过长错误，位24 = CRC错误，其他?? 16位是否足够？）。 |
| TOC |
附录B.标准化块类型代码
每个块由32位整数值唯一标识，存储在块头中。
如第2.1节所述，最高有效位（第31位）设置为1的块类型代码保留供应用程序本地使用。
本文档标准化了所有剩余的块类型代码（0x00000000至0x7FFFFFFF）。应将请求发送给本文档的作者，以向规范添加新的标准块类型代码。
以下是标准化块类型代码的列表。
| 块类型代码 | 描述 |
|---|---|
| 00000000 | 保留??? |
| 00000001 | 接口说明块 |
| 0x00000002 | 数据包块 |
| 0x00000003 | 简单数据包块 |
| 0x00000004 | 名称解析块 |
| 0x00000005 | 接口统计块 |
| 0x00000006 | 增强的数据包块 |
| 0x00000007 | IRIG时间戳块（Gianluca Varenni要求< [email protected] >，CACE Technologies LLC） |
| 0x00000008 | AFDX封装信息块中的Arinc 429（Gianluca Varenni请求< [email protected] >，CACE Technologies LLC） |
| 0x0A0D0D0A | 部分标题块 |
| 0x0A0D0A00-0x0A0D0AFF | 保留。用于检测因文本模式下使用HTTP协议进行文件传输而损坏的跟踪文件。 |
| 0x000A0D0A-0xFF0A0D0A | 保留。用于检测因文本模式下使用HTTP协议进行文件传输而损坏的跟踪文件。 |
| 0x000A0D0D-0xFF0A0D0D | 保留。用于检测因文本模式下使用HTTP协议进行文件传输而损坏的跟踪文件。 |
| 0x0D0D0A00-0x0D0D0AFF | 保留。用于检测因文本模式下使用FTP协议进行文件传输而损坏的跟踪文件。 |
| TOC |
附录C.标准化链接类型代码
注意：我们应该决定是否要在此处或单独的文档中列出此列表。将此列表放在单独的文档中并描述每种不同链接类型的帧格式可能是有意义的，或者指定帧格式是公司的专有而非公开。有大量的封装实际上是模糊的和未指定的（甚至名称没有任何意义）。此外，我们应该决定是否要使用libpcap定义的* all * linktypes（LINKTYPE_XXX），或者只是它们的一部分，从而试图消除类似标题的大混乱和混乱。
以下是标准化链接类型代码的列表。
| 链接类型名称 | 链接类型代码 | 描述 |
|---|---|---|
| LINKTYPE_NULL | 0 | 没有链接层信息。使用此链路层保存的数据包包含一个原始L3数据包，前面是32位主机字节顺序AF_值，表示特定的L3类型。 |
| LINKTYPE_ETHERNET | 1 | D / I / X和802.3以太网 |
| LINKTYPE_EXP_ETHERNET | 2 | 实验性以太网（3Mb） |
| LINKTYPE_AX25 | 3 | 业余无线电AX.25 |
| LINKTYPE_PRONET | 4 | Proteon ProNET令牌环 |
| LINKTYPE_CHAOS | 五 | 混沌 |
| LINKTYPE_TOKEN_RING | 6 | IEEE 802网络 |
| LINKTYPE_ARCNET | 7 | ARCNET，带有BSD风格的标题 |
| LINKTYPE_SLIP | 8 | 串行线IP |
| LINKTYPE_PPP | 9 | 点对点协议 |
| LINKTYPE_FDDI | 10 | FDDI |
| LINKTYPE_PPP_HDLC | 50 | PPP类似HDLC的框架 |
| LINKTYPE_PPP_ETHER | 51 | NetBSD PPP-over-Ethernet |
| LINKTYPE_SYMANTEC_FIREWALL | 99 | Symantec Enterprise Firewall |
| LINKTYPE_ATM_RFC1483 | 100 | LLC / SNAP封装的ATM |
| LINKTYPE_RAW | 101 | 原始IP |
| LINKTYPE_SLIP_BSDOS | 102 | BSD / OS SLIP BPF头 |
| LINKTYPE_PPP_BSDOS | 103 | BSD / OS PPP BPF头 |
| LINKTYPE_C_HDLC | 104 | Cisco HDLC |
| LINKTYPE_IEEE802_11 | 105 | IEEE 802.11（无线） |
| LINKTYPE_ATM_CLIP | 106 | Linux经典IP over ATM |
| LINKTYPE_FRELAY | 107 | 帧中继 |
| LINKTYPE_LOOP | 108 | OpenBSD环回 |
| LINKTYPE_ENC | 109 | OpenBSD IPSEC enc |
| LINKTYPE_LANE8023 | 110 | ATM LANE + 802.3（保留供将来使用） |
| LINKTYPE_HIPPI | 111 | NetBSD HIPPI（保留供将来使用） |
| LINKTYPE_HDLC | 112 | NetBSD HDLC框架（保留供将来使用） |
| LINKTYPE_LINUX_SLL | 113 | Linux熟的套接字捕获 |
| LINKTYPE_LTALK | 114 | Apple LocalTalk硬件 |
| LINKTYPE_ECONET | 115 | 橡子Econet |
| LINKTYPE_IPFILTER | 116 | 保留用于OpenBSD ipfilter |
| LINKTYPE_PFLOG | 117 | OpenBSD DLT_PFLOG |
| LINKTYPE_CISCO_IOS | 118 | 用于思科内部使用 |
| LINKTYPE_PRISM_HEADER | 119 | 802.11 + Prism II监控模式 |
| LINKTYPE_AIRONET_HEADER | 120 | FreeBSD Aironet驱动程序的东西 |
| LINKTYPE_HHDLC | 121 | 保留给Siemens HiPath HDLC |
| LINKTYPE_IP_OVER_FC | 122 | RFC 2625 IP-over-Fibre Channel |
| LINKTYPE_SUNATM | 123 | 的Solaris + SunATM |
| LINKTYPE_RIO | 124 | RapidIO - 根据Kent Dahlgren < [email protected] >的要求保留供私人使用。 |
| LINKTYPE_PCI_EXP | 125 | PCI Express - 根据Kent Dahlgren < [email protected] >的要求保留供私人使用。 |
| LINKTYPE_AURORA | 126 | Xilinx Aurora链路层 - 根据Kent Dahlgren < [email protected] >的要求保留供私人使用。 |
| LINKTYPE_IEEE802_11_RADIO | 127 | 802.11 plus BSD无线电头 |
| LINKTYPE_TZSP | 128 | Tazmen Sniffer协议 - 根据Chris Waters的请求保留用于TZSP封装< [email protected] > TZSP是任何其他链路类型的通用封装，其中包括将数据包包含在元数据中的方法，例如802.11数据包的信号强度和信道。 |
| LINKTYPE_ARCNET_LINUX | 129 | Linux风格的标题 |
| LINKTYPE_JUNIPER_MLPPP | 130 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_MLFR | 131 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_ES | 132 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_GGSN | 133 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_MFR | 134 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_ATM2 | 135 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_SERVICES | 136 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_JUNIPER_ATM1 | 137 | 根据Hannes Gredler < [email protected] >的请求，Juniper专用数据链接类型。相应的DLT_s用于传递机箱内部元信息，如QOS配置文件等。 |
| LINKTYPE_APPLE_IP_OVER_IEEE1394 | 138 | Apple IP-over-IEEE 1394 cooked header |
| LINKTYPE_MTP2_WITH_PHDR | 139 | ??? |
| LINKTYPE_MTP2 | 140 | ??? |
| LINKTYPE_MTP3 | 141 | ??? |
| LINKTYPE_SCCP | 142 | ??? |
| LINKTYPE_DOCSIS | 143 | DOCSIS MAC帧 |
| LINKTYPE_LINUX_IRDA | 144 | Linux的红外线 |
| LINKTYPE_IBM_SP | 145 | 保留给IBM SP交换机和IBM Next Federation交换机。 |
| LINKTYPE_IBM_SN | 146 | 保留给IBM SP交换机和IBM Next Federation交换机。 |
| TOC |
附录D.链路层标头
分组块的分组数据字段不会以捕获的实际网络数据开始，而是以某些链路类型特定的“元数据”开始。此元数据的格式取决于所使用的链接类型。TODO：提及libpcap中列出这些链接头的示例代码。
| TOC |
作者的地址
| Loris Degioanni | |
| CACE Technologies | |
| 1949年第五街＃103 | |
| 戴维斯，加利福尼亚州95616 | |
| 美国 | |
| 电话： | +1 530 758 2790 |
| 电子邮件： | [email protected] |
| URI： | http://www.winpcap.org/loris/ |
| Fulvio Risso | |
| Politecnico di Torino | |
| Corso Duca degli Abruzzi，24岁 | |
| 都灵10129 | |
| 意大利 | |
| 电话： | +39 011 564 7008 |
| 电子邮件： | [email protected] |
| URI： | http://staff.polito.it/fulvio.risso/ |
| Gianluca Varenni | |
| CACE Technologies | |
| 1949年第五街＃103 | |
| 戴维斯，加利福尼亚州95616 | |
| 美国 | |
| 电话： | +1 530 758 2790 |
| 电子邮件： | [email protected] |
| URI： | http://www.winpcap.org/gianluca/ |
| TOC |
完整的版权声明
版权所有©互联网协会（2004年）。版权所有。
本文件及其翻译可以复制并提供给他人，可以编写，复制，发布和分发全部或部分不受任何限制的衍生作品，评论或解释或协助其实施。 ，但上述版权声明和本款包含在所有此类副本和衍生作品中。但是，本文档本身不得以任何方式进行修改，例如删除版权声明或对互联网协会或其他互联网组织的引用，除非为了开发互联网标准而需要，在这种情况下，版权的程序定义于必须遵循互联网标准流程，或根据需要将其翻译成英语以外的语言。
上述授予的有限权限是永久性的，不会被互联网协会或其继承人或受让人撤销。
本文档及其中包含的信息按“原样”提供，互联网协会和互联网工程任务部门不提供任何明示或暗示的担保，包括但不限于此处使用此类信息的任何担保。侵犯任何权利或任何暗示的适销性或适用于特定用途的保证。
知识产权
IETF对于可能声称与本文档中描述的技术的实现或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能或可能不是可用的; 它也不代表它已经做出任何努力来确定任何此类权利。有关IETF关于标准跟踪和标准相关文档权利的程序的信息可以在BCP 11中找到。权利主张的副本可供发布，可以提供任何许可证保证，或者尝试的结果可以从IETF秘书处获得本规范的实施者或用户获得使用此类所有权的一般许可或许可。
IETF邀请任何相关方提请其注意任何版权，专利或专利申请，或其他所有权，这些权利可涵盖实施此标准所需的技术。请将信息提供给IETF执行主任。
承认
RFC编辑功能的资金目前由互联网协会提供。
备注
最后附上pcapng与pcap抓对实例比图。