idnits 2.17.1 draft-tuexen-opsawg-pcapng-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 June 2021) is 1037 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen, Ed. 3 Internet-Draft Muenster Univ. of Appl. Sciences 4 Intended status: Informational F. Risso 5 Expires: 25 December 2021 Politecnico di Torino 6 J. Bongertz 7 Airbus DS CyberSecurity 8 G. Combs 9 Wireshark 10 G. Harris 12 E. Chaudron 13 Red Hat 14 M. Richardson 15 Sandelman 16 23 June 2021 18 PCAP Next Generation (pcapng) Capture File Format 19 draft-tuexen-opsawg-pcapng-03 21 Abstract 23 This document describes a format to record captured packets to a 24 file. This format is extensible; Wireshark can currently read and 25 write it, and libpcap can currently read some pcapng files. 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Discussion of this document takes place on the OPSAWG Working Group 32 mailing list (opsawg@ietf.org), which is archived at 33 https://mailarchive.ietf.org/arch/browse/opsawg/. 35 Source for this draft and an issue tracker can be found at 36 https://github.com/pcapng/pcapng. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 25 December 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. General File Structure . . . . . . . . . . . . . . . . . . . 4 75 3.1. General Block Structure . . . . . . . . . . . . . . . . . 4 76 3.2. Block Types . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.3. Logical Block Hierarchy . . . . . . . . . . . . . . . . . 7 78 3.4. Physical File Layout . . . . . . . . . . . . . . . . . . 8 79 3.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.5.1. Custom Options . . . . . . . . . . . . . . . . . . . 12 81 3.6. Data format . . . . . . . . . . . . . . . . . . . . . . . 13 82 3.6.1. Endianness . . . . . . . . . . . . . . . . . . . . . 13 83 3.6.2. Alignment . . . . . . . . . . . . . . . . . . . . . . 14 84 4. Block Definition . . . . . . . . . . . . . . . . . . . . . . 14 85 4.1. Section Header Block . . . . . . . . . . . . . . . . . . 14 86 4.2. Interface Description Block . . . . . . . . . . . . . . . 18 87 4.3. Enhanced Packet Block . . . . . . . . . . . . . . . . . . 25 88 4.3.1. Enhanced Packet Block Flags Word . . . . . . . . . . 30 89 4.4. Simple Packet Block . . . . . . . . . . . . . . . . . . . 31 90 4.5. Name Resolution Block . . . . . . . . . . . . . . . . . . 33 91 4.6. Interface Statistics Block . . . . . . . . . . . . . . . 37 92 4.7. systemd Journal Export Block . . . . . . . . . . . . . . 40 93 4.8. Decryption Secrets Block . . . . . . . . . . . . . . . . 41 94 4.9. Custom Block . . . . . . . . . . . . . . . . . . . . . . 45 95 5. Experimental Blocks (deserve further investigation) . . . . . 47 96 5.1. Alternative Packet Blocks (experimental) . . . . . . . . 47 97 5.2. Compression Block (experimental) . . . . . . . . . . . . 47 98 5.3. Encryption Block (experimental) . . . . . . . . . . . . . 48 99 5.4. Fixed Length Block (experimental) . . . . . . . . . . . . 49 100 5.5. Directory Block (experimental) . . . . . . . . . . . . . 50 101 5.6. Traffic Statistics and Monitoring Blocks 102 (experimental) . . . . . . . . . . . . . . . . . . . . . 50 103 5.7. Event/Security Block (experimental) . . . . . . . . . . . 50 104 6. Vendor-Specific Custom Extensions . . . . . . . . . . . . . . 50 105 6.1. Supported Use-Cases . . . . . . . . . . . . . . . . . . . 51 106 6.2. Controlling Copy Behavior . . . . . . . . . . . . . . . . 51 107 6.3. Strings vs. Octets . . . . . . . . . . . . . . . . . . . 52 108 6.4. Endianness Issues . . . . . . . . . . . . . . . . . . . . 52 109 7. Recommended File Name Extension: .pcapng . . . . . . . . . . 52 110 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 53 111 9. Implementations . . . . . . . . . . . . . . . . . . . . . . . 53 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 53 113 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 114 11.1. Standardized Block Type Codes . . . . . . . . . . . . . 53 115 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 116 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 117 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 118 14.1. Normative References . . . . . . . . . . . . . . . . . . 57 119 14.2. Informative References . . . . . . . . . . . . . . . . . 57 120 Appendix A. Packet Block (obsolete!) . . . . . . . . . . . . . . 57 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 123 1. Introduction 125 The problem of exchanging packet traces becomes more and more 126 critical every day; unfortunately, no standard solutions exist for 127 this task right now. One of the most accepted packet interchange 128 formats is the one defined by libpcap, which is rather old and is 129 lacking in functionality for more modern applications particularly 130 from the extensibility point of view. 132 This document proposes a new format for recording packet traces. The 133 following goals are being pursued: 135 Extensibility: It should be possible to add new standard 136 capabilities to the file format over time, and third parties 137 should be able to enrich the information embedded in the file with 138 proprietary extensions, with tools unaware of newer extensions 139 being able to ignore them. 141 Portability: A capture trace must contain all the information needed 142 to read data independently from network, hardware and operating 143 system of the machine that made the capture. 145 Merge/Append data: It should be possible to add data at the end of a 146 given file, and the resulting file must still be readable. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2.1. Acronyms 158 The following acronyms are used throughout this document: 160 SHB: Section Header Block 162 IDB: Interface Description Block 164 ISB: Interface Statistics Block 166 EPB: Enhanced Packet Block 168 SPB: Simple Packet Block 170 NRB: Name Resolution Block 172 CB: Custom Block 174 3. General File Structure 176 3.1. General Block Structure 178 A capture file is organized in blocks, that are appended one to 179 another to form the file. All the blocks share a common format, 180 which is shown in Figure 1. 182 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 0 | Block Type | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 4 | Block Total Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 8 / Block Body / 190 / variable length, padded to 32 bits / 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Block Total Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: Basic block structure. 197 The fields have the following meaning: 199 * Block Type (32 bits): a unique unsigned value that identifies the 200 block. Values whose Most Significant Bit (MSB) is equal to 1 are 201 reserved for local use. They can be used to make extensions to 202 the file format to save private data to the file. The list of 203 currently defined types can be found in Section 11.1. 205 * Block Total Length (32 bits): an unsigned value giving the total 206 size of this block, in octets. For instance, the length of a 207 block that does not have a body is 12 octets: 4 octets for the 208 Block Type, 4 octets for the initial Block Total Length and 4 209 octets for the trailing Block Total Length. This value MUST be a 210 multiple of 4. 212 * Block Body: content of the block. 214 * Block Total Length: total size of this block, in octets. This 215 field is duplicated to permit backward file navigation. 217 This structure, shared among all blocks, makes it easy to process a 218 file and to skip unneeded or unknown blocks. Some blocks can contain 219 other blocks inside (nested blocks). Some of the blocks are 220 mandatory, i.e. a capture file is not valid if they are not present, 221 other are optional. 223 The General Block Structure allows defining other blocks if needed. 224 A parser that does not understand them can simply ignore their 225 content. 227 3.2. Block Types 229 The currently standardized Block Type codes are specified in 230 Section 11.1; they have been grouped in the following four 231 categories: 233 The following MANDATORY block MUST appear at least once in each file: 235 * Section Header Block (Section 4.1): it defines the most important 236 characteristics of the capture file. 238 The following OPTIONAL blocks MAY appear in a file: 240 * Interface Description Block (Section 4.2): it defines the most 241 important characteristics of the interface(s) used for capturing 242 traffic. This block is required in certain cases, as described 243 later. 245 * Enhanced Packet Block (Section 4.3): it contains a single captured 246 packet, or a portion of it. It represents an evolution of the 247 original, now obsolete, Packet Block (Appendix A). If this 248 appears in a file, an Interface Description Block is also 249 required, before this block. 251 * Simple Packet Block (Section 4.4): it contains a single captured 252 packet, or a portion of it, with only a minimal set of information 253 about it. If this appears in a file, an Interface Description 254 Block is also required, before this block. 256 * Name Resolution Block (Section 4.5): it defines the mapping from 257 numeric addresses present in the packet capture and the canonical 258 name counterpart. 260 * Interface Statistics Block (Section 4.6): it defines how to store 261 some statistical data (e.g. packet dropped, etc) which can be 262 useful to understand the conditions in which the capture has been 263 made. If this appears in a file, an Interface Description Block 264 is also required, before this block. 266 * Custom Block (Section 4.9): it contains vendor-specific data in a 267 portable fashion. 269 The following OBSOLETE block SHOULD NOT appear in newly written files 270 (but is documented in the Appendix for reference): 272 * Packet Block (Appendix A): it contains a single captured packet, 273 or a portion of it. It is OBSOLETE, and superseded by the 274 Enhanced Packet Block (Section 4.3). 276 The following EXPERIMENTAL blocks are considered interesting but the 277 authors believe that they deserve more in-depth discussion before 278 being defined: 280 * Alternative Packet Blocks 282 * Compression Block 284 * Encryption Block 286 * Fixed Length Block 288 * Directory Block 290 * Traffic Statistics and Monitoring Blocks 292 * Event/Security Blocks 294 Requests for new standardized Block Type codes should be made by 295 creating a pull request to update this document as described in 296 Section 11.1. 298 3.3. Logical Block Hierarchy 300 The blocks build a logical hierarchy as they refer to each other. 301 Figure 2 shows the logical hierarchy of the currently defined blocks 302 in the form of a "tree view": 304 Section Header 305 | 306 +- Interface Description 307 | +- Simple Packet 308 | +- Enhanced Packet 309 | +- Interface Statistics 310 | 311 +- Name Resolution 313 Figure 2: Logical Block Hierarchy of a pcapng File 315 For example: each captured packet refers to a specific capture 316 interface, the interface itself refers to a specific section. 318 3.4. Physical File Layout 320 The file MUST begin with a Section Header Block. However, more than 321 one Section Header Block can be present in the capture file, each one 322 covering the data following it until the next one (or the end of 323 file). A Section includes the data delimited by two Section Header 324 Blocks (or by a Section Header Block and the end of the file), 325 including the first Section Header Block. 327 In case an application cannot read a Section because of different 328 version number, it MUST skip everything until the next Section Header 329 Block. Note that, in order to properly skip the blocks until the 330 next section, all blocks MUST have the fields Type and Length at the 331 beginning. In order to properly skip blocks in the backward 332 direction, all blocks MUST have the Length repeated at the end of the 333 block. These are mandatory requirements that MUST be maintained in 334 future versions of the block format. 336 Figure 3 shows a typical file layout, with a single Section Header 337 that covers the whole file. 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | SHB v1.0 | Data | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 3: File structure example: Typical layout with a single 344 Section Header Block 346 Figure 4 shows a file that contains three headers, and is normally 347 the result of file concatenation. An application that understands 348 only version 1.0 of the file format skips the intermediate section 349 and restart processing the packets after the third Section Header. 351 |-- 1st Section --|-- 2nd Section --|-- 3rd Section --| 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 4: File structure example: three Section Header Blocks in 358 a single file 360 Figure 5 shows a file comparable to a "classic libpcap" file - the 361 minimum for a useful capture file. It contains a single 362 Section Header Block (SHB), a single Interface Description Block 363 (IDB) and a few Enhanced Packet Blocks (EPB). 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | SHB | IDB | EPB | EPB | ... | EPB | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 5: File structure example: a pcapng file similar to a 370 classical libpcap file 372 Figure 6 shows a complex example file. In addition to the minimum 373 file above, it contains packets captured from three interfaces, 374 capturing on the third of which begins after packets have arrived on 375 other interfaces, and also includes some Name Resolution Blocks (NRB) 376 and an Interface Statistics Block (ISB). 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | SHB | IDB | IDB | EPB | NRB |...| IDB | EPB | ISB | NRB | EPB | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 6: File structure example: complex pcapng file 384 The last example should make it obvious that the block structure 385 makes the file format very flexible compared to the classical libpcap 386 format. 388 3.5. Options 390 All the block bodies MAY embed optional fields. Optional fields can 391 be used to insert some information that may be useful when reading 392 data, but that is not really needed for packet processing. 393 Therefore, each tool can either read the content of the optional 394 fields (if any), or skip some of them or even all at once. 396 A block that may contain options must be structured so that the 397 number of octets of data in the Block Body that precede the options 398 can be determined from that data; that allows the beginning of the 399 options to be found. That is true for all standard blocks that 400 support options; for Custom Blocks that support options, the Custom 401 Data must be structured in such a fashion. This means that the Block 402 Length field (present in the General Block Structure, see 403 Section 3.1) can be used to determine how many octets of optional 404 fields, if any, are present in the block. That number can be used to 405 determine whether the block has optional fields (if it is zero, there 406 are no optional fields), to check, when processing optional fields, 407 whether any optional fields remain, and to skip all the optional 408 fields at once. 410 Options are a list of Type - Length - Value fields, each one 411 containing a single value: 413 * Option Type (16 bits): an unsigned value that contains the code 414 that specifies the type of the current TLV record. Option types 415 whose Most Significant Bit is equal to one are reserved for local 416 use; therefore, there is no guarantee that the code used is unique 417 among all capture files (generated by other applications), and is 418 most certainly not portable. For cross-platform globally unique 419 vendor-specific extensions, the Custom Option MUST be used 420 instead, as defined in Section 3.5.1). 422 * Option Length (16 bits): an unsigned value that contains the 423 actual length of the following 'Option Value' field without the 424 padding octets. 426 * Option Value (variable length): the value of the given option, 427 padded to a 32-bit boundary. The actual length of this field 428 (i.e. without the padding octets) is specified by the Option 429 Length field. 431 Requests for new standardized option codes for a given block should 432 be made by creating a pull request to update this document as 433 described in Section 11.1. 435 A given option may have a fixed length, in which case all instances 436 of that option have a length that is equal to the specified fixed 437 length, or a variable length, in which case the option has a minimum 438 length and all instances of that option must have a length equal to 439 or greater than the specified minimum length. The length of fixed- 440 length options, and the minimum length of variable-length options, is 441 specified in the description of the option; if the minimum length of 442 a variable-length option is not specified, a zero-length option is 443 valid. Software that reads these files SHOULD report options that 444 have an invalid length as errors; the software MAY stop processing 445 the file if it sees an option that has invalid length, or MAY ignore 446 the option and continue processing it. Software that writes these 447 files MUST NOT write files with options that have invalid lengths. 449 If an option's value is a string, the value is not necessarily zero- 450 terminated. Software that reads these files MUST NOT assume that 451 strings are zero-terminated, and MUST treat a zero-value octet as a 452 string terminator. 454 Some options may be repeated several times; for example, a block can 455 have multiple comments, and an Interface Description Block can give 456 multiple IPv4 or IPv6 addresses for the interface if it has multiple 457 IPv4 or IPv6 addresses assigned to it. Other options may appear at 458 most once in a given block. 460 The option list is terminated by a option which uses the special 'End 461 of Option' code (opt_endofopt). Code that writes pcapng files MUST 462 put an opt_endofopt option at the end of an option list. Code that 463 reads pcapng files MUST NOT assume an option list will have an 464 opt_endofopt option at the end; it MUST also check for the end of the 465 block, and SHOULD treat blocks where the option list has no 466 opt_endofopt option as if the option list had an opt_endofopt option 467 at the end. 469 The format of the optional fields is shown in Figure 7. 471 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Option Code | Option Length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 / Option Value / 477 / variable length, padded to 32 bits / 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 / / 480 / . . . other options . . . / 481 / / 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Option Code == opt_endofopt | Option Length == 0 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 7: Options Format 488 The following codes can always be present in any optional field: 490 +==============+=======================+===========+==========+ 491 | Name | Code | Length | Multiple | 492 | | | | allowed? | 493 +==============+=======================+===========+==========+ 494 | opt_endofopt | 0 | 0 | no | 495 +--------------+-----------------------+-----------+----------+ 496 | opt_comment | 1 | variable | yes | 497 +--------------+-----------------------+-----------+----------+ 498 | opt_custom | 2988/2989/19372/19373 | variable, | yes | 499 | | | minimum 4 | | 500 +--------------+-----------------------+-----------+----------+ 502 Table 1: Common Options 504 opt_endofopt: 505 The opt_endofopt option delimits the end of the optional 506 fields. This option MUST NOT be repeated within a given list 507 of options. 509 opt_comment: 510 The opt_comment option is a UTF-8 string containing human- 511 readable comment text that is associated to the current 512 block. Line separators SHOULD be a carriage-return + 513 linefeed ('\r\n') or just linefeed ('\n'); either form may 514 appear and be considered a line separator. The string is not 515 zero-terminated. 517 Examples: "This packet is the beginning of all of our problems", 518 "Packets 17-23 showing a bogus TCP retransmission!\r\n This is 519 reported in bugzilla entry 1486.\nIt will be fixed in the future.". 521 opt_custom: 522 This option is described in detail in Section 3.5.1. 524 3.5.1. Custom Options 526 Customs Options are used for portable, vendor-specific data related 527 to the block they're in. A Custom Option can be in any block type 528 that can have options, can be repeated any number of times in a 529 block, and may come before or after other option types - except the 530 opt_endofopt option, which is always the last option. Different 531 Custom Options, of different type codes and/or different Private 532 Enterprise Numbers, may be used in the same pcapng file. See 533 Section 6 for additional details. 535 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Custom Option Code | Option Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Private Enterprise Number (PEN) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 / Custom Data / 543 / variable length, padded to 32 bits / 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 8: Custom Options Format 548 The Custom Option has the following fields: 550 * Custom Option Code: The code number for the Custom Option, which 551 can be one of the following decimal numbers: 553 2988: 554 This option code identifies a Custom Option containing a 555 UTF-8 string in the Custom Data portion. The string is 556 not zero-terminated. This Custom Option can be safely 557 copied to a new file if the pcapng file is manipulated by 558 an application; otherwise 19372 should be used instead. 559 See Section 6.2 for details. 561 2989: 562 This option code identifies a Custom Option containing 563 binary octets in the Custom Data portion. This Custom 564 Option can be safely copied to a new file if the pcapng 565 file is manipulated by an application; otherwise 19372 566 should be used instead. See Section 6.2 for details. 568 19372: 569 This option code identifies a Custom Option containing a 570 UTF-8 string in the Custom Data portion. The string is 571 not zero-terminated. This Custom Option should not be 572 copied to a new file if the pcapng file is manipulated by 573 an application. See Section 6.2 for details. 575 19373: 576 This option code identifies a Custom Option containing 577 binary octets in the Custom Data portion. This Custom 578 Option should not be copied to a new file if the pcapng 579 file is manipulated by an application. See Section 6.2 580 for details. 582 * Option Length: as described in Section 3.1, this contains the 583 length of the option's value, which includes the 4-octet Private 584 Enterprise Number and variable-length Custom Data fields, without 585 the padding octets. 587 * Private Enterprise Number: An IANA-assigned Private Enterprise 588 Number identifying the organization which defined the Custom 589 Option. See Section 6.1 for details. The PEN number MUST be 590 encoded using the same endianness as the Section Header Block it 591 is within the scope of. 593 * Custom Data: the custom data, padded to a 32 bit boundary. 595 3.6. Data format 597 3.6.1. Endianness 599 Data contained in each section will always be saved according to the 600 characteristics (little endian / big endian) of the capturing 601 machine. This refers to all the fields that are saved as numbers and 602 that span over two or more octets. 604 The approach of having each section saved in the native format of the 605 generating host is more efficient because it avoids translation of 606 data when reading / writing on the host itself, which is the most 607 common case when generating/processing capture captures. 609 Please note: The endianness is indicated by the Section Header Block 610 (Section 4.1). Since this block can appear several times in a pcapng 611 file, a single file can contain both endianness variants. 613 3.6.2. Alignment 615 All fields of this specification use proper alignment for 16- and 616 32-bit values. This makes it easier and faster to read/write file 617 contents if using techniques like memory mapped files. 619 The alignment octets (marked in this document e.g. with "padded to 32 620 bits") MUST be filled with zeroes. 622 Please note: 64-bit values are not aligned to 64-bit boundaries. 623 This is because the file is naturally aligned to 32-bit boundaries 624 only. Special care MUST be taken when reading and writing such 625 values. (Note also that some 64-bit values are represented as a 626 64-bit integer in the endianness of the machine that wrote the file, 627 and others are represented as 2 32-bit values, one containing the 628 upper 32 bits of the value and one containing the lower 32 bits of 629 the value, each written as 32-bit integers in the endianness of the 630 machine that wrote the file. Neither of these formats guarantee 631 64-bit alignment.) 633 4. Block Definition 635 This section details the format of the blocks currently defined. 637 4.1. Section Header Block 639 The Section Header Block (SHB) is mandatory. It identifies the 640 beginning of a section of the capture file. The Section Header Block 641 does not contain data but it rather identifies a list of blocks 642 (interfaces, packets) that are logically correlated. Its format is 643 shown in Figure 9. 645 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 0 | Block Type = 0x0A0D0D0A | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 4 | Block Total Length | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 8 | Byte-Order Magic | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 12 | Major Version | Minor Version | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 16 | | 657 | Section Length | 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 24 / / 661 / Options (variable) / 662 / / 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Block Total Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 9: Section Header Block Format 669 The meaning of the fields is: 671 * Block Type: The block type of the Section Header Block is the 672 integer corresponding to the 4-char string "\n\r\r\n" 673 (0x0A0D0D0A). This particular value is used for 2 reasons: 675 1. This number is used to detect if a file has been transferred 676 via FTP or HTTP from a machine to another with an 677 inappropriate ASCII conversion. In this case, the value of 678 this field will differ from the standard one ("\n\r\r\n") and 679 the reader can detect a possibly corrupted file. 681 2. This value is palindromic, so that the reader is able to 682 recognize the Section Header Block regardless of the 683 endianness of the section. The endianness is recognized by 684 reading the Byte Order Magic, which is located 8 octets after 685 the Block Type. 687 * Block Total Length: total size of this block, as described in 688 Section 3.1. 690 * Byte-Order Magic (32 bits): an unsigned magic number, whose value 691 is the hexadecimal number 0x1A2B3C4D. This number can be used to 692 distinguish sections that have been saved on little-endian 693 machines from the ones saved on big-endian machines, and to 694 heuristically identify pcapng files. 696 * Major Version (16 bits): an unsigned value, giving the number of 697 the current major version of the format. The value for the 698 current version of the format is 1. 700 * Minor Version (16 bits): an unsigned value, giving the number of 701 the current minor version of the format. The value for the 702 current version of the format is 0. 704 * Section Length (64 bits): a signed value specifying the length in 705 octets of the following section, excluding the Section Header 706 Block itself. This field can be used to skip the section, for 707 faster navigation inside large files. If the Section Length is -1 708 (0xFFFFFFFFFFFFFFFF), this means that the size of the section is 709 not specified, and the only way to skip the section is to parse 710 the blocks that it contains. Please note that if this field is 711 valid (i.e. not negative), its value is always a multiple of 4, as 712 all the blocks are aligned to and padded to 32-bit (4 octet) 713 boundaries. Also, special care should be taken in accessing this 714 field: since the alignment of all the blocks in the file is 715 32-bits, this field is not guaranteed to be aligned to a 64-bit 716 boundary. This could be a problem on 64-bit processors. 718 * Options: optionally, a list of options (formatted according to the 719 rules defined in Section 3.5) can be present. 721 Writers of pcapng files MUST NOT write SHBs with a Major Version 722 other than 1 or a Minor Version other than 0. If they do so, they 723 will write a file that many readers of pcapng files, such as programs 724 using libpcap to read pcapng files (including, but not limited to, 725 tcpdump), Wireshark, and possibly other programs not to be able to 726 read their files. 728 Some pcapng file writers have used a minor version of 2, but the file 729 format did not change incompatibly (new block types were added); 730 Readers of pcapng files MUST treat a Minor Version of 2 as equivalent 731 to a Minor Version of 0 (and, if they also write a pcapng file based 732 on the results of reading one or more pcapng files, they MUST NOT, as 733 per the previous sentence, write an SHB with a Minor Version of 2, 734 even if they read an SHB with a Minor Version of 2). As indicated 735 above, using a minor version number other than 0 when writing a 736 section of a pcapng file will produce a section that most existing 737 software will not be able to read; future versions of some of that 738 software will be able to read sections with a version of 1.2, but 739 older copies of that software that are not updated to the latest 740 version will still not be able to read them. 742 The Major Version would be changed only if a new version of this 743 specification, for a later major version of the file format, were 744 created. Such a version would only be created if the format were to 745 change in such a way that code that reads the new format could not 746 read the old format (i.e., code to read both formats would have to 747 check the version number and use different code paths for the two 748 formats) and code that reads the old format could not read the new 749 format. An incompatible change to the format of an existing block or 750 an existing option would be such a change; the addition of a new 751 block or a new option would not be such a change. An example of such 752 an incomparible change would be the addition of an additional field 753 to the Section Header Block, following the Minor Version field and 754 before the Snaplen field; software expecting the new SHB format would 755 not correctly read the old SHB format, and software expecting the old 756 SHB format would not correctly read the new SHB format. (Note that a 757 change to the SHB must leave the Block Type, Block Total Length, 758 Byte-Order Magic, Major Version, and Minor Version fields at the same 759 offsets from the beginning of the SHB and with the same lengths, must 760 keep the value of the Block TYpe the same, must keep the two 761 posssible values of the Byte-Order Magic the same, depending on the 762 block's byte order, so that the rest of the SHB can be correctly 763 interpreted.) 765 The Minor Version would be changed only if a new version of this 766 specification, for a later minor version of the file format, were 767 created. Such a version would only be created if the format were to 768 change in such a way that code that reads the new format could read 769 the old format without checking the version number but code that 770 reads the old format could not read all files in the new format. A 771 backward-compatible change to the format of an existing block or an 772 existing opption would be such a change; the addition of a new block 773 or a new option would not be such a change. An example of such a 774 backward-compatible but not forward-compatible change would be a 775 change to the Interface Description block (see below) to use the 776 current Reserved field to indicate the presence of additional fields 777 before the Options, with a zero value indicate no such fields are 778 present. 780 I.e., adding new block types or options would not require that either 781 the Major Version or the Minor Version be changed, as code that does 782 not know about the block type or option should just skip it; only if 783 skipping a block or option does not work should the minor version 784 number be changed. 786 Aside from the options defined in Section 3.5, the following options 787 are valid within this block: 789 +==============+======+==========+===================+ 790 | Name | Code | Length | Multiple allowed? | 791 +==============+======+==========+===================+ 792 | shb_hardware | 2 | variable | no | 793 +--------------+------+----------+-------------------+ 794 | shb_os | 3 | variable | no | 795 +--------------+------+----------+-------------------+ 796 | shb_userappl | 4 | variable | no | 797 +--------------+------+----------+-------------------+ 799 Table 2: Section Header Block Options 801 shb_hardware: 802 The shb_hardware option is a UTF-8 string containing the 803 description of the hardware used to create this section. The 804 string is not zero-terminated. 806 Examples: "x86 Personal Computer", "Sun Sparc Workstation". 808 shb_os: 809 The shb_os option is a UTF-8 string containing the name of 810 the operating system used to create this section. The string 811 is not zero-terminated. 813 Examples: "Windows XP SP2", "openSUSE 10.2". 815 shb_userappl: 816 The shb_userappl option is a UTF-8 string containing the name 817 of the application used to create this section. The string 818 is not zero-terminated. 820 Examples: "dumpcap V0.99.7". 822 [Open issue: does a program which re-writes a capture file change the 823 original hardware/os/application info?] 825 4.2. Interface Description Block 827 An Interface Description Block (IDB) is the container for information 828 describing an interface on which packet data is captured. 830 Tools that write / read the capture file associate an incrementing 831 unsigned 32-bit number (starting from '0') to each Interface 832 Definition Block, called the Interface ID for the interface in 833 question. This number is unique within each Section and identifies 834 the interface to which the IDB refers; it is only unique inside the 835 current section, so, two Sections can have different interfaces 836 identified by the same Interface ID values. This unique identifier 837 is referenced by other blocks, such as Enhanced Packet Blocks and 838 Interface Statistic Blocks, to indicate the interface to which the 839 block refers (such the interface that was used to capture the packet 840 that an Enhanced Packet Block contains or to which the statistics in 841 an Interface Statistic Block refer). 843 There must be an Interface Description Block for each interface to 844 which another block refers. Blocks such as an Enhanced Packet Block 845 or an Interface Statistics Block contain an Interface ID value 846 referring to a particular interface, and a Simple Packet Block 847 implicitly refers to an interface with an Interface ID of 0. If the 848 file does not contain any blocks that use an Interface ID, then the 849 file does not need to have any IDBs. 851 An Interface Description Block is valid only inside the section to 852 which it belongs. The structure of a Interface Description Block is 853 shown in Figure 10. 855 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 0 | Block Type = 0x00000001 | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 4 | Block Total Length | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 8 | LinkType | Reserved | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 12 | SnapLen | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 16 / / 867 / Options (variable) / 868 / / 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Block Total Length | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Figure 10: Interface Description Block Format 875 The meaning of the fields is: 877 * Block Type: The block type of the Interface Description Block is 878 1. 880 * Block Total Length: total size of this block, as described in 881 Section 3.1. 883 * LinkType (16 bits): an unsigned value that defines the link layer 884 type of this interface. The list of Standardized Link Layer Type 885 codes is available in [LINKTYPES]. 887 * Reserved (16 bits): not used - MUST be filled with 0 by pcapng 888 file writers, and MUST be ignored by pcapng file readers. 890 * SnapLen (32 bits): an unsigned value indicating the maximum number 891 of octets captured from each packet. The portion of each packet 892 that exceeds this value will not be stored in the file. A value 893 of zero indicates no limit. 895 * Options: optionally, a list of options (formatted according to the 896 rules defined in Section 3.5) can be present. 898 In addition to the options defined in Section 3.5, the following 899 options are valid within this block: 901 +================+======+=====================+===================+ 902 | Name | Code | Length | Multiple allowed? | 903 +================+======+=====================+===================+ 904 | if_name | 2 | variable | no | 905 +----------------+------+---------------------+-------------------+ 906 | if_description | 3 | variable | no | 907 +----------------+------+---------------------+-------------------+ 908 | if_IPv4addr | 4 | 8 | yes | 909 +----------------+------+---------------------+-------------------+ 910 | if_IPv6addr | 5 | 17 | yes | 911 +----------------+------+---------------------+-------------------+ 912 | if_MACaddr | 6 | 6 | no | 913 +----------------+------+---------------------+-------------------+ 914 | if_EUIaddr | 7 | 8 | no | 915 +----------------+------+---------------------+-------------------+ 916 | if_speed | 8 | 8 | no | 917 +----------------+------+---------------------+-------------------+ 918 | if_tsresol | 9 | 1 | no | 919 +----------------+------+---------------------+-------------------+ 920 | if_tzone | 10 | 4 | no | 921 +----------------+------+---------------------+-------------------+ 922 | if_filter | 11 | variable, minimum 1 | no | 923 +----------------+------+---------------------+-------------------+ 924 | if_os | 12 | variable | no | 925 +----------------+------+---------------------+-------------------+ 926 | if_fcslen | 13 | 1 | no | 927 +----------------+------+---------------------+-------------------+ 928 | if_tsoffset | 14 | 8 | no | 929 +----------------+------+---------------------+-------------------+ 930 | if_hardware | 15 | variable | no | 931 +----------------+------+---------------------+-------------------+ 932 | if_txspeed | 16 | 8 | no | 933 +----------------+------+---------------------+-------------------+ 934 | if_rxspeed | 17 | 8 | no | 935 +----------------+------+---------------------+-------------------+ 937 Table 3: Interface Description Block Options 939 if_name: 940 The if_name option is a UTF-8 string containing the name of 941 the device used to capture data. The string is not zero- 942 terminated. 944 Examples: "eth0", 945 "\Device\NPF_{AD1CE675-96D0-47C5-ADD0-2504B9126B68}". 947 if_description: 949 The if_description option is a UTF-8 string containing the 950 description of the device used to capture data. The string 951 is not zero-terminated. 953 Examples: "Wi-Fi", "Local Area Connection", "Wireless Network 954 Connection", "First Ethernet Interface". 956 if_IPv4addr: 957 The if_IPv4addr option is an IPv4 network address and 958 corresponding netmask for the interface. The first four 959 octets are the IP address, and the next four octets are the 960 netmask. This option can be repeated multiple times within 961 the same Interface Description Block when multiple IPv4 962 addresses are assigned to the interface. Note that the IP 963 address and netmask are both treated as four octets, one for 964 each octet of the address or mask; they are not 32-bit 965 numbers, and thus the endianness of the SHB does not affect 966 this field's value. 968 Examples: '192 168 1 1 255 255 255 0'. 970 if_IPv6addr: 971 The if_IPv6addr option is an IPv6 network address and 972 corresponding prefix length for the interface. The first 16 973 octets are the IP address and the next octet is the prefix 974 length. This option can be repeated multiple times within 975 the same Interface Description Block when multiple IPv6 976 addresses are assigned to the interface. 978 Example: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344/64 is written (in 979 hex) as '20 01 0d b8 85 a3 08 d3 13 19 8a 2e 03 70 73 44 40'. 981 if_MACaddr: 982 The if_MACaddr option is the Interface Hardware MAC address 983 (48 bits), if available. 985 Example: '00 01 02 03 04 05'. 987 if_EUIaddr: 988 The if_EUIaddr option is the Interface Hardware EUI address 989 (64 bits), if available. 991 Example: '02 34 56 FF FE 78 9A BC'. 993 if_speed: 994 The if_speed option is a 64-bit unsigned value indicating the 995 interface speed, in bits per second. 997 Example: the 64-bit decimal number 100000000 for 100Mbps. 999 if_tsresol: 1000 The if_tsresol option identifies the resolution of 1001 timestamps. If the Most Significant Bit is equal to zero, 1002 the remaining bits indicates the resolution of the timestamp 1003 as a negative power of 10 (e.g. 6 means microsecond 1004 resolution, timestamps are the number of microseconds since 1005 1970-01-01 00:00:00 UTC). If the Most Significant Bit is 1006 equal to one, the remaining bits indicates the resolution as 1007 negative power of 2 (e.g. 10 means 1/1024 of second). If 1008 this option is not present, a resolution of 10^-6 is assumed 1009 (i.e. timestamps have the same resolution of the standard 1010 'libpcap' timestamps). 1012 Example: '6'. 1014 if_tzone: 1015 The if_tzone option identifies the time zone for GMT support 1016 (TODO: specify better). 1018 Example: TODO: give a good example. 1020 if_filter: 1021 The if_filter option identifies the filter (e.g. "capture 1022 only TCP traffic") used to capture traffic. The first octet 1023 of the Option Data keeps a code of the filter used (e.g. if 1024 this is a libpcap string, or BPF bytecode, and more). More 1025 details about this format will be presented in Appendix XXX 1026 (TODO). (TODO: better use different options for different 1027 fields? e.g. if_filter_pcap, if_filter_bpf, ...) 1029 Example: '00'"tcp port 23 and host 192.0.2.5". 1031 if_os: 1032 The if_os option is a UTF-8 string containing the name of the 1033 operating system of the machine in which this interface is 1034 installed. This can be different from the same information 1035 that can be contained by the Section Header Block 1036 (Section 4.1) because the capture can have been done on a 1037 remote machine. The string is not zero-terminated. 1039 Examples: "Windows XP SP2", "openSUSE 10.2". 1041 if_fcslen: 1042 The if_fcslen option is an 8-bit unsigned integer value that 1043 specifies the length of the Frame Check Sequence (in bits) 1044 for this interface. For link layers whose FCS length can 1045 change during time, the Enhanced Packet Block epb_flags 1046 Option can be used in each Enhanced Packet Block (see 1047 Section 4.3.1). 1049 Example: '4'. 1051 if_tsoffset: 1052 The if_tsoffset option is a 64-bit signed integer value that 1053 specifies an offset (in seconds) that must be added to the 1054 timestamp of each packet to obtain the absolute timestamp of 1055 a packet. If the option is missing, the timestamps stored in 1056 the packet MUST be considered absolute timestamps. The time 1057 zone of the offset can be specified with the option if_tzone. 1058 TODO: won't a if_tsoffset_low for fractional second offsets 1059 be useful for highly synchronized capture systems? 1061 Example: '1234'. 1063 if_hardware: 1064 The if_hardware option is a UTF-8 string containing the 1065 description of the interface hardware. The string is not 1066 zero-terminated. 1068 Examples: "Broadcom NetXtreme", "Intel(R) PRO/1000 MT Network 1069 Connection", "NETGEAR WNA1000Mv2 N150 Wireless USB Micro Adapter". 1071 if_txspeed: 1072 The if_txrxspeeds option is a 64-bit unsigned value 1073 indicating the interface transmit speed in bits per second. 1075 Example: the 64-bit decimal number 1024000 for 1024Kbps. 1077 if_rxspeed: 1078 The if_rxspeed option is a 64-bit unsigned value indicating 1079 the interface receive speed, in bits per second. 1081 Example: the 64-bit decimal number 8192000 for 8192Kbps. 1083 If the interface transmit speed and receive speed are the same, the 1084 if_speed option MUST be used and the if_txspeed and if_rxspeed 1085 options MUST NOT be used. If the transmit speed is unknown, the 1086 if_speed and if_txspeed options MUST NOT be used; if the receive 1087 speed is unknown, the if_speed and if_rxspeed options MUST NOT be 1088 used. 1090 4.3. Enhanced Packet Block 1092 An Enhanced Packet Block (EPB) is the standard container for storing 1093 the packets coming from the network. The Enhanced Packet Block is 1094 optional because packets can be stored either by means of this block 1095 or the Simple Packet Block, which can be used to speed up capture 1096 file generation; or a file may have no packets in it. The format of 1097 an Enhanced Packet Block is shown in Figure 11. 1099 The Enhanced Packet Block is an improvement over the original, now 1100 obsolete, Packet Block (Appendix A): 1102 * it stores the Interface Identifier as a 32-bit integer value. 1103 This is a requirement when a capture stores packets coming from a 1104 large number of interfaces; 1106 * unlike the Packet Block (Appendix A), the number of packets 1107 dropped by the capture system between this packet and the previous 1108 one is not stored in the header, but rather in an option of the 1109 block itself. 1111 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 0 | Block Type = 0x00000006 | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 4 | Block Total Length | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 8 | Interface ID | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 12 | Timestamp (High) | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 16 | Timestamp (Low) | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 20 | Captured Packet Length | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 24 | Original Packet Length | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 28 / / 1129 / Packet Data / 1130 / variable length, padded to 32 bits / 1131 / / 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 / / 1134 / Options (variable) / 1135 / / 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Block Total Length | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 Figure 11: Enhanced Packet Block Format 1142 The Enhanced Packet Block has the following fields: 1144 * Block Type: The block type of the Enhanced Packet Block is 6. 1146 * Block Total Length: total size of this block, as described in 1147 Section 3.1. 1149 * Interface ID (32 bits): an unsigned value that specifies the 1150 interface on which this packet was received or transmitted; the 1151 correct interface will be the one whose Interface Description 1152 Block (within the current Section of the file) is identified by 1153 the same number (see Section 4.2) of this field. The interface ID 1154 MUST be valid, which means that an matching interface description 1155 block MUST exist. 1157 * Timestamp (High) and Timestamp (Low): upper 32 bits and lower 32 1158 bits of a 64-bit timestamp. The timestamp is a single 64-bit 1159 unsigned integer that represents the number of units of time that 1160 have elapsed since 1970-01-01 00:00:00 UTC. The length of a unit 1161 of time is specified by the 'if_tsresol' option (see Figure 10) of 1162 the Interface Description Block referenced by this packet. Note 1163 that, unlike timestamps in the libpcap file format, timestamps in 1164 Enhanced Packet Blocks are not saved as two 32-bit values that 1165 represent the seconds and microseconds that have elapsed since 1166 1970-01-01 00:00:00 UTC. Timestamps in Enhanced Packet Blocks are 1167 saved as two 32-bit words that represent the upper and lower 32 1168 bits of a single 64-bit quantity. 1170 * Captured Packet Length (32 bits): an unsigned value that indicates 1171 the number of octets captured from the packet (i.e. the length of 1172 the Packet Data field). It will be the minimum value among the 1173 Original Packet Length and the snapshot length for the interface 1174 (SnapLen, defined in Figure 10). The value of this field does not 1175 include the padding octets added at the end of the Packet Data 1176 field to align the Packet Data field to a 32-bit boundary. 1178 * Original Packet Length (32 bits): an unsigned value that indicates 1179 the actual length of the packet when it was transmitted on the 1180 network. It can be different from the Captured Packet Length if 1181 the packet has been truncated by the capture process. 1183 * Packet Data: the data coming from the network, including link- 1184 layer headers. The actual length of this field is Captured Packet 1185 Length plus the padding to a 32-bit boundary. The format of the 1186 link-layer headers depends on the LinkType field specified in the 1187 Interface Description Block (see Section 4.2) and it is specified 1188 in the entry for that format in [LINKTYPES]. 1190 * Options: optionally, a list of options (formatted according to the 1191 rules defined in Section 3.5) can be present. 1193 In addition to the options defined in Section 3.5, the following 1194 options are valid within this block: 1196 +===============+======+========================+===================+ 1197 | Name | Code | Length | Multiple | 1198 | | | | allowed? | 1199 +===============+======+========================+===================+ 1200 | epb_flags | 2 | 4 | no | 1201 +---------------+------+------------------------+-------------------+ 1202 | epb_hash | 3 | variable, minimum hash | yes | 1203 | | | type-dependent | | 1204 +---------------+------+------------------------+-------------------+ 1205 | epb_dropcount | 4 | 8 | no | 1206 +---------------+------+------------------------+-------------------+ 1207 | epb_packetid | 5 | 8 | no | 1208 +---------------+------+------------------------+-------------------+ 1209 | epb_queue | 6 | 4 | no | 1210 +---------------+------+------------------------+-------------------+ 1211 | epb_verdict | 7 | variable, minimum | yes | 1212 | | | verdict type-dependent | | 1213 +---------------+------+------------------------+-------------------+ 1215 Table 4: Enhanced Packet Block Options 1217 epb_flags: 1218 The epb_flags option is a 32-bit flags word containing link- 1219 layer information. A complete specification of the allowed 1220 flags can be found in Section 4.3.1. 1222 Example: '0'. 1224 epb_hash: 1225 The epb_hash option contains a hash of the packet. The first 1226 octet specifies the hashing algorithm, while the following 1227 octets contain the actual hash, whose size depends on the 1228 hashing algorithm, and hence from the value in the first 1229 octet. The hashing algorithm can be: 2s complement 1230 (algorithm octet = 0, size = XXX), XOR (algorithm octet = 1, 1231 size=XXX), CRC32 (algorithm octet = 2, size = 4), MD-5 1232 (algorithm octet = 3, size = 16), SHA-1 (algorithm octet = 4, 1233 size = 20), Toeplitz (algorithm octet = 5, size = 4). The 1234 hash covers only the packet, not the header added by the 1235 capture driver: this gives the possibility to calculate it 1236 inside the network card. The hash allows easier comparison/ 1237 merging of different capture files, and reliable data 1238 transfer between the data acquisition system and the capture 1239 library. 1241 Examples: '02 EC 1D 87 97', '03 45 6E C2 17 7C 10 1E 3C 2E 99 6E C2 1242 9A 3D 50 8E'. 1244 epb_dropcount: 1245 The epb_dropcount option is a 64-bit unsigned integer value 1246 specifying the number of packets lost (by the interface and 1247 the operating system) between this packet and the preceding 1248 one for the same interface or, for the first packet for an 1249 interface, between this packet and the start of the capture 1250 process. 1252 Example: '0'. 1254 epb_packetid: 1255 The epb_packetid option is a 64-bit unsigned integer that 1256 uniquely identifies the packet. If the same packet is seen 1257 by multiple interfaces and there is a way for the capture 1258 application to correlate them, the same epb_packetid value 1259 must be used. An example could be a router that captures 1260 packets on all its interfaces in both directions. When a 1261 packet hits interface A on ingress, an EPB entry gets 1262 created, TTL gets decremented, and right before it egresses 1263 on interface B another EPB entry gets created in the trace 1264 file. In this case, two packets are in the capture file, 1265 which are not identical but the epb_packetid can be used to 1266 correlate them. 1268 Example: '0'. 1270 epb_queue: 1271 The epb_queue option is a 32-bit unsigned integer that 1272 identifies on which queue of the interface the specific 1273 packet was received. 1275 Example: '0'. 1277 epb_verdict: 1278 The epb_verdict option stores a verdict of the packet. The 1279 verdict indicates what would be done with the packet after 1280 processing it. For example, a firewall could drop the 1281 packet. This verdict can be set by various components, i.e. 1282 Hardware, Linux's eBPF TC or XDP framework, etc. etc. The 1283 first octet specifies the verdict type, while the following 1284 octets contain the actual verdict data, whose size depends on 1285 the verdict type, and hence from the value in the first 1286 octet. The verdict type can be: Hardware (type octet = 0, 1287 size = variable), Linux_eBPF_TC (type octet = 1, size = 8 1288 (64-bit unsigned integer), value = TC_ACT_* as defined in the 1289 Linux pck_cls.h (https://git.kernel.org/pub/scm/linux/kernel/ 1290 git/torvalds/linux.git/tree/include/uapi/linux/pkt_cls.h) 1291 include), Linux_eBPF_XDP (type octet = 2, size = 8 (64-bit 1292 unsigned integer), value = xdp_action as defined in the Linux 1293 pbf.h (https://git.kernel.org/pub/scm/linux/kernel/git/torval 1294 ds/linux.git/tree/include/uapi/linux/bpf.h) include). 1296 Example: '02 00 00 00 00 00 00 00 02' for Linux_eBPF_XDP with verdict 1297 XDP_PASS. 1299 4.3.1. Enhanced Packet Block Flags Word 1301 The Enhanced Packet Block Flags Word is a 32-bit value that contains 1302 link-layer information about the packet. 1304 The word is encoded as an unsigned 32-bit integer, using the 1305 endianness of the Section Header Block scope it is in. In the 1306 following table, the bits are numbered with 0 being the least- 1307 significant bit and 31 being the most-significant bit of the 32-bit 1308 unsigned integer. The meaning of the bits is the following: 1310 +========+======================================================+ 1311 | Bit | Description | 1312 | Number | | 1313 +========+======================================================+ 1314 | 0-1 | Inbound / Outbound packet (00 = information not | 1315 | | available, 01 = inbound, 10 = outbound) | 1316 +--------+------------------------------------------------------+ 1317 | 2-4 | Reception type (000 = not specified, 001 = unicast, | 1318 | | 010 = multicast, 011 = broadcast, 100 = | 1319 | | promiscuous). | 1320 +--------+------------------------------------------------------+ 1321 | 5-8 | FCS length, in octets (0000 if this information is | 1322 | | not available). This value overrides the if_fcslen | 1323 | | option of the Interface Description Block, and is | 1324 | | used with those link layers (e.g. PPP) where the | 1325 | | length of the FCS can change during time. | 1326 +--------+------------------------------------------------------+ 1327 | 9-15 | Reserved (MUST be set to zero). | 1328 +--------+------------------------------------------------------+ 1329 | 16-31 | link-layer-dependent errors (Bit 31 = symbol error, | 1330 | | Bit 30 = preamble error, Bit 29 = Start Frame | 1331 | | Delimiter error, Bit 28 = unaligned frame error, Bit | 1332 | | 27 = wrong Inter Frame Gap error, Bit 26 = packet | 1333 | | too short error, Bit 25 = packet too long error, Bit | 1334 | | 24 = CRC error, other?? are 16 bit enough?). | 1335 +--------+------------------------------------------------------+ 1337 Table 5 1339 NOTE: in earlier versions of this specification, the bits were 1340 specified as being numbered with 0 being the most-significant bit and 1341 31 being the least-significant bit of the 32-bit unsigned integer, 1342 rather than with 0 being the least-significant bit and 31 being the 1343 most-significant bit. Several implementations number the bits with 0 1344 being the least-significant bit, and no known implementations number 1345 them with 0 being the most-significant bit, so the specification was 1346 changed to reflect that reality. 1348 4.4. Simple Packet Block 1350 The Simple Packet Block (SPB) is a lightweight container for storing 1351 the packets coming from the network. Its presence is optional. 1353 A Simple Packet Block is similar to an Enhanced Packet Block (see 1354 Section 4.3), but it is smaller, simpler to process and contains only 1355 a minimal set of information. This block is preferred to the 1356 standard Enhanced Packet Block when performance or space occupation 1357 are critical factors, such as in sustained traffic capture 1358 applications. A capture file can contain both Enhanced Packet Blocks 1359 and Simple Packet Blocks: for example, a capture tool could switch 1360 from Enhanced Packet Blocks to Simple Packet Blocks when the hardware 1361 resources become critical. 1363 The Simple Packet Block does not contain the Interface ID field. 1364 Therefore, it MUST be assumed that all the Simple Packet Blocks have 1365 been captured on the interface previously specified in the first 1366 Interface Description Block. 1368 Figure 12 shows the format of the Simple Packet Block. 1370 1 2 3 1371 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 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 0 | Block Type = 0x00000003 | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 4 | Block Total Length | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 8 | Original Packet Length | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 12 / / 1380 / Packet Data / 1381 / variable length, padded to 32 bits / 1382 / / 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Block Total Length | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Figure 12: Simple Packet Block Format 1388 The Simple Packet Block has the following fields: 1390 * Block Type: The block type of the Simple Packet Block is 3. 1392 * Block Total Length: total size of this block, as described in 1393 Section 3.1. 1395 * Original Packet Length (32 bits): an unsigned value indicating the 1396 actual length of the packet when it was transmitted on the 1397 network. It can be different from length of the Packet Data 1398 field's length if the packet has been truncated by the capture 1399 process, in which case the SnapLen value in Section 4.2 will be 1400 less than this Original Packet Length value, and the SnapLen value 1401 MUST be used to determine the size of the Packet Data field 1402 length. 1404 * Packet Data: the data coming from the network, including link- 1405 layer headers. The length of this field can be derived from the 1406 field Block Total Length, present in the Block Header, and it is 1407 the minimum value among the SnapLen (present in the Interface 1408 Description Block) and the Original Packet Length (present in this 1409 header). The format of the data within this Packet Data field 1410 depends on the LinkType field specified in the Interface 1411 Description Block (see Section 4.2) and it is specified in the 1412 entry for that format in [LINKTYPES]. 1414 The Simple Packet Block does not contain the timestamp because this 1415 is often one of the most costly operations on PCs. Additionally, 1416 there are applications that do not require it; e.g. an Intrusion 1417 Detection System is interested in packets, not in their timestamp. 1419 A Simple Packet Block cannot be present in a Section that has more 1420 than one interface because of the impossibility to refer to the 1421 correct one (it does not contain any Interface ID field). 1423 The Simple Packet Block is very efficient in term of disk space: a 1424 snapshot whose length is 100 octets requires only 16 octets of 1425 overhead, which corresponds to an efficiency of more than 86%. 1427 4.5. Name Resolution Block 1429 The Name Resolution Block (NRB) is used to support the correlation of 1430 numeric addresses (present in the captured packets) and their 1431 corresponding canonical names and it is optional. Having the literal 1432 names saved in the file prevents the need for performing name 1433 resolution at a later time, when the association between names and 1434 addresses may be different from the one in use at capture time. 1435 Moreover, the NRB avoids the need for issuing a lot of DNS requests 1436 every time the trace capture is opened, and also provides name 1437 resolution when reading the capture with a machine not connected to 1438 the network. 1440 A Name Resolution Block is often placed at the beginning of the file, 1441 but no assumptions can be taken about its position. Multiple NRBs 1442 can exist in a pcapng file, either due to memory constraints or 1443 because additional name resolutions were performed by file processing 1444 tools, like network analyzers. 1446 A Name Resolution Block need not contain any Records, except the 1447 nrb_record_end Record which MUST be the last Record. The addresses 1448 and names in NRB Records MAY be repeated multiple times; i.e., the 1449 same IP address may resolve to multiple names, the same name may 1450 resolve to the multiple IP addresses, and even the same address-to- 1451 name pair may appear multiple times, in the same NRB or across NRBs. 1453 The format of the Name Resolution Block is shown in Figure 13. 1455 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 0 | Block Type = 0x00000004 | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 4 | Block Total Length | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 8 | Record Type | Record Value Length | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 12 / Record Value / 1465 / variable length, padded to 32 bits / 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 . . 1468 . . . . other records . . . . 1469 . . 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Record Type = nrb_record_end | Record Value Length = 0 | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 / / 1474 / Options (variable) / 1475 / / 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Block Total Length | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 Figure 13: Name Resolution Block Format 1482 The Name Resolution Block has the following fields: 1484 * Block Type: The block type of the Name Resolution Block is 4. 1486 * Block Total Length: total size of this block, as described in 1487 Section 3.1. 1489 This is followed by zero or more Name Resolution Records (in the TLV 1490 format), each of which contains an association between a network 1491 address and a name. An nrb_record_end MUST be added after the last 1492 Record, and MUST exist even if there are no other Records in the NRB. 1493 There are currently three possible types of records: 1495 +=================+========+==========+ 1496 | Name | Code | Length | 1497 +=================+========+==========+ 1498 | nrb_record_end | 0x0000 | 0 | 1499 +-----------------+--------+----------+ 1500 | nrb_record_ipv4 | 0x0001 | variable | 1501 +-----------------+--------+----------+ 1502 | nrb_record_ipv6 | 0x0002 | variable | 1503 +-----------------+--------+----------+ 1505 Table 6: Name Resolution Block Records 1507 nrb_record_end: 1508 The nrb_record_end record delimits the end of name resolution 1509 records. This record is needed to determine when the list of 1510 name resolution records has ended and some options (if any) 1511 begin. 1513 nrb_record_ipv4: 1514 The nrb_record_ipv4 record specifies an IPv4 address 1515 (contained in the first 4 octets), followed by one or more 1516 zero-terminated UTF-8 strings containing the DNS entries for 1517 that address. The minimum valid Record Length for this 1518 Record Type is thus 6: 4 for the IP octets, 1 character, and 1519 a zero-value octet terminator. Note that the IP address is 1520 treated as four octets, one for each octet of the IP address; 1521 it is not a 32-bit word, and thus the endianness of the SHB 1522 does not affect this field's value. 1524 Example: '127 0 0 1'"localhost". 1526 [Open issue: is an empty string (i.e., just a zero-value octet) 1527 valid?] 1529 nrb_record_ipv6: 1530 The nrb_record_ipv6 record specifies an IPv6 address 1531 (contained in the first 16 octets), followed by one or more 1532 zero-terminated strings containing the DNS entries for that 1533 address. The minimum valid Record Length for this Record 1534 Type is thus 18: 16 for the IP octets, 1 character, and a 1535 zero-value octet terminator. 1537 Example: '20 01 0d b8 00 00 00 00 00 00 00 00 12 34 56 78'"somehost". 1539 [Open issue: is an empty string (i.e., just a zero-value octet) 1540 valid?] 1541 Record Types other than those specified earlier MUST be ignored and 1542 skipped past. More Record Types will likely be defined in the 1543 future, and MUST NOT break backwards compatibility. 1545 Each Record Value is aligned to and padded to a 32-bit boundary. The 1546 corresponding Record Value Length reflects the actual length of the 1547 Record Value; it does not include the lengths of the Record Type 1548 field, the Record Value Length field, any padding for the Record 1549 Value, or anything after the Record Value. For Record Types with 1550 name strings, the Record Length does include the zero-value octet 1551 terminating that string. A Record Length of 0 is valid, unless 1552 indicated otherwise. 1554 After the list of Name Resolution Records, optionally, a list of 1555 options (formatted according to the rules defined in Section 3.5) can 1556 be present. 1558 In addition to the options defined in Section 3.5, the following 1559 options are valid within this block: 1561 +===============+======+==========+===================+ 1562 | Name | Code | Length | Multiple allowed? | 1563 +===============+======+==========+===================+ 1564 | ns_dnsname | 2 | variable | no | 1565 +---------------+------+----------+-------------------+ 1566 | ns_dnsIP4addr | 3 | 4 | no | 1567 +---------------+------+----------+-------------------+ 1568 | ns_dnsIP6addr | 4 | 16 | no | 1569 +---------------+------+----------+-------------------+ 1571 Table 7: Name Resolution Block Options 1573 ns_dnsname: 1574 The ns_dnsname option is a UTF-8 string containing the name 1575 of the machine (DNS server) used to perform the name 1576 resolution. The string is not zero-terminated. 1578 Example: "our_nameserver". 1580 ns_dnsIP4addr: 1581 The ns_dnsIP4addr option specifies the IPv4 address of the 1582 DNS server. Note that the IP address is treated as four 1583 octets, one for each octet of the IP address; it is not a 1584 32-bit word, and thus the endianness of the SHB does not 1585 affect this field's value. 1587 Example: '192 168 0 1'. 1589 ns_dnsIP6addr: 1590 The ns_dnsIP6addr option specifies the IPv6 address of the 1591 DNS server. 1593 Example: '20 01 0d b8 00 00 00 00 00 00 00 00 12 34 56 78'. 1595 4.6. Interface Statistics Block 1597 The Interface Statistics Block (ISB) contains the capture statistics 1598 for a given interface and it is optional. The statistics are 1599 referred to the interface defined in the current Section identified 1600 by the Interface ID field. An Interface Statistics Block is normally 1601 placed at the end of the file, but no assumptions can be taken about 1602 its position - it can even appear multiple times for the same 1603 interface. 1605 The format of the Interface Statistics Block is shown in Figure 14. 1607 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 0 | Block Type = 0x00000005 | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 4 | Block Total Length | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 8 | Interface ID | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 12 | Timestamp (High) | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 16 | Timestamp (Low) | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 20 / / 1621 / Options (variable) / 1622 / / 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Block Total Length | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 Figure 14: Interface Statistics Block Format 1629 The fields have the following meaning: 1631 * Block Type: The block type of the Interface Statistics Block is 5. 1633 * Block Total Length: total size of this block, as described in 1634 Section 3.1. 1636 * Interface ID: specifies the interface these statistics refers to; 1637 the correct interface will be the one whose Interface Description 1638 Block (within the current Section of the file) is identified by 1639 same number (see Section 4.2) of this field. 1641 * Timestamp: time this statistics refers to. The format of the 1642 timestamp is the same already defined in the Enhanced Packet Block 1643 (Section 4.3); the length of a unit of time is specified by the 1644 'if_tsresol' option (see Figure 10) of the Interface Description 1645 Block referenced by this packet. 1647 * Options: optionally, a list of options (formatted according to the 1648 rules defined in Section 3.5) can be present. 1650 All the statistic fields are defined as options in order to deal with 1651 systems that do not have a complete set of statistics. Therefore, In 1652 addition to the options defined in Section 3.5, the following options 1653 are valid within this block: 1655 +==================+======+========+===================+ 1656 | Name | Code | Length | Multiple allowed? | 1657 +==================+======+========+===================+ 1658 | isb_starttime | 2 | 8 | no | 1659 +------------------+------+--------+-------------------+ 1660 | isb_endtime | 3 | 8 | no | 1661 +------------------+------+--------+-------------------+ 1662 | isb_ifrecv | 4 | 8 | no | 1663 +------------------+------+--------+-------------------+ 1664 | isb_ifdrop | 5 | 8 | no | 1665 +------------------+------+--------+-------------------+ 1666 | isb_filteraccept | 6 | 8 | no | 1667 +------------------+------+--------+-------------------+ 1668 | isb_osdrop | 7 | 8 | no | 1669 +------------------+------+--------+-------------------+ 1670 | isb_usrdeliv | 8 | 8 | no | 1671 +------------------+------+--------+-------------------+ 1673 Table 8: Interface Statistics Block Options 1675 isb_starttime: 1676 The isb_starttime option specifies the time the capture 1677 started; time will be stored in two blocks of four octets 1678 each. The format of the timestamp is the same as the one 1679 defined in the Enhanced Packet Block (Section 4.3); the 1680 length of a unit of time is specified by the 'if_tsresol' 1681 option (see Figure 10) of the Interface Description Block 1682 referenced by this packet. 1684 Example: '96 c3 04 00 73 89 6a 65', in Little Endian, decodes to 1685 2012-06-29 06:17:00.834163 UTC. 1687 isb_endtime: 1688 The isb_endtime option specifies the time the capture ended; 1689 time will be stored in two blocks of four octets each. The 1690 format of the timestamp is the same as the one defined in the 1691 Enhanced Packet Block (Section 4.3); the length of a unit of 1692 time is specified by the 'if_tsresol' option (see Figure 10) 1693 of the Interface Description Block referenced by this packet. 1695 Example: '97 c3 04 00 aa 47 ca 64', in Little Endian, decodes to 1696 2012-06-29 07:28:25.298858 UTC. 1698 isb_ifrecv: 1699 The isb_ifrecv option specifies the 64-bit unsigned integer 1700 number of packets received from the physical interface 1701 starting from the beginning of the capture. 1703 Example: the decimal number 100. 1705 isb_ifdrop: 1706 The isb_ifdrop option specifies the 64-bit unsigned integer 1707 number of packets dropped by the interface due to lack of 1708 resources starting from the beginning of the capture. 1710 Example: '0'. 1712 isb_filteraccept: 1713 The isb_filteraccept option specifies the 64-bit unsigned 1714 integer number of packets accepted by filter starting from 1715 the beginning of the capture. 1717 Example: the decimal number 100. 1719 isb_osdrop: 1720 The isb_osdrop option specifies the 64-bit unsigned integer 1721 number of packets dropped by the operating system starting 1722 from the beginning of the capture. 1724 Example: '0'. 1726 isb_usrdeliv: 1728 The isb_usrdeliv option specifies the 64-bit unsigned integer 1729 number of packets delivered to the user starting from the 1730 beginning of the capture. The value contained in this field 1731 can be different from the value 'isb_filteraccept - 1732 isb_osdrop' because some packets could still be in the OS 1733 buffers when the capture ended. 1735 Example: '0'. 1737 All the fields that refer to packet counters are 64-bit values, 1738 represented with the octet order of the current section. Special 1739 care must be taken in accessing these fields: since all the blocks 1740 are aligned to a 32-bit boundary, such fields are not guaranteed to 1741 be aligned on a 64-bit boundary. 1743 4.7. systemd Journal Export Block 1745 The systemd (https://www.freedesktop.org/wiki/Software/systemd/) 1746 Journal Export Block 1747 (https://www.freedesktop.org/wiki/Software/systemd/export/) is a 1748 lightweight container for systemd Journal Export Format entry data. 1750 One of the primary components of the systemd System and Service 1751 Manager is the "Journal", a message logging system that uses arrays 1752 of key-value pairs. Journal entries are stored in a database-like 1753 file on disk but can be serialized to easily parseable "Journal 1754 Export Format" data or to a JSON object. The block described here is 1755 limited to Journal Export Format data only. 1757 A systemd Journal Export Block contains a single systemd Journal 1758 Export Format entry. Each entry MUST contain a __REALTIME_TIMESTAMP= 1759 field. If a timestamp for the block is required it can be derived 1760 from this field. Each entry MUST be zero-padded to 32 bits. 1761 Although the primary use of this block is intended for importing data 1762 from systemd, it could potentially be used to include arbitrary key- 1763 value data in a capture file. 1765 Figure 15 shows the format of the Journal Export Block. 1767 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 0 | Block Type = 0x00000009 | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 4 | Block Total Length | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 8 / / 1775 / Journal Entry / 1776 / variable length, padded to 32 bits / 1777 / / 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Block Total Length | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 Figure 15: systemd Journal Export Block Format 1784 The systemd Journal Export Block has the following fields: 1786 * Block Type: The block type of the Journal Export Block is 9. 1788 * Block Total Length: total size of this block, as described in 1789 Section 3.1. 1791 * Journal Entry: A journal entry as described in the Journal Export 1792 Format (https://www.freedesktop.org/wiki/Software/systemd/export/) 1793 documentation. Entries consist of a series of field names 1794 followed by text or binary field data. Common field names can be 1795 found in the systemd.journal-fields 1796 (https://www.freedesktop.org/software/systemd/man/systemd.journal- 1797 fields.html) documentation. The __REALTIME_TIMESTAMP= field MUST 1798 be present and valid as described above. Entries are not 1799 guaranteed to be a multiple of four octets and must be zero- 1800 padded. This allows the length of the entry to be determined by 1801 finding the last non-zero octet in the Journal Entry data. An 1802 entry may contain an entry separator (trailing newline) as 1803 described in the Journal Export Format specification 1805 4.8. Decryption Secrets Block 1807 A Decryption Secrets Block (DSB) stores (session) secrets that enable 1808 decryption of packets within the capture file. The format of these 1809 secrets is defined by the Secrets Type. 1811 Multiple DSBs can exist in a pcapng file, but they SHOULD be written 1812 before packet blocks that require those secrets. Tools MAY limit 1813 decryption to secrets that appear before packet blocks. 1815 The structure of a Decryption Secrets Block is shown in Figure 16. 1817 1 2 3 1818 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 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 0 | Block Type = 0x0000000A | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 4 | Block Total Length | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 8 | Secrets Type | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 12 | Secrets Length | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 16 / / 1829 / Secrets Data / 1830 / (variable length, padded to 32 bits) / 1831 / / 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 / / 1834 / Options (variable) / 1835 / / 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 / Block Total Length / 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Figure 16: Decryption Secrets Block Format 1842 The Decryption Secrets Block has the following fields. 1844 * Block Type: The block type of the Decryption Secrets Block is 10. 1846 * Block Total Length: total size of this block, as described in 1847 Section 3.1. 1849 * Secrets Type (32 bits): an unsigned integer identifier that 1850 describes the format of the following Secrets field. Requests for 1851 new Secrets Type codes should be made by creating a pull request 1852 to update this document as described in Section 11.1. 1854 * Secrets Length (32 bits): an unsigned integer that indicates the 1855 size of the following Secrets field, without any padding octets. 1857 * Secrets Data: binary data containing secrets, padded to a 32 bit 1858 boundary. 1860 * Options: optionally, a list of options (formatted according to the 1861 rules defined in Section 3.5) can be present. No DSB-specific 1862 options are currently defined. 1864 The following is a list of Secrets Types. 1866 0x544c534b: 1867 TLS Key Log. This format is described at NSS Key Log Format 1868 (https://developer.mozilla.org/NSS_Key_Log_Format). Every 1869 line MUST be properly terminated with either carriage return 1870 and linefeed ('\r\n') or linefeed ('\n'). Tools MUST be able 1871 to handle both line endings. 1873 0x57474b4c: 1874 WireGuard Key Log. Every line consists of the key type, 1875 equals sign ('='), and the base64-encoded 32-byte key with 1876 optional spaces before and in between. The key type is one 1877 of LOCAL_STATIC_PRIVATE_KEY, REMOTE_STATIC_PUBLIC_KEY, 1878 LOCAL_EPHEMERAL_PRIVATE_KEY, or PRESHARED|_KEY. This matches 1879 the output of extract-handshakes.sh 1880 (https://git.zx2c4.com/WireGuard/tree/contrib/examples/ 1881 extract-handshakes/README), which is part of the WireGuard 1882 (https://www.wireguard.com/) project. A PRESHARED_KEY line 1883 is linked to a session matched by a previous 1884 LOCAL_EPHEMERAL_PRIVATE_KEY line. Every line MUST be 1885 properly terminated with either carriage return and linefeed 1886 ('\r\n') or linefeed ('\n'). Tools MUST be able to handle 1887 both line endings. 1889 Warning: LOCAL_STATIC_PRIVATE_KEY and potentially PRESHARED_KEY are 1890 long-term secrets, users SHOULD only store non-production keys, or 1891 ensure proper protection of the pcapng file. 1893 0x5a4e574b: 1894 ZigBee NWK Key and ZigBee PANID for that network. Network 1895 Key as described in the ZigBee Specification 1896 (https://zigbeealliance.org/) 05-3473-21 (R21) section 4.2.2. 1897 The NWK Key is a 16 octet binary AES-128 key used to secure 1898 NWK Level frames within a single PAN. The NWK key is 1899 immediately followed by the 2 octet (16 bit) network PANID in 1900 little endian format. If and when the NWK Key changes a new 1901 DSB will contain the new NWK Key. 1903 0x5a415053: 1904 ZigBee APS Key. Application Support Link Key as described in 1905 the ZigBee Specification (https://zigbeealliance.org/) 1906 05-3473-21 (R21) section 4.4. Each 16 octet binary AES-128 1907 key secures frames exchanged between a pair of network nodes. 1908 The APS Key is immediately followed by the 2 octet (16 bit) 1909 network PANID in little endian format. The PANID is followed 1910 by the 2 octet (16 bit) short addresses, in little endian 1911 format, of the nodes to which the APS Key applies. The 1912 numerically lower short address shall come first. There is a 1913 APS Key DSB for each node pair for which the Link Key is 1914 known. As new links are formed, new DSBs contain the new 1915 Keys. If the APS Key changes for an existing link, it is 1916 contained in a new DSB with the new APS Key. 1918 0 1 2 3 1919 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 1920 +---------------------------------------------------------------+ 1921 0 | Block Type = 0x0000000A | 1922 +---------------------------------------------------------------+ 1923 4 | Block Total Length | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 8 | Secrets Type = 0x5a4e574b | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 12 | Secrets Length | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 16 | AES-128 | 1930 | NKW Key | 1931 | (16 octets) | 1932 | (128 bits) | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 32 | PAN ID | padding (0) | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 36 / / 1937 / Options (variable) / 1938 / / 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 / Block Total Length / 1941 +---------------------------------------------------------------+ 1943 Figure 17: ZigBee NWK Key Data Format 1945 0 1 2 3 1946 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 1947 +---------------------------------------------------------------+ 1948 0 | Block Type = 0x0000000A | 1949 +---------------------------------------------------------------+ 1950 4 | Block Total Length | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 8 | Secrets Type = 0x5a415053 | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 12 | Secrets Length | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 16 | AES-128 | 1957 | APS Key | 1958 | (16 octets) | 1959 | (128 bits) | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 32 | PAN ID | Low Node Short Address | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 36 | High Node Short Address | padding (0) | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 40 / / 1966 / Options (variable) / 1967 / / 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 / Block Total Length / 1970 +---------------------------------------------------------------+ 1972 Figure 18: ZigBee APS Key Data Format 1974 4.9. Custom Block 1976 A Custom Block (CB) is the container for storing custom data that is 1977 not part of another block; for storing custom data as part of another 1978 block, see Section 3.5.1. The Custom Block is optional, can be 1979 repeated any number of times, and can appear before or after any 1980 other block except the first Section Header Block which must come 1981 first in the file. Different Custom Blocks, of different type codes 1982 and/or different Private Enterprise Numbers, may be used in the same 1983 pcapng file. The format of a Custom Block is shown in Figure 19. 1985 1 2 3 1986 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 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 0 | Block Type = 0x00000BAD or 0x40000BAD | 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 4 | Block Total Length | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 8 | Private Enterprise Number (PEN) | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 12 / / 1995 / Custom Data / 1996 / variable length, padded to 32 bits / 1997 / / 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 / / 2000 / Options (variable) / 2001 / / 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Block Total Length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 Figure 19: Custom Block Format 2008 The Custom Block uses the type code 0x00000BAD (2989 in decimal) for 2009 a custom block that pcapng re-writers can copy into new files, and 2010 the type code 0x40000BAD (1073744813 in decimal) for one that should 2011 not be copied. See Section 6.2 for details. 2013 The Custom Block has the following fields: 2015 * Block Type: The block type of the Custom Block is 0x00000BAD or 2016 0x40000BAD, as described previously. 2018 * Block Total Length: total size of this block, as described in 2019 Section 3.1. 2021 * Private Enterprise Number (32 bits): An IANA-assigned Private 2022 Enterprise Number identifying the organization which defined the 2023 Custom Block. See Section 6.1 for details. The PEN MUST be 2024 encoded using the same endianness as the Section Header Block it 2025 is within the scope of. 2027 * Custom Data: the custom data, padded to a 32 bit boundary. 2029 * Options: optionally, a list of options (formatted according to the 2030 rules defined in Section 3.5) can be present. Note that custom 2031 options for the Custom Block still use the custom option format 2032 and type code, as described in Section 3.5.1. 2034 5. Experimental Blocks (deserve further investigation) 2036 5.1. Alternative Packet Blocks (experimental) 2038 Can some other packet blocks (besides the ones described in the 2039 previous paragraphs) be useful? 2041 5.2. Compression Block (experimental) 2043 The Compression Block is optional. A file can contain an arbitrary 2044 number of these blocks. A Compression Block, as the name says, is 2045 used to store compressed data. Its format is shown in Figure 20. 2047 1 2 3 2048 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 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 0 | Block Type = ? | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 4 | Block Total Length | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 8 | Compr. Type | / 2055 +-+-+-+-+-+-+-+-+ / 2056 / / 2057 / Compressed Data / 2058 / / 2059 / variable length, octet-aligned and padded to end on a 32-bit / 2060 / boundary / 2061 / / 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Block Total Length | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 Figure 20: Compression Block Format 2068 The fields have the following meaning: 2070 * Block Type: The block type of the Compression Block is not yet 2071 assigned. 2073 * Block Total Length: total size of this block, as described in 2074 Section 3.1. 2076 * Compression Type (8 bits): an unsigned value that specifies the 2077 compression algorithm. Possible values for this field are 0 2078 (uncompressed), 1 (Lempel-Ziv), 2 (Gzip), other?? Probably some 2079 kind of dumb and fast compression algorithm could be effective 2080 with some types of traffic (for example web), but which? 2082 * Compressed Data: data of this block. Once decompressed, it is 2083 made of other blocks. 2085 5.3. Encryption Block (experimental) 2087 The Encryption Block is optional. A file can contain an arbitrary 2088 number of these blocks. An Encryption Block is used to store 2089 encrypted data. Its format is shown in Figure 21. 2091 1 2 3 2092 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 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 0 | Block Type = ? | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 4 | Block Total Length | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 8 | Encr. Type | / 2099 +-+-+-+-+-+-+-+-+ / 2100 / / 2101 / Encrypted Data / 2102 / / 2103 / variable length, octet-aligned / 2104 / / 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | Block Total Length | 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 Figure 21: Encryption Block Format 2111 The fields have the following meaning: 2113 * Block Type: The block type of the Encryption Block is not yet 2114 assigned. 2116 * Block Total Length: total size of this block, as described in 2117 Section 3.1. 2119 * Encryption Type (8 bits): an unsigned value that specifies the 2120 encryption algorithm. Possible values for this field are ??? 2121 (TODO) NOTE: this block should probably contain other fields, 2122 depending on the encryption algorithm. To be defined precisely. 2124 * Encrypted Data: data of this block. Once decrypted, it originates 2125 other blocks. 2127 5.4. Fixed Length Block (experimental) 2129 The Fixed Length Block is optional. A file can contain an arbitrary 2130 number of these blocks. A Fixed Length Block can be used to optimize 2131 the access to the file. Its format is shown in Figure 22. A Fixed 2132 Length Block stores records with constant size. It contains a set of 2133 Blocks (normally Enhanced Packet Blocks or Simple Packet Blocks), of 2134 which it specifies the size. Knowing this size a priori helps to 2135 scan the file and to load some portions of it without truncating a 2136 block, and is particularly useful with cell-based networks like ATM. 2138 1 2 3 2139 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 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 0 | Block Type = ? | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 4 | Block Total Length | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 8 | Cell Size | | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 2147 / / 2148 / Fixed Size Data / 2149 / / 2150 / variable length, octet-aligned / 2151 / / 2152 / / 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Block Total Length | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 Figure 22: Fixed Length Block Format 2159 The fields have the following meaning: 2161 * Block Type: The block type of the Fixed Length Block is not yet 2162 assigned. 2164 * Block Total Length: total size of this block, as described in 2165 Section 3.1. 2167 * Cell size (16 bits): an unsigned value that indicates the size of 2168 the blocks contained in the data field. 2170 * Fixed Size Data: data of this block. 2172 5.5. Directory Block (experimental) 2174 If present, this block contains the following information: 2176 * number of indexed packets (N) 2178 * table with position and length of any indexed packet (N entries) 2180 A directory block MUST be followed by at least N packets, otherwise 2181 it MUST be considered invalid. It can be used to efficiently load 2182 portions of the file to memory and to support operations on memory 2183 mapped files. This block can be added by tools like network 2184 analyzers as a consequence of file processing. 2186 5.6. Traffic Statistics and Monitoring Blocks (experimental) 2188 One or more blocks could be defined to contain network statistics or 2189 traffic monitoring information. They could be use to store data 2190 collected from RMON or Netflow probes, or from other network 2191 monitoring tools. 2193 5.7. Event/Security Block (experimental) 2195 This block could be used to store events. Events could contain 2196 generic information (for example network load over 50%, server 2197 down...) or security alerts. An event could be: 2199 * skipped, if the application doesn't know how to do with it 2201 * processed independently by the packets. In other words, the 2202 applications skips the packets and processes only the alerts 2204 * processed in relation to packets: for example, a security tool 2205 could load only the packets of the file that are near a security 2206 alert; a monitoring tool could skip the packets captured while the 2207 server was down. 2209 6. Vendor-Specific Custom Extensions 2211 This section uses the term "vendor" to describe an organization which 2212 extends the pcapng file with custom, proprietary blocks or options. 2213 It should be noted, however, that the "vendor" is just an abstract 2214 entity that agrees on a custom extension format: for example it may 2215 be a manufacturer, industry association, an individual user, or 2216 collective group of users. 2218 6.1. Supported Use-Cases 2220 There are two different supported use-cases for vendor-specific 2221 custom extensions: local and portable. Local use means the custom 2222 data is only expected to be usable on the same machine, and the same 2223 application, which encoded it into the file. This limitation is due 2224 to the lack of a common registry for the local use number codes (the 2225 block or option type code numbers with the Most Significant Bit set). 2226 Since two different vendors may choose the same number, one vendor's 2227 application reading the other vendor's file would result in decoding 2228 failure. Therefore, vendors SHOULD instead use the portable method, 2229 as described next. 2231 The portable use-case supports vendor-specific custom extensions in 2232 pcapng files which can be shared across systems, organizations, etc. 2233 To avoid number space collisions, an IANA-registered Private 2234 Enterprise Number (PEN) is encoded into the Custom Block or Custom 2235 Option, using the PEN number that belongs to the vendor defining the 2236 extension. Anyone can register a new PEN with IANA, for free, by 2237 filling out the online request form at http://pen.iana.org/pen/ 2238 PenApplication.page (http://pen.iana.org/pen/PenApplication.page). 2240 6.2. Controlling Copy Behavior 2242 Both Custom Blocks and Custom Options support two different codes to 2243 distinguish their "copy" behavior: a code for when the block or 2244 option can be safely copied into a new pcapng file by a pcapng 2245 manipulating application, and a code for when it should not be 2246 copied. A common reason for not copying a Custom Block or Custom 2247 Option is because it depends on other blocks or options in some way 2248 that would invalidate the custom data if the other blocks/options 2249 were removed or re-ordered. For example, if a Custom Block's data 2250 includes an Interface ID number in its Custom Data portion, then it 2251 cannot be safely copied by a pcapng application that merges pcapng 2252 files, because the merging application might re-order or remove one 2253 or more of the Interface Description Blocks, and thereby change the 2254 Interface IDs that the Custom Block depends upon. The same issue 2255 arises if a Custom Block or Custom Option depends on the presence of, 2256 or specific ordering of, other standard-based or custom-defined 2257 blocks or options. 2259 Note that the copy semantics is not related to privacy - there is no 2260 guarantee that a pcapng anonymizer will remove a Custom Block or 2261 Custom Option, even if the appropriate code is used requesting it not 2262 be copied; and the original pcapng file can be shared anyway. If the 2263 Custom Data portion of the Custom Block or Custom Option contains 2264 sensitive information, then it should be encrypted in some fashion. 2266 6.3. Strings vs. Octets 2268 For the Custom Options, there are two Custom Data formats supported: 2269 a UTF-8 string and a binary data payload. The rationale for this 2270 separation is that a pcapng display application which does not 2271 understand the specific PEN's Custom Option can still display the 2272 data as a string if it's a string type code, rather than as hex-ascii 2273 of the octets. 2275 6.4. Endianness Issues 2277 Implementers writing Custom Blocks or Custom Options should be aware 2278 that a pcapng file can be re-written by machines using a different 2279 endianness than the original file, which means all known fields of 2280 the pcapng file will change endianness in the new file. Since the 2281 Custom Data payload of the Custom Block or Custom Option might be an 2282 arbitrary sequence of unknown octets to such machines, they cannot 2283 convert multi-octet values inside the Custom Data into the 2284 appropriate endianness. 2286 For example, a little-endian machine can create a new pcapng file and 2287 add some binary data Custom Options to some Block(s) in the file. 2288 This file can then be sent to a big-endian host, which will convert 2289 it to big-endian format if it re-writes the file. It will, however, 2290 leave the Custom Data payload alone (as little-endian format). If 2291 this file then gets sent back to the little-endian machine, then when 2292 that little-endian machine reads the file it will detect the format 2293 is big- endian, and swap the endianness while it parses the file - 2294 but that will cause the Custom Data payload to be incorrect since it 2295 was already in little-endian format. 2297 Therefore, the vendor should either encode all of their fields in a 2298 consistent manner, such as always in big-endian or always little- 2299 endian format, regardless of the host platform's endianness, or 2300 should encode some flag in the Custom Data payload to indicate in 2301 which endianness the rest of the payload is written. 2303 7. Recommended File Name Extension: .pcapng 2305 The recommended file name extension for the "PCAP Next Generation 2306 Capture File Format" specified in this document is ".pcapng". 2308 On Windows and macOS, files are distinguished by an extension to 2309 their filename. Such an extension is technically not actually 2310 required, as applications should be able to automatically detect the 2311 pcapng file format through the "magic bytes" at the beginning of the 2312 file, as some other UN*X desktop environments do. However, using 2313 name extensions makes it easier to work with files (e.g. visually 2314 distinguish file formats) so it is recommended - though not required 2315 - to use .pcapng as the name extension for files following this 2316 specification. 2318 Please note: To avoid confusion (such as the current usage of .cap 2319 for a plethora of different capture file formats) file name 2320 extensions other than .pcapng should be avoided. 2322 8. Conclusions 2324 The file format proposed in this document should be very versatile 2325 and satisfy a wide range of applications. In the simplest case, it 2326 can contain a raw capture of the network data, made of a series of 2327 Simple Packet Blocks. In the most complex case, it can be used as a 2328 repository for heterogeneous information. In every case, the file 2329 remains easy to parse and an application can always skip the data it 2330 is not interested in; at the same time, different applications can 2331 share the file, and each of them can benefit of the information 2332 produced by the others. Two or more files can be concatenated 2333 obtaining another valid file. 2335 9. Implementations 2337 Some known implementations that read or write the pcapng file format 2338 are listed on the pcapng GitHub wiki 2339 (https://github.com/pcapng/pcapng/wiki/Implementations). 2341 10. Security Considerations 2343 TBD. 2345 11. IANA Considerations 2347 TBD. 2349 [Open issue: decide whether the block types, option types, NRB Record 2350 types, etc. should be IANA registries. And if so, what the IANA 2351 policy for each should be (see RFC 5226)] 2353 11.1. Standardized Block Type Codes 2355 Every Block is uniquely identified by a 32-bit integer value, stored 2356 in the Block Header. 2358 As pointed out in Section 3.1, Block Type codes whose Most 2359 Significant Bit (bit 31) is set to 1 are reserved for local use by 2360 the application. 2362 All the remaining Block Type codes (0x00000000 to 0x7FFFFFFF) are 2363 standardized by this document. Requests for new Block Type codes, 2364 Option Type codes, and Secrets Type codes should be made by creating 2365 a pull request to update this document at github.com/pcapng/pcapng 2366 (https://github.com/pcapng/pcapng). The pull request should add a 2367 description of the new block, option, or secret type to Section 4. 2368 The pull request description should contain a clear request for a new 2369 type code assignment. 2371 The following is a list of the Standardized Block Type Codes: 2373 +=======================+=======================================+ 2374 | Block Type Code | Description | 2375 +=======================+=======================================+ 2376 | 0x00000000 | Reserved ??? | 2377 +-----------------------+---------------------------------------+ 2378 | 0x00000001 | Interface Description Block | 2379 | | (Section 4.2) | 2380 +-----------------------+---------------------------------------+ 2381 | 0x00000002 | Packet Block (Appendix A) | 2382 +-----------------------+---------------------------------------+ 2383 | 0x00000003 | Simple Packet Block (Section 4.4) | 2384 +-----------------------+---------------------------------------+ 2385 | 0x00000004 | Name Resolution Block (Section 4.5) | 2386 +-----------------------+---------------------------------------+ 2387 | 0x00000005 | Interface Statistics Block | 2388 | | (Section 4.6) | 2389 +-----------------------+---------------------------------------+ 2390 | 0x00000006 | Enhanced Packet Block (Section 4.3) | 2391 +-----------------------+---------------------------------------+ 2392 | 0x00000007 | IRIG Timestamp Block (requested by | 2393 | | Gianluca Varenni | 2394 | | , CACE | 2395 | | Technologies LLC); code also used for | 2396 | | Socket Aggregation Event Block | 2397 | | (https://github.com/google/linux- | 2398 | | sensor/blob/master/hone-pcapng.txt) | 2399 +-----------------------+---------------------------------------+ 2400 | 0x00000008 | ARINC 429 | 2401 | | (https://en.wikipedia.org/wiki/ | 2402 | | ARINC_429) in AFDX Encapsulation | 2403 | | Information Block (requested by | 2404 | | Gianluca Varenni | 2405 | | , CACE | 2406 | | Technologies LLC) | 2407 +-----------------------+---------------------------------------+ 2408 | 0x00000009 | systemd Journal Export Block | 2409 | | (Section 4.7) | 2410 +-----------------------+---------------------------------------+ 2411 | 0x0000000A | Decryption Secrets Block | 2412 | | (Section 4.8) | 2413 +-----------------------+---------------------------------------+ 2414 | 0x00000101 | Hone Project (https://github.com/ | 2415 | | HoneProject) Machine Info Block | 2416 | | (https://github.com/HoneProject/ | 2417 | | Linux-Sensor/wiki/Augmented-PCAP- | 2418 | | Next-Generation-Dump-File-Format) | 2419 | | (see also Google version | 2420 | | (https://github.com/google/linux- | 2421 | | sensor/blob/master/hone-pcapng.txt)) | 2422 +-----------------------+---------------------------------------+ 2423 | 0x00000102 | Hone Project (https://github.com/ | 2424 | | HoneProject) Connection Event Block | 2425 | | (https://github.com/HoneProject/ | 2426 | | Linux-Sensor/wiki/Augmented-PCAP- | 2427 | | Next-Generation-Dump-File-Format) | 2428 | | (see also Google version | 2429 | | (https://github.com/google/linux- | 2430 | | sensor/blob/master/hone-pcapng.txt)) | 2431 +-----------------------+---------------------------------------+ 2432 | 0x00000201 | Sysdig (https://github.com/draios/ | 2433 | | sysdig) Machine Info Block | 2434 +-----------------------+---------------------------------------+ 2435 | 0x00000202 | Sysdig (https://github.com/draios/ | 2436 | | sysdig) Process Info Block, version 1 | 2437 +-----------------------+---------------------------------------+ 2438 | 0x00000203 | Sysdig (https://github.com/draios/ | 2439 | | sysdig) FD List Block | 2440 +-----------------------+---------------------------------------+ 2441 | 0x00000204 | Sysdig (https://github.com/draios/ | 2442 | | sysdig) Event Block | 2443 +-----------------------+---------------------------------------+ 2444 | 0x00000205 | Sysdig (https://github.com/draios/ | 2445 | | sysdig) Interface List Block | 2446 +-----------------------+---------------------------------------+ 2447 | 0x00000206 | Sysdig (https://github.com/draios/ | 2448 | | sysdig) User List Block | 2449 +-----------------------+---------------------------------------+ 2450 | 0x00000207 | Sysdig (https://github.com/draios/ | 2451 | | sysdig) Process Info Block, version 2 | 2452 +-----------------------+---------------------------------------+ 2453 | 0x00000208 | Sysdig (https://github.com/draios/ | 2454 | | sysdig) Event Block with flags | 2455 +-----------------------+---------------------------------------+ 2456 | 0x00000209 | Sysdig (https://github.com/draios/ | 2457 | | sysdig) Process Info Block, version 3 | 2458 +-----------------------+---------------------------------------+ 2459 | 0x00000210 | Sysdig (https://github.com/draios/ | 2460 | | sysdig) Process Info Block, version 4 | 2461 +-----------------------+---------------------------------------+ 2462 | 0x00000211 | Sysdig (https://github.com/draios/ | 2463 | | sysdig) Process Info Block, version 5 | 2464 +-----------------------+---------------------------------------+ 2465 | 0x00000212 | Sysdig (https://github.com/draios/ | 2466 | | sysdig) Process Info Block, version 6 | 2467 +-----------------------+---------------------------------------+ 2468 | 0x00000213 | Sysdig (https://github.com/draios/ | 2469 | | sysdig) Process Info Block, version 7 | 2470 +-----------------------+---------------------------------------+ 2471 | 0x00000BAD | Custom Block that rewriters can copy | 2472 | | into new files (Section 4.9) | 2473 +-----------------------+---------------------------------------+ 2474 | 0x40000BAD | Custom Block that rewriters should | 2475 | | not copy into new files (Section 4.9) | 2476 +-----------------------+---------------------------------------+ 2477 | 0x0A0D0D0A | Section Header Block (Section 4.1) | 2478 +-----------------------+---------------------------------------+ 2479 | 0x0A0D0A00-0x0A0D0AFF | Reserved. Used to detect trace files | 2480 | | corrupted because of file transfers | 2481 | | using the HTTP protocol in text mode. | 2482 +-----------------------+---------------------------------------+ 2483 | 0x000A0D0A-0xFF0A0D0A | Reserved. Used to detect trace files | 2484 | | corrupted because of file transfers | 2485 | | using the HTTP protocol in text mode. | 2486 +-----------------------+---------------------------------------+ 2487 | 0x000A0D0D-0xFF0A0D0D | Reserved. Used to detect trace files | 2488 | | corrupted because of file transfers | 2489 | | using the HTTP protocol in text mode. | 2490 +-----------------------+---------------------------------------+ 2491 | 0x0D0D0A00-0x0D0D0AFF | Reserved. Used to detect trace files | 2492 | | corrupted because of file transfers | 2493 | | using the FTP protocol in text mode. | 2494 +-----------------------+---------------------------------------+ 2495 | 0x80000000-0xFFFFFFFF | Reserved for local use. | 2496 +-----------------------+---------------------------------------+ 2498 Table 9: Standardized Block Type Codes 2500 [Open issue: reserve 0x40000000-0x7FFFFFFF for do-not-copy-bit range 2501 of base types?] 2503 12. Contributors 2505 Loris Degioanni and Gianluca Varenni were coauthoring this document 2506 before it was submitted to the IETF. 2508 13. Acknowledgments 2510 The authors wish to thank Anders Broman, Ulf Lamping, Richard Sharpe 2511 and many others for their invaluable comments. 2513 14. References 2515 14.1. Normative References 2517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2518 Requirement Levels", BCP 14, RFC 2119, 2519 DOI 10.17487/RFC2119, March 1997, 2520 . 2522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2524 May 2017, . 2526 14.2. Informative References 2528 [LINKTYPES] 2529 The Tcpdump Group, "the tcpdump.org link-layer header 2530 types registry", . 2532 Appendix A. Packet Block (obsolete!) 2534 The Packet Block is obsolete, and MUST NOT be used in new files. Use 2535 the Enhanced Packet Block or Simple Packet Block instead. This 2536 section is for historical reference only. 2538 A Packet Block was a container for storing packets coming from the 2539 network. 2541 1 2 3 2542 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 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 0 | Block Type = 0x00000002 | 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 4 | Block Total Length | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 8 | Interface ID | Drops Count | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 12 | Timestamp (High) | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 16 | Timestamp (Low) | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 20 | Captured Packet Length | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 24 | Original Packet Length | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 28 / / 2559 / Packet Data / 2560 / variable length, padded to 32 bits / 2561 / / 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 / / 2564 / Options (variable) / 2565 / / 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | Block Total Length | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 Figure 23: Packet Block Format 2572 The Packet Block has the following fields: 2574 * Block Type: The block type of the Packet Block is 2. 2576 * Block Total Length: total size of this block, as described in 2577 Section 3.1. 2579 * Interface ID: specifies the interface this packet comes from; the 2580 correct interface will be the one whose Interface Description 2581 Block (within the current Section of the file) is identified by 2582 the same number (see Section 4.2) of this field. The interface ID 2583 MUST be valid, which means that an matching interface description 2584 block MUST exist. 2586 * Drops Count: a local drop counter. It specifies the number of 2587 packets lost (by the interface and the operating system) between 2588 this packet and the preceding one. The value xFFFF (in 2589 hexadecimal) is reserved for those systems in which this 2590 information is not available. 2592 * Timestamp (High) and Timestamp (Low): timestamp of the packet. 2593 The format of the timestamp is the same as was already defined for 2594 the Enhanced Packet Block (Section 4.3). 2596 * Captured Packet Length: number of octets captured from the packet 2597 (i.e. the length of the Packet Data field). It will be the 2598 minimum value among the Original Packet Length and the snapshot 2599 length for the interface (SnapLen, defined in Figure 10). The 2600 value of this field does not include the padding octets added at 2601 the end of the Packet Data field to align the Packet Data field to 2602 a 32-bit boundary. 2604 * Original Packet Length: actual length of the packet when it was 2605 transmitted on the network. It can be different from Captured 2606 Packet Length if the packet has been truncated by the capture 2607 process. 2609 * Packet Data: the data coming from the network, including link- 2610 layer headers. The actual length of this field is Captured Packet 2611 Length plus the padding to a 32-bit boundary. The format of the 2612 link-layer headers depends on the LinkType field specified in the 2613 Interface Description Block (see Section 4.2) and it is specified 2614 in the entry for that format in [LINKTYPES]. 2616 * Options: optionally, a list of options (formatted according to the 2617 rules defined in Section 3.5) can be present. 2619 In addition to the options defined in Section 3.5, the following 2620 options were valid within this block: 2622 +============+======+==========+===================+ 2623 | Name | Code | Length | Multiple allowed? | 2624 +============+======+==========+===================+ 2625 | pack_flags | 2 | 4 | no | 2626 +------------+------+----------+-------------------+ 2627 | pack_hash | 3 | variable | yes | 2628 +------------+------+----------+-------------------+ 2630 Table 10: Packet Block Options 2632 pack_flags: 2634 The pack_flags option is the same as the epb_flags of the 2635 enhanced packet block. 2637 Example: '0'. 2639 pack_hash: 2640 The pack_hash option is the same as the epb_hash of the 2641 enhanced packet block. 2643 Examples: '02 EC 1D 87 97', '03 45 6E C2 17 7C 10 1E 3C 2E 99 6E C2 2644 9A 3D 50 8E'. 2646 Authors' Addresses 2648 Michael Tuexen (editor) 2649 Muenster University of Applied Sciences 2650 Stegerwaldstrasse 39 2651 48565 Steinfurt 2652 Germany 2654 Email: tuexen@fh-muenster.de 2656 Fulvio Risso 2657 Politecnico di Torino 2658 Corso Duca degli Abruzzi, 24 2659 10129 Torino 2660 Italy 2662 Email: fulvio.risso@polito.it 2664 Jasper Bongertz 2665 Airbus Defence and Space CyberSecurity 2666 Kanzlei 63c 2667 40667 Meerbusch 2668 Germany 2670 Email: jasper@packet-foo.com 2672 Gerald Combs 2673 Wireshark Foundation 2674 339 Madson Pl 2675 Davis, CA 95618 2676 United States of America 2678 Email: gerald@wireshark.org 2679 Guy Harris 2681 Email: gharris@sonic.net 2683 Eelco Chaudron 2684 Red Hat 2685 De Entree 238 2686 1101 EE Amsterdam 2687 Netherlands 2689 Email: eelco@redhat.com 2691 Michael C. Richardson 2692 Sandelman Software Works 2694 Email: mcr+ietf@sandelman.ca 2695 URI: http://www.sandelman.ca/