idnits 2.17.1 draft-tuexen-opswg-pcapng-00.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2014) is 3585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1851 -- Looks like a reference, but probably isn't: '2' on line 1853 -- Looks like a reference, but probably isn't: '3' on line 1855 -- Looks like a reference, but probably isn't: '4' on line 1857 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). 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: December 28, 2014 Politecnico di Torino 6 J. Bongertz 7 Airbus DS CyberSecurity 8 G. Harris 10 June 26, 2014 12 PCAP Next Generation (PCAPNG) Dump File Format 13 draft-tuexen-opswg-pcapng-00.txt 15 Abstract 17 This document describes a format to dump captured packets to a file. 18 This format is extensible; Wireshark can currently read and write it, 19 and libpcap can currently read some pcap-ng files. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 28, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. General File Structure . . . . . . . . . . . . . . . . . . . 3 58 3.1. General Block Structure . . . . . . . . . . . . . . . . . 3 59 3.2. Block Types . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Logical Block Hierarchy . . . . . . . . . . . . . . . . . 6 61 3.4. Physical File Layout . . . . . . . . . . . . . . . . . . 6 62 3.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.6. Data format . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Block Definition . . . . . . . . . . . . . . . . . . . . . . 11 65 4.1. Section Header Block (mandatory) . . . . . . . . . . . . 11 66 4.2. Interface Description Block (mandatory) . . . . . . . . . 14 67 4.3. Enhanced Packet Block (optional) . . . . . . . . . . . . 23 68 4.4. Simple Packet Block (optional) . . . . . . . . . . . . . 27 69 4.5. Packet Block (obsolete!) . . . . . . . . . . . . . . . . 29 70 4.6. Name Resolution Block (optional) . . . . . . . . . . . . 31 71 4.7. Interface Statistics Block (optional) . . . . . . . . . . 34 72 5. Experimental Blocks (deserved to a further investigation) . . 37 73 5.1. Alternative Packet Blocks (experimental) . . . . . . . . 37 74 5.2. Compression Block (experimental) . . . . . . . . . . . . 37 75 5.3. Encryption Block (experimental) . . . . . . . . . . . . . 38 76 5.4. Fixed Length Block (experimental) . . . . . . . . . . . . 39 77 5.5. Directory Block (experimental) . . . . . . . . . . . . . 40 78 5.6. Traffic Statistics and Monitoring Blocks (experimental) . 41 79 5.7. Event/Security Block (experimental) . . . . . . . . . . . 41 80 6. Recommended File Name Extension: .pcapng . . . . . . . . . . 41 81 7. How to add Vendor / Domain specific extensions . . . . . . . 41 82 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 42 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 42 88 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 89 Appendix A. Packet Block Flags Word . . . . . . . . . . . . . . 43 90 Appendix B. Standardized Block Type Codes . . . . . . . . . . . 43 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 93 1. Introduction 95 The problem of exchanging packet traces becomes more and more 96 critical every day; unfortunately, no standard solutions exist for 97 this task right now. One of the most accepted packet interchange 98 formats is the one defined by libpcap, which is rather old and is 99 lacking in functionality for more modern applications particularly 100 from the extensibility point of view. 102 This document proposes a new format for dumping packet traces. The 103 following goals are being pursued: 105 Extensibility: It should be possible to add new standard 106 capabilities to the file format over time, and third parties 107 should be able to enrich the information embedded in the file with 108 proprietary extensions, with tools unaware of newer extensions 109 being able to ignore them. 111 Portability: A capture trace must contain all the information needed 112 to read data independently from network, hardware and operating 113 system of the machine that made the capture. 115 Merge/Append data: It should be possible to add data at the end of a 116 given file, and the resulting file must still be readable. 118 2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. General File Structure 126 3.1. General Block Structure 128 A capture file is organized in blocks, that are appended one to 129 another to form the file. All the blocks share a common format, 130 which is shown in Figure 1. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Block Type | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Block Total Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 / Block Body / 140 / variable length, aligned to 32 bits / 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Block Total Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1: Basic block structure. 147 The fields have the following meaning: 149 o Block Type (32 bits): unique value that identifies the block. 150 Values whose Most Significant Bit (MSB) is equal to 1 are reserved 151 for local use. They can be used to make extensions to the file 152 format to save private data to the file. The list of currently 153 defined types can be found in Appendix B 155 o Block Total Length: total size of this block, in bytes. For 156 instance, the length of a block that does not have body is 12 157 bytes. 159 o Block Body: content of the block. 161 o Block Total Length: total size of this block, in bytes. This 162 field is duplicated for permitting backward file navigation. 164 This structure, shared among all blocks, makes it easy to process a 165 file and to skip unneeded or unknown blocks. Some blocks can contain 166 other blocks inside (nested blocks). Some of the blocks are 167 mandatory, i.e. a dump file is not valid if they are not present, 168 other are optional. 170 The General Block Structure allows defining other blocks if needed. 171 A parser that does non understand them can simply ignore their 172 content. 174 3.2. Block Types 176 The currently standardized Block Type codes are specified in 177 Appendix B, they have been grouped in the following four categories: 179 MANDATORY blocks MUST appear at least once in each file: 181 o Section Header Block (Section 4.1): it defines the most important 182 characteristics of the capture file. 184 o Interface Description Block (Section 4.2): it defines the most 185 important characteristics of the interface(s) used for capturing 186 traffic. 188 OPTIONAL blocks MAY appear in a file: 190 o Enhanced Packet Block (Section 4.3): it contains a single captured 191 packet, or a portion of it. It represents an evolution of the 192 original Packet Block (Section 4.5). 194 o Simple Packet Block (Section 4.4): it contains a single captured 195 packet, or a portion of it, with only a minimal set of information 196 about it. 198 o Name Resolution Block (Section 4.6): it defines the mapping from 199 numeric addresses present in the packet dump and the canonical 200 name counterpart. 202 o Interface Statistics Block (Section 4.7): it defines how to store 203 some statistical data (e.g. packet dropped, etc) which can be 204 useful to understand the conditions in which the capture has been 205 made. 207 OBSOLETE blocks SHOULD NOT appear in newly written files (but left 208 here for reference): 210 o Packet Block (Section 4.5): it contains a single captured packet, 211 or a portion of it. It should be considered OBSOLETE, and 212 superseded by the Enhanced Packet Block (Section 4.3). 214 EXPERIMENTAL blocks are considered interesting but the authors 215 believe that they deserve more in-depth discussion before being 216 defined: 218 o Alternative Packet Blocks 220 o Compression Block 222 o Encryption Block 224 o Fixed Length Block 226 o Directory Block 228 o Traffic Statistics and Monitoring Blocks 229 o Event/Security Blocks 231 3.3. Logical Block Hierarchy 233 The blocks build a logical hierarchy as they refer to each other. 234 Figure 2 shows the logical hierarchy of the currently defined blocks 235 in the form of a "tree view": 237 Section Header 238 | 239 +- Interface Description 240 | +- Simple Packet 241 | +- Enhanced Packet 242 | +- Interface Statistics 243 | 244 +- Name Resolution 246 Figure 2: Logical block Hierarchy of a pcapng file. 248 For example: each captured packet refers to a specific capture 249 interface, the interface itself refers to a specific section. 251 3.4. Physical File Layout 253 The file MUST begin with a Section Header Block. However, more than 254 one Section Header Block can be present on the dump, each one 255 covering the data following it till the next one (or the end of 256 file). A Section includes the data delimited by two Section Header 257 Blocks (or by a Section Header Block and the end of the file), 258 including the first Section Header Block. 260 In case an application cannot read a Section because of different 261 version number, it MUST skip everything until the next Section Header 262 Block. Note that, in order to properly skip the blocks until the 263 next section, all blocks MUST have the fields Type and Length at the 264 beginning. This is a mandatory requirement that MUST be maintained 265 in future versions of the block format. 267 Figure 3 shows a typical file configuration, with a single 268 Section Header that covers the whole file. 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | SHB v1.0 | Data | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 3: File structure example: Typical configuration with a single 275 Section Header Block. 277 Figure 4 shows a file that contains three headers, and is normally 278 the result of file concatenation. An application that understands 279 only version 1.0 of the file format skips the intermediate section 280 and restart processing the packets after the third Section Header. 282 |-- 1st Section --|-- 2nd Section --|-- 3rd Section --| 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 4: File structure example: three Section Header Blocks in a 289 single file. 291 Figure 5 shows a file comparable to a "classic libpcap" file - the 292 minimum for a useful capture file. It contains a single 293 Section Header Block (SHB), a single Interface Description Block 294 (IDB) and a few Enhanced Packet Blocks (EPB). 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | SHB | IDB | EPB | EPB | ... | EPB | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 5: File structure example: a pcapng file similar to a 301 classical libpcap file. 303 Figure 6 shows a complex example file. In addition to the minimum 304 file above, it contains packets captured from three interfaces, 305 capturing on the third of which begins after packets have arrived on 306 other interfaces, and also includes some Name Resolution Blocks (NRB) 307 and an Interface Statistics Block (ISB). 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | SHB | IDB | IDB | EPB | NRB |...| IDB | EPB | ISB | NRB | EPB | EPB | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 6: File structure example: more complex pcapng file. 315 The last example should make it obvious that the block structure 316 makes the file format very flexible compared to the classical libpcap 317 format. 319 3.5. Options 321 All the block bodies have the possibility to embed optional fields. 322 Optional fields can be used to insert some information that may be 323 useful when reading data, but that is not really needed for packet 324 processing. Therefore, each tool can either read the content of the 325 optional fields (if any), or skip some of them or even all at once. 327 Skipping all the optional fields at once is straightforward because 328 most of the blocks are made of a first part with fixed format, and a 329 second optional part. Therefore, the Block Length field (present in 330 the General Block Structure, see Section 3.1) can be used to skip 331 everything till the next block. 333 Options are a list of Type - Length - Value fields, each one 334 containing a single value: 336 o Option Type (2 bytes): it contains the code that specifies the 337 type of the current TLV record. Option types whose Most 338 Significant Bit is equal to one are reserved for local use; 339 therefore, there is no guarantee that the code used is unique 340 among all capture files (generated by other applications). In 341 case of vendor-specific extensions that have to be identified 342 uniquely, vendors MUST request an Option Code whose MSB is equal 343 to zero. 345 o Option Length (2 bytes): it contains the actual length of the 346 following 'Option Value' field without the padding bytes. 348 o Option Value (variable length): it contains the value of the given 349 option, aligned to a 32-bit boundary. The actual length of this 350 field (i.e. without the padding bytes) is specified by the Option 351 Length field. 353 If an option's value is a string, the value is not necessarily zero- 354 terminated. Software that reads these files MUST NOT assume that 355 strings are zero-terminated, and MUST treat a zero byte as a string 356 terminator. 358 Options may be repeated several times (e.g. an interface that has 359 several IP addresses associated to it) TODO: mention for each option, 360 if it can/shouldn't appear more than one time. The option list is 361 terminated by a Option which uses the special 'End of Option' code 362 (opt_endofopt). 364 The format of the optional fields is shown in Figure 7. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Option Code | Option Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 / Option Value / 372 / variable length, aligned to 32 bits / 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 / / 375 / . . . other options . . . / 376 / / 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Option Code == opt_endofopt | Option Length == 0 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 7: Options format. 383 The following codes can always be present in any optional field: 385 +--------------+------+----------+-------------+--------------------+ 386 | Name | Code | Length | Description | Example(s) | 387 +--------------+------+----------+-------------+--------------------+ 388 | opt_endofopt | 0 | 0 | It delimits | | 389 | | | | the end of | | 390 | | | | the | | 391 | | | | optional | | 392 | | | | fields. | | 393 | | | | This block | | 394 | | | | cannot be | | 395 | | | | repeated | | 396 | | | | within a | | 397 | | | | given list | | 398 | | | | of options. | | 399 | opt_comment | 1 | variable | A UTF-8 | "This packet is | 400 | | | | string | the beginning of | 401 | | | | containing | all of our | 402 | | | | a comment | problems" / | 403 | | | | that is | "Packets 17-23 | 404 | | | | associated | showing a bogus | 405 | | | | to the | TCP | 406 | | | | current | retransmission, as | 407 | | | | block. | reported in | 408 | | | | | bugzilla entry | 409 | | | | | 1486!" / "Captured | 410 | | | | | at the southern | 411 | | | | | plant" / "I've | 412 | | | | | checked again, now | 413 | | | | | it's working ok" / | 414 | | | | | ... | 415 +--------------+------+----------+-------------+--------------------+ 417 3.6. Data format 419 Endianess 421 Data contained in each section will always be saved according to the 422 characteristics (little endian / big endian) of the dumping machine. 423 This refers to all the fields that are saved as numbers and that span 424 over two or more bytes. 426 The approach of having each section saved in the native format of the 427 generating host is more efficient because it avoids translation of 428 data when reading / writing on the host itself, which is the most 429 common case when generating/processing capture dumps. 431 Please note: The endianess is indicated by the Section Header Block 432 (Section 4.1). As this block can appear several times in a pcapng 433 file, a single file can contain both endianess variants! 435 Alignment 437 All fields of this specification uses proper alignment for 16- and 438 32-bit values. This makes it easier and faster to read/write file 439 contents if using techniques like memory mapped files. 441 The alignment bytes (marked in this document e.g. with "aligned to 32 442 bits") MUST be filled with zero bytes. 444 Please note: 64-bit values are not aligned to 64-bit boundaries. 445 This is because the file is naturally aligned to 32-bit boundaries 446 only. Special care MUST be taken when reading and writing such 447 values. TODO: the spec is not too consistent wrt how 64-bit values 448 are saved. in the Packet blocks we clearly specify where the low and 449 high 32-bits of a 64-bit timestamp should be saved. In the SHB we do 450 use the endianess of the machine when we save the section length. 452 4. Block Definition 454 This section details the format of the body of the blocks currently 455 defined. 457 4.1. Section Header Block (mandatory) 459 The Section Header Block is mandatory. It identifies the beginning 460 of a section of the capture dump file. The Section Header Block does 461 not contain data but it rather identifies a list of blocks 462 (interfaces, packets) that are logically correlated. Its format is 463 shown in Figure 8. 465 0 1 2 3 466 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 467 +---------------------------------------------------------------+ 468 0 | Block Type = 0x0A0D0D0A | 469 +---------------------------------------------------------------+ 470 4 | Block Total Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 8 | Byte-Order Magic | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 12 | Major Version | Minor Version | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 16 | | 477 | Section Length | 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 24 / / 481 / Options (variable) / 482 / / 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Block Total Length | 485 +---------------------------------------------------------------+ 487 Figure 8: Section Header Block format. 489 The meaning of the fields is: 491 o Block Type: The block type of the Section Header Block is the 492 integer corresponding to the 4-char string "\r\n\n\r" 493 (0x0A0D0D0A). This particular value is used for 2 reasons: 495 1. This number is used to detect if a file has been transferred 496 via FTP or HTTP from a machine to another with an 497 inappropriate ASCII conversion. In this case, the value of 498 this field will differ from the standard one ("\r\n\n\r") and 499 the reader can detect a possibly corrupted file. 501 2. This value is palindromic, so that the reader is able to 502 recognize the Section Header Block regardless of the endianess 503 of the section. The endianess is recognized by reading the 504 Byte Order Magic, that is located 8 bytes after the Block 505 Type. 507 o Block Total Length: total size of this block, as described in 508 Section 3.1. 510 o Byte-Order Magic: magic number, whose value is the hexadecimal 511 number 0x1A2B3C4D. This number can be used to distinguish 512 sections that have been saved on little-endian machines from the 513 ones saved on big-endian machines. 515 o Major Version: number of the current mayor version of the format. 516 Current value is 1. This value should change if the format 517 changes in such a way that tools that can read the new format 518 could not read the old format (i.e., the code would have to check 519 the version number to be able to read both formats). 521 o Minor Version: number of the current minor version of the format. 522 Current value is 0. This value should change if the format 523 changes in such a way that tools that can read the new format can 524 still automatically read the new format but code that can only 525 read the old format cannot read the new format. 527 o Section Length: 64-bit value specifying the length in bytes of the 528 following section, excluding the Section Header Block itself. 529 This field can be used to skip the section, for faster navigation 530 inside large files. Section Length equal -1 (0xFFFFFFFFFFFFFFFF) 531 means that the size of the section is not specified, and the only 532 way to skip the section is to parse the blocks that it contains. 533 Please note that if this field is valid (i.e. not -1), its value 534 is always aligned to 32 bits, as all the blocks are aligned to 535 32-bit boundaries. Also, special care should be taken in 536 accessing this field: since the alignment of all the blocks in the 537 file is 32-bit, this field is not guaranteed to be aligned to a 538 64-bit boundary. This could be a problem on 64-bit workstations. 540 o Options: optionally, a list of options (formatted according to the 541 rules defined in Section 3.5) can be present. 543 Adding new block types or options would not necessarily require that 544 either Major or Minor numbers be changed, as code that does not know 545 about the block type or option could just skip it; only if skipping a 546 block or option does not work should the minor version number be 547 changed. 549 Aside from the options defined in Section 3.5, the following options 550 are valid within this block: 552 +--------------+------+----------+-------------------+--------------+ 553 | Name | Code | Length | Description | Example(s) | 554 +--------------+------+----------+-------------------+--------------+ 555 | shb_hardware | 2 | variable | An UTF-8 string | "x86 | 556 | | | | containing the | Personal | 557 | | | | description of | Computer" / | 558 | | | | the hardware used | "Sun Sparc | 559 | | | | to create this | Workstation" | 560 | | | | section. | / ... | 561 | shb_os | 3 | variable | An UTF-8 string | "Windows XP | 562 | | | | containing the | SP2" / | 563 | | | | name of the | "openSUSE | 564 | | | | operating system | 10.2" / ... | 565 | | | | used to create | | 566 | | | | this section. | | 567 | shb_userappl | 4 | variable | An UTF-8 string | "dumpcap | 568 | | | | containing the | V0.99.7" / | 569 | | | | name of the | ... | 570 | | | | application used | | 571 | | | | to create this | | 572 | | | | section. | | 573 +--------------+------+----------+-------------------+--------------+ 575 4.2. Interface Description Block (mandatory) 577 The Interface Description Block is mandatory. This block is needed 578 to specify the characteristics of the network interface on which the 579 capture has been made. In order to properly associate the captured 580 data to the corresponding interface, the Interface Description Block 581 MUST be defined before any other block that uses it; therefore, this 582 block is usually placed immediately after the Section Header Block. 583 However, if capturing on an interface starts in the middle of a 584 capture, an Interface Description Block can appear after other 585 blocks, including blocks for packets on interfaces for which 586 Interface Description Blocks have already appeared. 588 An Interface Description Block is valid only inside the section which 589 it belongs to. The structure of a Interface Description Block is 590 shown in Figure 9. 592 0 1 2 3 593 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 594 +---------------------------------------------------------------+ 595 0 | Block Type = 0x00000001 | 596 +---------------------------------------------------------------+ 597 4 | Block Total Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 8 | LinkType | Reserved | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 12 | SnapLen | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 16 / / 604 / Options (variable) / 605 / / 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Block Total Length | 608 +---------------------------------------------------------------+ 610 Figure 9: Interface Description Block format. 612 The meaning of the fields is: 614 o Block Type: The block type of the Interface Description Block is 615 1. 617 o Block Total Length: total size of this block, as described in 618 Section 3.1. 620 o LinkType: a value that defines the link layer type of this 621 interface. The list of Standardized Link Layer Type codes is 622 available in the tcpdump.org link-layer header types registry [1]. 624 o SnapLen: maximum number of bytes dumped from each packet. The 625 portion of each packet that exceeds this value will not be stored 626 in the file. A value of zero indicates no limit. 628 o Options: optionally, a list of options (formatted according to the 629 rules defined in Section 3.5) can be present. 631 Interface ID: Tools that write / read the capture file associate a 632 progressive 32-bit number (starting from '0') to each Interface 633 Definition Block. This number is unique within each Section and 634 uniquely identifies the interface (inside the current section); 635 therefore, two Sections can have interfaces identified by the same 636 identifiers. This unique identifier is referenced by other blocks 637 (e.g. Packet Block) to point out the interface the block refers to 638 (e.g. the interface that was used to capture the packet). 640 In addition to the options defined in Section 3.5, the following 641 options are valid within this block: 643 +----------+----+-------+-----------+-------------------------------+ 644 | Name | Co | Lengt | Descripti | Example(s) | 645 | | de | h | on | | 646 +----------+----+-------+-----------+-------------------------------+ 647 | if_name | 2 | Varia | A UTF-8 | "eth0" / "\Device\NPF_{AD1CE6 | 648 | | | ble | string co | 75-96D0-47C5-ADD0-2504B9126B6 | 649 | | | | ntaining | 8}" / ... | 650 | | | | the name | | 651 | | | | of the | | 652 | | | | device | | 653 | | | | used to | | 654 | | | | capture | | 655 | | | | data. | | 656 | if_descr | 3 | Varia | A UTF-8 | "Broadcom NetXtreme" / "First | 657 | iption | | ble | string co | Ethernet Interface" / ... | 658 | | | | ntaining | | 659 | | | | the descr | | 660 | | | | iption of | | 661 | | | | the | | 662 | | | | device | | 663 | | | | used to | | 664 | | | | capture | | 665 | | | | data. | | 666 | if_IPv4a | 4 | 8 | Interface | 192 168 1 1 255 255 255 0 | 667 | ddr | | | network | | 668 | | | | address | | 669 | | | | and | | 670 | | | | netmask. | | 671 | | | | This | | 672 | | | | option | | 673 | | | | can be | | 674 | | | | repeated | | 675 | | | | multiple | | 676 | | | | times | | 677 | | | | within | | 678 | | | | the same | | 679 | | | | Interface | | 680 | | | | Descripti | | 681 | | | | on Block | | 682 | | | | when | | 683 | | | | multiple | | 684 | | | | IPv4 | | 685 | | | | addresses | | 686 | | | | are | | 687 | | | | assigned | | 688 | | | | to the in | | 689 | | | | terface. | | 690 | if_IPv6a | 5 | 17 | Interface | 2001:0db8:85a3:08d3:1319:8a2e | 691 | ddr | | | network | :0370:7344/64 is written (in | 692 | | | | address | hex) as "20 01 0d b8 85 a3 08 | 693 | | | | and | d3 13 19 8a 2e 03 70 73 44 | 694 | | | | prefix | 40" | 695 | | | | length | | 696 | | | | (stored | | 697 | | | | in the | | 698 | | | | last | | 699 | | | | byte). | | 700 | | | | This | | 701 | | | | option | | 702 | | | | can be | | 703 | | | | repeated | | 704 | | | | multiple | | 705 | | | | times | | 706 | | | | within | | 707 | | | | the same | | 708 | | | | Interface | | 709 | | | | Descripti | | 710 | | | | on Block | | 711 | | | | when | | 712 | | | | multiple | | 713 | | | | IPv6 | | 714 | | | | addresses | | 715 | | | | are | | 716 | | | | assigned | | 717 | | | | to the in | | 718 | | | | terface. | | 719 | if_MACad | 6 | 6 | Interface | 00 01 02 03 04 05 | 720 | dr | | | Hardware | | 721 | | | | MAC | | 722 | | | | address | | 723 | | | | (48 | | 724 | | | | bits). | | 725 | if_EUIad | 7 | 8 | Interface | 02 34 56 FF FE 78 9A BC | 726 | dr | | | Hardware | | 727 | | | | EUI | | 728 | | | | address | | 729 | | | | (64 | | 730 | | | | bits), if | | 731 | | | | available | | 732 | | | | . | | 733 | if_speed | 8 | 8 | Interface | 100000000 for 100Mbps | 734 | | | | speed (in | | 735 | | | | bps). | | 736 | if_tsres | 9 | 1 | Resolutio | 6 | 737 | ol | | | n of time | | 738 | | | | stamps. | | 739 | | | | If the | | 740 | | | | Most Sign | | 741 | | | | ificant | | 742 | | | | Bit is | | 743 | | | | equal to | | 744 | | | | zero, the | | 745 | | | | remaining | | 746 | | | | bits | | 747 | | | | indicates | | 748 | | | | the resol | | 749 | | | | ution of | | 750 | | | | the | | 751 | | | | timestamp | | 752 | | | | as as a | | 753 | | | | negative | | 754 | | | | power of | | 755 | | | | 10 (e.g. | | 756 | | | | 6 means m | | 757 | | | | icrosecon | | 758 | | | | d resolut | | 759 | | | | ion, time | | 760 | | | | stamps | | 761 | | | | are the | | 762 | | | | number of | | 763 | | | | microseco | | 764 | | | | nds since | | 765 | | | | 1/1/1970) | | 766 | | | | . If the | | 767 | | | | Most Sign | | 768 | | | | ificant | | 769 | | | | Bit is | | 770 | | | | equal to | | 771 | | | | one, the | | 772 | | | | remaining | | 773 | | | | bits | | 774 | | | | indicates | | 775 | | | | the resol | | 776 | | | | ution as | | 777 | | | | as | | 778 | | | | negative | | 779 | | | | power of | | 780 | | | | 2 (e.g. | | 781 | | | | 10 means | | 782 | | | | 1/1024 of | | 783 | | | | second). | | 784 | | | | If this | | 785 | | | | option is | | 786 | | | | not | | 787 | | | | present, | | 788 | | | | a resolut | | 789 | | | | ion of | | 790 | | | | 10^-6 is | | 791 | | | | assumed | | 792 | | | | (i.e. tim | | 793 | | | | estamps | | 794 | | | | have the | | 795 | | | | same reso | | 796 | | | | lution of | | 797 | | | | the | | 798 | | | | standard | | 799 | | | | 'libpcap' | | 800 | | | | timestamp | | 801 | | | | s). | | 802 | if_tzone | 10 | 4 | Time zone | TODO: give a good example | 803 | | | | for GMT | | 804 | | | | support | | 805 | | | | (TODO: | | 806 | | | | specify | | 807 | | | | better). | | 808 | if_filte | 11 | varia | The | 00 "tcp port 23 and host | 809 | r | | ble | filter | 192.0.2.5" | 810 | | | | (e.g. | | 811 | | | | "capture | | 812 | | | | only TCP | | 813 | | | | traffic") | | 814 | | | | used to | | 815 | | | | capture | | 816 | | | | traffic. | | 817 | | | | The first | | 818 | | | | byte of | | 819 | | | | the | | 820 | | | | Option | | 821 | | | | Data | | 822 | | | | keeps a | | 823 | | | | code of | | 824 | | | | the | | 825 | | | | filter | | 826 | | | | used | | 827 | | | | (e.g. if | | 828 | | | | this is a | | 829 | | | | libpcap | | 830 | | | | string, | | 831 | | | | or BPF | | 832 | | | | bytecode, | | 833 | | | | and | | 834 | | | | more). | | 835 | | | | More | | 836 | | | | details | | 837 | | | | about | | 838 | | | | this | | 839 | | | | format | | 840 | | | | will be | | 841 | | | | presented | | 842 | | | | in | | 843 | | | | Appendix | | 844 | | | | XXX | | 845 | | | | (TODO). | | 846 | | | | (TODO: | | 847 | | | | better | | 848 | | | | use | | 849 | | | | different | | 850 | | | | options | | 851 | | | | for | | 852 | | | | different | | 853 | | | | fields? | | 854 | | | | e.g. if_f | | 855 | | | | ilter_pca | | 856 | | | | p, if_fil | | 857 | | | | ter_bpf, | | 858 | | | | ...) | | 859 | if_os | 12 | varia | A UTF-8 | "Windows XP SP2" / "openSUSE | 860 | | | ble | string co | 10.2" / ... | 861 | | | | ntaining | | 862 | | | | the name | | 863 | | | | of the | | 864 | | | | operating | | 865 | | | | system of | | 866 | | | | the | | 867 | | | | machine | | 868 | | | | in which | | 869 | | | | this | | 870 | | | | interface | | 871 | | | | is instal | | 872 | | | | led. This | | 873 | | | | can be | | 874 | | | | different | | 875 | | | | from the | | 876 | | | | same info | | 877 | | | | rmation | | 878 | | | | that can | | 879 | | | | be | | 880 | | | | contained | | 881 | | | | by the | | 882 | | | | Section | | 883 | | | | Header | | 884 | | | | Block | | 885 | | | | (Section | | 886 | | | | 4.1) | | 887 | | | | because | | 888 | | | | the | | 889 | | | | capture | | 890 | | | | can have | | 891 | | | | been done | | 892 | | | | on a | | 893 | | | | remote | | 894 | | | | machine. | | 895 | if_fcsle | 13 | 1 | An | 4 | 896 | n | | | integer | | 897 | | | | value | | 898 | | | | that | | 899 | | | | specified | | 900 | | | | the | | 901 | | | | length of | | 902 | | | | the Frame | | 903 | | | | Check | | 904 | | | | Sequence | | 905 | | | | (in bits) | | 906 | | | | for this | | 907 | | | | interface | | 908 | | | | . For | | 909 | | | | link | | 910 | | | | layers | | 911 | | | | whose FCS | | 912 | | | | length | | 913 | | | | can | | 914 | | | | change | | 915 | | | | during | | 916 | | | | time, the | | 917 | | | | Packet | | 918 | | | | Block | | 919 | | | | Flags | | 920 | | | | Word can | | 921 | | | | be used | | 922 | | | | (see | | 923 | | | | Appendix | | 924 | | | | A). | | 925 | if_tsoff | 14 | 8 | A 64-bit | 1234 | 926 | set | | | integer | | 927 | | | | value | | 928 | | | | that | | 929 | | | | specifies | | 930 | | | | an offset | | 931 | | | | (in | | 932 | | | | seconds) | | 933 | | | | that must | | 934 | | | | be added | | 935 | | | | to the | | 936 | | | | timestamp | | 937 | | | | of each | | 938 | | | | packet to | | 939 | | | | obtain | | 940 | | | | the | | 941 | | | | absolute | | 942 | | | | timestamp | | 943 | | | | of a | | 944 | | | | packet. | | 945 | | | | If the | | 946 | | | | option is | | 947 | | | | missing, | | 948 | | | | the times | | 949 | | | | tamps | | 950 | | | | stored in | | 951 | | | | the | | 952 | | | | packet | | 953 | | | | MUST be c | | 954 | | | | onsidered | | 955 | | | | absolute | | 956 | | | | timestamp | | 957 | | | | s. The | | 958 | | | | time zone | | 959 | | | | of the | | 960 | | | | offset | | 961 | | | | can be | | 962 | | | | specified | | 963 | | | | with the | | 964 | | | | option | | 965 | | | | if_tzone. | | 966 | | | | TODO: | | 967 | | | | won't a i | | 968 | | | | f_tsoffse | | 969 | | | | t_low for | | 970 | | | | fractiona | | 971 | | | | l second | | 972 | | | | offsets | | 973 | | | | be useful | | 974 | | | | for | | 975 | | | | highly sy | | 976 | | | | ncronized | | 977 | | | | capture | | 978 | | | | systems? | | 979 +----------+----+-------+-----------+-------------------------------+ 981 4.3. Enhanced Packet Block (optional) 983 An Enhanced Packet Block is the standard container for storing the 984 packets coming from the network. The Enhanced Packet Block is 985 optional because packets can be stored either by means of this block 986 or the Simple Packet Block, which can be used to speed up dump 987 generation. The format of an Enhanced Packet Block is shown in 988 Figure 10. 990 The Enhanced Packet Block is an improvement over the original Packet 991 Block (Section 4.5): 993 o it stores the Interface Identifier as a 32-bit integer value. 994 This is a requirement when a capture stores packets coming from a 995 large number of interfaces 997 o differently from the Packet Block (Section 4.5), the number of 998 packets dropped by the capture system between this packet and the 999 previous one is not stored in the header, but rather in an option 1000 of the block itself. 1002 0 1 2 3 1003 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 1004 +---------------------------------------------------------------+ 1005 0 | Block Type = 0x00000006 | 1006 +---------------------------------------------------------------+ 1007 4 | Block Total Length | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 8 | Interface ID | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 12 | Timestamp (High) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 16 | Timestamp (Low) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 20 | Captured Len | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 24 | Packet Len | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 28 / / 1020 / Packet Data / 1021 / variable length, aligned to 32 bits / 1022 / / 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 / / 1025 / Options (variable) / 1026 / / 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Block Total Length | 1029 +---------------------------------------------------------------+ 1031 Figure 10: Enhanced Packet Block format. 1033 The Enhanced Packet Block has the following fields: 1035 o Block Type: The block type of the Enhanced Packet Block is 6. 1037 o Block Total Length: total size of this block, as described in 1038 Section 3.1. 1040 o Interface ID: it specifies the interface this packet comes from; 1041 the correct interface will be the one whose Interface Description 1042 Block (within the current Section of the file) is identified by 1043 the same number (see Section 4.2) of this field. The interface ID 1044 MUST be valid, which means that an matching interface description 1045 block MUST exist. 1047 o Timestamp (High) and Timestamp (Low): high and low 32-bits of a 1048 64-bit quantity representing the timestamp. The timestamp is a 1049 single 64-bit unsigned integer representing the number of units 1050 since 1/1/1970 00:00:00 UTC. The way to interpret this field is 1051 specified by the 'if_tsresol' option (see Figure 9) of the 1052 Interface Description block referenced by this packet. Please 1053 note that differently from the libpcap file format, timestamps are 1054 not saved as two 32-bit values accounting for the seconds and 1055 microseconds since 1/1/1970. They are saved as a single 64-bit 1056 quantity saved as two 32-bit words. 1058 o Captured Len: number of bytes captured from the packet (i.e. the 1059 length of the Packet Data field). It will be the minimum value 1060 among the actual Packet Length and the snapshot length (defined in 1061 Figure 9). The value of this field does not include the padding 1062 bytes added at the end of the Packet Data field to align the 1063 Packet Data Field to a 32-bit boundary. 1065 o Packet Len: actual length of the packet when it was transmitted on 1066 the network. It can be different from Captured Len if the user 1067 wants only a snapshot of the packet. 1069 o Packet Data: the data coming from the network, including link- 1070 layer headers. The actual length of this field is Captured Len. 1071 The format of the link-layer headers depends on the LinkType field 1072 specified in the Interface Description Block (see Section 4.2) and 1073 it is specified in the entry for that format in the the 1074 tcpdump.org link-layer header types registry [2]. 1076 o Options: optionally, a list of options (formatted according to the 1077 rules defined in Section 3.5) can be present. 1079 In addition to the options defined in Section 3.5 and in the Packet 1080 Block (Table 1), the following options are valid within this block: 1082 +---------------+------+----------+--------------------+------------+ 1083 | Name | Code | Length | Description | Example(s) | 1084 +---------------+------+----------+--------------------+------------+ 1085 | epb_flags | 2 | 4 | A flags word | 0 | 1086 | | | | containing link- | | 1087 | | | | layer information. | | 1088 | | | | A complete | | 1089 | | | | specification of | | 1090 | | | | the allowed flags | | 1091 | | | | can be found in | | 1092 | | | | Appendix A. | | 1093 | epb_hash | 3 | variable | This option | 2 EC 1D 87 | 1094 | | | | contains a hash of | 97 / 3 45 | 1095 | | | | the packet. The | 6e c2 17 | 1096 | | | | first byte | 7c 10 1e | 1097 | | | | specifies the | 3c 2e 99 | 1098 | | | | hashing algorithm, | 6e c2 9a | 1099 | | | | while the | 3d 50 8e | 1100 | | | | following bytes | | 1101 | | | | contain the actual | | 1102 | | | | hash, whose size | | 1103 | | | | depends on the | | 1104 | | | | hashing algorithm, | | 1105 | | | | and hence from the | | 1106 | | | | value in the first | | 1107 | | | | byte. The hashing | | 1108 | | | | algorithm can be: | | 1109 | | | | 2s complement | | 1110 | | | | (algorithm byte = | | 1111 | | | | 0, size=XXX), XOR | | 1112 | | | | (algorithm byte = | | 1113 | | | | 1, size=XXX), | | 1114 | | | | CRC32 (algorithm | | 1115 | | | | byte = 2, size = | | 1116 | | | | 4), MD-5 | | 1117 | | | | (algorithm byte = | | 1118 | | | | 3, size=XXX), | | 1119 | | | | SHA-1 (algorithm | | 1120 | | | | byte = 4, | | 1121 | | | | size=XXX). The | | 1122 | | | | hash covers only | | 1123 | | | | the packet, not | | 1124 | | | | the header added | | 1125 | | | | by the capture | | 1126 | | | | driver: this gives | | 1127 | | | | the possibility to | | 1128 | | | | calculate it | | 1129 | | | | inside the network | | 1130 | | | | card. The hash | | 1131 | | | | allows easier | | 1132 | | | | comparison/merging | | 1133 | | | | of different | | 1134 | | | | capture files, and | | 1135 | | | | reliable data | | 1136 | | | | transfer between | | 1137 | | | | the data | | 1138 | | | | acquisition system | | 1139 | | | | and the capture | | 1140 | | | | library. (TODO: | | 1141 | | | | the text above | | 1142 | | | | uses "first bit", | | 1143 | | | | but shouldn't this | | 1144 | | | | be "first | | 1145 | | | | byte"?!?) | | 1146 | epb_dropcount | 4 | 8 | A 64-bit integer | 0 | 1147 | | | | value specifying | | 1148 | | | | the number of | | 1149 | | | | packets lost (by | | 1150 | | | | the interface and | | 1151 | | | | the operating | | 1152 | | | | system) between | | 1153 | | | | this packet and | | 1154 | | | | the preceding one. | | 1155 +---------------+------+----------+--------------------+------------+ 1157 4.4. Simple Packet Block (optional) 1159 The Simple Packet Block is a lightweight container for storing the 1160 packets coming from the network. Its presence is optional. 1162 A Simple Packet Block is similar to a Packet Block (see Section 4.5), 1163 but it is smaller, simpler to process and contains only a minimal set 1164 of information. This block is preferred to the standard Packet Block 1165 when performance or space occupation are critical factors, such as in 1166 sustained traffic dump applications. A capture file can contain both 1167 Packet Blocks and Simple Packet Blocks: for example, a capture tool 1168 could switch from Packet Blocks to Simple Packet Blocks when the 1169 hardware resources become critical. 1171 The Simple Packet Block does not contain the Interface ID field. 1172 Therefore, it MUST be assumed that all the Simple Packet Blocks have 1173 been captured on the interface previously specified in the first 1174 Interface Description Block. 1176 Figure 11 shows the format of the Simple Packet Block. 1178 0 1 2 3 1179 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 1180 +---------------------------------------------------------------+ 1181 0 | Block Type = 0x00000003 | 1182 +---------------------------------------------------------------+ 1183 4 | Block Total Length | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 8 | Packet Len | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 12 / / 1188 / Packet Data / 1189 / variable length, aligned to 32 bits / 1190 / / 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Block Total Length | 1193 +---------------------------------------------------------------+ 1195 Figure 11: Simple Packet Block format. 1197 The Simple Packet Block has the following fields: 1199 o Block Type: The block type of the Simple Packet Block is 3. 1201 o Block Total Length: total size of this block, as described in 1202 Section 3.1. 1204 o Packet Len: actual length of the packet when it was transmitted on 1205 the network. Can be different from captured len if the packet has 1206 been truncated by the capture process. 1208 o Packet Data: the data coming from the network, including link- 1209 layer headers. The length of this field can be derived from the 1210 field Block Total Length, present in the Block Header, and it is 1211 the minimum value among the SnapLen (present in the Interface 1212 Description Block) and the Packet Len (present in this header). 1213 The format of the link-layer headers depends on the LinkType field 1214 specified in the Interface Description Block (see Section 4.2) and 1215 it is specified in the entry for that format in the the 1216 tcpdump.org link-layer header types registry [3]. 1218 The Simple Packet Block does not contain the timestamp because this 1219 is often one of the most costly operations on PCs. Additionally, 1220 there are applications that do not require it; e.g. an Intrusion 1221 Detection System is interested in packets, not in their timestamp. 1223 A Simple Packet Block cannot be present in a Section that has more 1224 than one interface because of the impossibility to refer to the 1225 correct one (it does not contain any Interface ID field). 1227 The Simple Packet Block is very efficient in term of disk space: a 1228 snapshot whose length is 100 bytes requires only 16 bytes of 1229 overhead, which corresponds to an efficiency of more than 86%. 1231 4.5. Packet Block (obsolete!) 1233 The Packet Block is marked obsolete, better use the Enhanced Packet 1234 Block instead! 1236 A Packet Block is the standard container for storing the packets 1237 coming from the network. The Packet Block is optional because 1238 packets can be stored either by means of this block or the Simple 1239 Packet Block, which can be used to speed up dump generation. The 1240 format of a packet block is shown in Figure 12. 1242 0 1 2 3 1243 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 1244 +---------------------------------------------------------------+ 1245 0 | Block Type = 0x00000002 | 1246 +---------------------------------------------------------------+ 1247 4 | Block Total Length | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 8 | Interface ID | Drops Count | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 12 | Timestamp (High) | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 16 | Timestamp (Low) | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 20 | Captured Len | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 24 | Packet Len | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 28 / / 1260 / Packet Data / 1261 / variable length, aligned to 32 bits / 1262 / / 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 / / 1265 / Options (variable) / 1266 / / 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Block Total Length | 1269 +---------------------------------------------------------------+ 1271 Figure 12: Packet Block format. 1273 The Packet Block has the following fields: 1275 o Block Type: The block type of the Packet Block is 2. 1277 o Block Total Length: total size of this block, as described in 1278 Section 3.1. 1280 o Interface ID: it specifies the interface this packet comes from; 1281 the correct interface will be the one whose Interface Description 1282 Block (within the current Section of the file) is identified by 1283 the same number (see Section 4.2) of this field. The interface ID 1284 MUST be valid, which means that an matching interface description 1285 block MUST exist. 1287 o Drops Count: a local drop counter. It specifies the number of 1288 packets lost (by the interface and the operating system) between 1289 this packet and the preceding one. The value xFFFF (in 1290 hexadecimal) is reserved for those systems in which this 1291 information is not available. 1293 o Timestamp (High) and Timestamp (Low): timestamp of the packet. 1294 The format of the timestamp is the same already defined in the 1295 Enhanced Packet Block (Section 4.3). 1297 o Captured Len: number of bytes captured from the packet (i.e. the 1298 length of the Packet Data field). It will be the minimum value 1299 among the actual Packet Length and the snapshot length (SnapLen 1300 defined in Figure 9). The value of this field does not include 1301 the padding bytes added at the end of the Packet Data field to 1302 align the Packet Data Field to a 32-bit boundary. 1304 o Packet Len: actual length of the packet when it was transmitted on 1305 the network. Can be different from Captured Len if the user wants 1306 only a snapshot of the packet. 1308 o Packet Data: the data coming from the network, including link- 1309 layer headers. The actual length of this field is Captured Len. 1310 The format of the link-layer headers depends on the LinkType field 1311 specified in the Interface Description Block (see Section 4.2) and 1312 it is specified in the entry for that format in the the 1313 tcpdump.org link-layer header types registry [4]. 1315 o Options: optionally, a list of options (formatted according to the 1316 rules defined in Section 3.5) can be present. 1318 In addition to the options defined in Section 3.5, the following 1319 options are valid within this block: 1321 +------------+------+----------+----------------+-------------------+ 1322 | Name | Code | Length | Description | Example(s) | 1323 +------------+------+----------+----------------+-------------------+ 1324 | pack_flags | 2 | 4 | Same as | 0 | 1325 | | | | epb_flags of | | 1326 | | | | the enhanced | | 1327 | | | | packet block. | | 1328 | pack_hash | 3 | variable | Same as | 2 EC 1D 87 97 / 3 | 1329 | | | | epb_hash of | 45 6e c2 17 7c 10 | 1330 | | | | the enhanced | 1e 3c 2e 99 6e c2 | 1331 | | | | packet block. | 9a 3d 50 8e | 1332 +------------+------+----------+----------------+-------------------+ 1334 Table 1 1336 4.6. Name Resolution Block (optional) 1338 The Name Resolution Block is used to support the correlation of 1339 numeric addresses (present in the captured packets) and their 1340 corresponding canonical names and it is optional. Having the literal 1341 names saved in the file, this prevents the need of a name resolution 1342 in a delayed time, when the association between names and addresses 1343 can be different from the one in use at capture time. Moreover, the 1344 Name Resolution Block avoids the need of issuing a lot of DNS 1345 requests every time the trace capture is opened, and allows to have 1346 name resolution also when reading the capture with a machine not 1347 connected to the network. 1349 A Name Resolution Block is normally placed at the beginning of the 1350 file, but no assumptions can be taken about its position. Name 1351 Resolution Blocks can be added in a second time by tools that process 1352 the file, like network analyzers. 1354 The format of the Name Resolution Block is shown in Figure 13. 1356 0 1 2 3 1357 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 1358 +---------------------------------------------------------------+ 1359 0 | Block Type = 0x00000004 | 1360 +---------------------------------------------------------------+ 1361 4 | Block Total Length | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 8 | Record Type | Record Value Length | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 12 / Record Value / 1366 / variable length, aligned to 32 bits / 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 . . 1369 . . . . other records . . . . 1370 . . 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Record Type == end_of_recs | Record Value Length == 00 | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 / / 1375 / Options (variable) / 1376 / / 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Block Total Length | 1379 +---------------------------------------------------------------+ 1381 Figure 13: Name Resolution Block format. 1383 The Name Resolution Block has the following fields: 1385 o Block Type: The block type of the Name Resolution Block is 4. 1387 o Block Total Length: total size of this block, as described in 1388 Section 3.1. 1390 This is followed by a zero-terminated list of records (in the TLV 1391 format), each of which contains an association between a network 1392 address and a name. There are three possible types of records: 1394 +-----------------+------+----------+-----------------+-------------+ 1395 | Name | Code | Length | Description | Example(s) | 1396 +-----------------+------+----------+-----------------+-------------+ 1397 | nres_endofrecor | 0 | 0 | It delimits the | | 1398 | d | | | end of name | | 1399 | | | | resolution | | 1400 | | | | records. This | | 1401 | | | | record is | | 1402 | | | | needed to | | 1403 | | | | determine when | | 1404 | | | | the list of | | 1405 | | | | name resolution | | 1406 | | | | records has | | 1407 | | | | ended and some | | 1408 | | | | options (if | | 1409 | | | | any) begin. | | 1410 | nres_ip4record | 1 | Variable | Specifies an | 127 0 0 1 | 1411 | | | | IPv4 address | "localhost" | 1412 | | | | (contained in | | 1413 | | | | the first 4 | | 1414 | | | | bytes), | | 1415 | | | | followed by one | | 1416 | | | | or more zero- | | 1417 | | | | terminated | | 1418 | | | | strings | | 1419 | | | | containing the | | 1420 | | | | DNS entries for | | 1421 | | | | that address. | | 1422 | nres_ip6record | 2 | Variable | Specifies an | 20 01 0d b8 | 1423 | | | | IPv6 address | 00 00 00 00 | 1424 | | | | (contained in | 00 00 00 00 | 1425 | | | | the first 16 | 12 34 56 78 | 1426 | | | | bytes), | "somehost" | 1427 | | | | followed by one | | 1428 | | | | or more zero- | | 1429 | | | | terminated | | 1430 | | | | strings | | 1431 | | | | containing the | | 1432 | | | | DNS entries for | | 1433 | | | | that address. | | 1434 +-----------------+------+----------+-----------------+-------------+ 1436 Table 2 1438 Each Record Value is aligned to a 32-bit boundary. The corresponding 1439 Record Value Length reflects the actual length of the Record Value; 1440 it does not include the lengths of the Record Type or the Record 1441 Value Length. 1443 After the list of Name Resolution Records, optionally, a list of 1444 options (formatted according to the rules defined in Section 3.5) can 1445 be present. 1447 In addiction to the options defined in Section 3.5, the following 1448 options are valid within this block: 1450 +---------------+------+----------+--------------+------------------+ 1451 | Name | Code | Length | Description | Example(s) | 1452 +---------------+------+----------+--------------+------------------+ 1453 | ns_dnsname | 2 | Variable | A UTF-8 | "our_nameserver" | 1454 | | | | string | | 1455 | | | | containing | | 1456 | | | | the name of | | 1457 | | | | the machine | | 1458 | | | | (DNS server) | | 1459 | | | | used to | | 1460 | | | | perform the | | 1461 | | | | name | | 1462 | | | | resolution. | | 1463 | ns_dnsIP4addr | 3 | 4 | The IPv4 | 192 168 0 1 | 1464 | | | | address of | | 1465 | | | | the DNS | | 1466 | | | | server. | | 1467 | ns_dnsIP6addr | 4 | 16 | The IPv6 | 20 01 0d b8 00 | 1468 | | | | address of | 00 00 00 00 00 | 1469 | | | | the DNS | 00 00 12 34 56 | 1470 | | | | server. | 78 | 1471 +---------------+------+----------+--------------+------------------+ 1473 4.7. Interface Statistics Block (optional) 1475 The Interface Statistics Block contains the capture statistics for a 1476 given interface and it is optional. The statistics are referred to 1477 the interface defined in the current Section identified by the 1478 Interface ID field. An Interface Statistics Block is normally placed 1479 at the end of the file, but no assumptions can be taken about its 1480 position - it can even appear multiple times for the same interface. 1482 The format of the Interface Statistics Block is shown in Figure 14. 1484 0 1 2 3 1485 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 1486 +---------------------------------------------------------------+ 1487 0 | Block Type = 0x00000005 | 1488 +---------------------------------------------------------------+ 1489 4 | Block Total Length | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 8 | Interface ID | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 12 | Timestamp (High) | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 16 | Timestamp (Low) | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 20 / / 1498 / Options (variable) / 1499 / / 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Block Total Length | 1502 +---------------------------------------------------------------+ 1504 Figure 14: Interface Statistics Block format. 1506 The fields have the following meaning: 1508 o Block Type: The block type of the Interface Statistics Block is 5. 1510 o Block Total Length: total size of this block, as described in 1511 Section 3.1. 1513 o Interface ID: it specifies the interface these statistics refers 1514 to; the correct interface will be the one whose Interface 1515 Description Block (within the current Section of the file) is 1516 identified by same number (see Section 4.2) of this field. Please 1517 note: in former versions of this document, this field was 16 bits 1518 only. As this differs from its usage in other places of this doc 1519 and as this block was not used "in the wild" before (as to the 1520 knowledge of the authors), it seems reasonable to change it to 32 1521 bits! 1523 o Timestamp: time this statistics refers to. The format of the 1524 timestamp is the same already defined in the Enhanced Packet Block 1525 (Section 4.3). 1527 o Options: optionally, a list of options (formatted according to the 1528 rules defined in Section 3.5) can be present. 1530 All the statistic fields are defined as options in order to deal with 1531 systems that do not have a complete set of statistics. Therefore, In 1532 addiction to the options defined in Section 3.5, the following 1533 options are valid within this block: 1535 +------------------+------+--------+-------------------+------------+ 1536 | Name | Code | Length | Description | | 1537 +------------------+------+--------+-------------------+------------+ 1538 | isb_starttime | 2 | 8 | Time in which the | 97 c3 04 | 1539 | | | | capture started; | 00 aa 47 | 1540 | | | | time will be | ca 64 | 1541 | | | | stored in two | (Little | 1542 | | | | blocks of four | Endian, | 1543 | | | | bytes each. The | decodes to | 1544 | | | | format of the | 06/29/2012 | 1545 | | | | timestamp is the | 06:16:50 | 1546 | | | | same already | UTC) | 1547 | | | | defined in the | | 1548 | | | | Enhanced Packet | | 1549 | | | | Block (Section | | 1550 | | | | 4.3). | | 1551 | isb_endtime | 3 | 8 | Time in which the | 96 c3 04 | 1552 | | | | capture ended; ; | 00 73 89 | 1553 | | | | time will be | 6a 65 | 1554 | | | | stored in two | (Little | 1555 | | | | blocks of four | Endian, | 1556 | | | | bytes each. The | decodes to | 1557 | | | | format of the | 06/29/2012 | 1558 | | | | timestamp is the | 06:17:00 | 1559 | | | | same already | UTC) | 1560 | | | | defined in the | | 1561 | | | | Enhanced Packet | | 1562 | | | | Block (Section | | 1563 | | | | 4.3). | | 1564 | isb_ifrecv | 4 | 8 | Number of packets | 100 | 1565 | | | | received from the | | 1566 | | | | physical | | 1567 | | | | interface | | 1568 | | | | starting from the | | 1569 | | | | beginning of the | | 1570 | | | | capture. | | 1571 | isb_ifdrop | 5 | 8 | Number of packets | 0 | 1572 | | | | dropped by the | | 1573 | | | | interface due to | | 1574 | | | | lack of resources | | 1575 | | | | starting from the | | 1576 | | | | beginning of the | | 1577 | | | | capture. | | 1578 | isb_filteraccept | 6 | 8 | Number of packets | 100 | 1579 | | | | accepted by | | 1580 | | | | filter starting | | 1581 | | | | from the | | 1582 | | | | beginning of the | | 1583 | | | | capture. | | 1584 | isb_osdrop | 7 | 8 | Number of packets | 0 | 1585 | | | | dropped by the | | 1586 | | | | operating system | | 1587 | | | | starting from the | | 1588 | | | | beginning of the | | 1589 | | | | capture. | | 1590 | isb_usrdeliv | 8 | 8 | Number of packets | 0 | 1591 | | | | delivered to the | | 1592 | | | | user starting | | 1593 | | | | from the | | 1594 | | | | beginning of the | | 1595 | | | | capture. The | | 1596 | | | | value contained | | 1597 | | | | in this field can | | 1598 | | | | be different from | | 1599 | | | | the value | | 1600 | | | | 'isb_filteraccept | | 1601 | | | | - isb_osdrop' | | 1602 | | | | because some | | 1603 | | | | packets could | | 1604 | | | | still lay in the | | 1605 | | | | OS buffers when | | 1606 | | | | the capture | | 1607 | | | | ended. | | 1608 +------------------+------+--------+-------------------+------------+ 1610 All the fields that refer to packet counters are 64-bit values, 1611 represented with the byte order of the current section. Special care 1612 must be taken in accessing these fields: since all the blocks are 1613 aligned to a 32-bit boundary, such fields are not guaranteed to be 1614 aligned on a 64-bit boundary. 1616 5. Experimental Blocks (deserved to a further investigation) 1618 5.1. Alternative Packet Blocks (experimental) 1620 Can some other packet blocks (besides the ones described in the 1621 previous paragraphs) be useful? 1623 5.2. Compression Block (experimental) 1625 The Compression Block is optional. A file can contain an arbitrary 1626 number of these blocks. A Compression Block, as the name says, is 1627 used to store compressed data. Its format is shown in Figure 15. 1629 0 1 2 3 1630 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 1631 +---------------------------------------------------------------+ 1632 | Block Type = ? | 1633 +---------------------------------------------------------------+ 1634 | Block Total Length | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Compr. Type | | 1637 +-+-+-+-+-+-+-+-+ | 1638 | | 1639 | Compressed Data | 1640 | | 1641 | variable length, byte-aligned | 1642 | | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Block Total Length | 1645 +---------------------------------------------------------------+ 1647 Figure 15: Compression Block format. 1649 The fields have the following meaning: 1651 o Block Type: The block type of the Compression Block is not yet 1652 assigned. 1654 o Block Total Length: total size of this block, as described in 1655 Section 3.1. 1657 o Compression Type: specifies the compression algorithm. Possible 1658 values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2 1659 (Gzip), other?? Probably some kind of dumb and fast compression 1660 algorithm could be effective with some types of traffic (for 1661 example web), but which? 1663 o Compressed Data: data of this block. Once decompressed, it is 1664 made of other blocks. 1666 5.3. Encryption Block (experimental) 1668 The Encryption Block is optional. A file can contain an arbitrary 1669 number of these blocks. An Encryption Block is used to store 1670 encrypted data. Its format is shown in Figure 16. 1672 0 1 2 3 1673 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 1674 +---------------------------------------------------------------+ 1675 | Block Type = ? | 1676 +---------------------------------------------------------------+ 1677 | Block Total Length | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Encr. Type | | 1680 +-+-+-+-+-+-+-+-+ | 1681 | | 1682 | Encrypted Data | 1683 | | 1684 | variable length, byte-aligned | 1685 | | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Block Total Length | 1688 +---------------------------------------------------------------+ 1690 Figure 16: Encryption Block format. 1692 The fields have the following meaning: 1694 o Block Type: The block type of the Encryption Block is not yet 1695 assigned. 1697 o Block Total Length: total size of this block, as described in 1698 Section 3.1. 1700 o Encryption Type: specifies the encryption algorithm. Possible 1701 values for this field are ??? (TODO) NOTE: this block should 1702 probably contain other fields, depending on the encryption 1703 algorithm. To be defined precisely. 1705 o Encrypted Data: data of this block. Once decrypted, it originates 1706 other blocks. 1708 5.4. Fixed Length Block (experimental) 1710 The Fixed Length Block is optional. A file can contain an arbitrary 1711 number of these blocks. A Fixed Length Block can be used to optimize 1712 the access to the file. Its format is shown in Figure 17. A Fixed 1713 Length Block stores records with constant size. It contains a set of 1714 Blocks (normally Packet Blocks or Simple Packet Blocks), of which it 1715 specifies the size. Knowing this size a priori helps to scan the 1716 file and to load some portions of it without truncating a block, and 1717 is particularly useful with cell-based networks like ATM. 1719 0 1 2 3 1720 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 1721 +---------------------------------------------------------------+ 1722 | Block Type = ? | 1723 +---------------------------------------------------------------+ 1724 | Block Total Length | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Cell Size | | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1728 | | 1729 | Fixed Size Data | 1730 | | 1731 | variable length, byte-aligned | 1732 | | 1733 | | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Block Total Length | 1736 +---------------------------------------------------------------+ 1738 Figure 17: Fixed Length Block format. 1740 The fields have the following meaning: 1742 o Block Type: The block type of the Fixed Length Block is not yet 1743 assigned. 1745 o Block Total Length: total size of this block, as described in 1746 Section 3.1. 1748 o Cell size: the size of the blocks contained in the data field. 1750 o Fixed Size Data: data of this block. 1752 5.5. Directory Block (experimental) 1754 If present, this block contains the following information: 1756 o number of indexed packets (N) 1758 o table with position and length of any indexed packet (N entries) 1760 A directory block MUST be followed by at least N packets, otherwise 1761 it MUST be considered invalid. It can be used to efficiently load 1762 portions of the file to memory and to support operations on memory 1763 mapped files. This block can be added by tools like network 1764 analyzers as a consequence of file processing. 1766 5.6. Traffic Statistics and Monitoring Blocks (experimental) 1768 One or more blocks could be defined to contain network statistics or 1769 traffic monitoring information. They could be use to store data 1770 collected from RMON or Netflow probes, or from other network 1771 monitoring tools. 1773 5.7. Event/Security Block (experimental) 1775 This block could be used to store events. Events could contain 1776 generic information (for example network load over 50%, server 1777 down...) or security alerts. An event could be: 1779 o skipped, if the application doesn't know how to do with it 1781 o processed independently by the packets. In other words, the 1782 applications skips the packets and processes only the alerts 1784 o processed in relation to packets: for example, a security tool 1785 could load only the packets of the file that are near a security 1786 alert; a monitoring tool could skip the packets captured while the 1787 server was down. 1789 6. Recommended File Name Extension: .pcapng 1791 The recommended file name extension for the "PCAP Next Generation 1792 Dump File Format" specified in this document is ".pcapng". 1794 On Windows and OS X, files are distinguished by an extension to their 1795 filename. Such an extension is technically not actually required, as 1796 applications should be able to automatically detect the pcapng file 1797 format through the "magic bytes" at the beginning of the file, as 1798 some other UN*X desktop environments do. However, using name 1799 extensions makes it easier to work with files (e.g. visually 1800 distinguish file formats) so it is recommended - though not required 1801 - to use .pcapng as the name extension for files following this 1802 specification. 1804 Please note: To avoid confusion (like the current usage of .cap for a 1805 plethora of different capture file formats) other file name 1806 extensions than .pcapng should be avoided! 1808 7. How to add Vendor / Domain specific extensions 1810 TODO - explain the preferred way to add new block types and new 1811 options for existing blocks in more detail. 1813 8. Conclusions 1815 The file format proposed in this document should be very versatile 1816 and satisfy a wide range of applications. In the simplest case, it 1817 can contain a raw dump of the network data, made of a series of 1818 Simple Packet Blocks. In the most complex case, it can be used as a 1819 repository for heterogeneous information. In every case, the file 1820 remains easy to parse and an application can always skip the data it 1821 is not interested in; at the same time, different applications can 1822 share the file, and each of them can benefit of the information 1823 produced by the others. Two or more files can be concatenated 1824 obtaining another valid file. 1826 9. Security Considerations 1828 TBD. 1830 10. IANA Considerations 1832 TBD. 1834 11. Acknowledgments 1836 Loris Degioanni and Gianluca Varenni were coauthoring this document 1837 before it was submitted to the IETF. 1839 The authors wish to thank Anders Broman, Ulf Lamping, Richard Sharpe 1840 and many others for their invaluable comments. 1842 12. References 1844 12.1. Normative References 1846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1847 Requirement Levels", BCP 14, RFC 2119, March 1997. 1849 12.2. URIs 1851 [1] http://www.tcpdump.org/linktypes.html 1853 [2] http://www.tcpdump.org/linktypes.html 1855 [3] http://www.tcpdump.org/linktypes.html 1857 [4] http://www.tcpdump.org/linktypes.html 1859 Appendix A. Packet Block Flags Word 1861 The Packet Block Flags Word is a 32-bit value that contains link- 1862 layer information about the packet. 1864 The meaning of the bits is the following: 1866 +--------+----------------------------------------------------------+ 1867 | Bit | Description | 1868 | Number | | 1869 +--------+----------------------------------------------------------+ 1870 | 0-1 | Inbound / Outbound packet (00 = information not | 1871 | | available, 01 = inbound, 10 = outbound) | 1872 | 2-4 | Reception type (000 = not specified, 001 = unicast, 010 | 1873 | | = multicast, 011 = broadcast, 100 = promiscuous). | 1874 | 5-8 | FCS length, in bytes (0000 if this information is not | 1875 | | available). This value overrides the if_fcslen option of | 1876 | | the Interface Description Block, and is used with those | 1877 | | link layers (e.g. PPP) where the length of the FCS can | 1878 | | change during time. | 1879 | 9-15 | Reserved (MUST be set to zero). | 1880 | 16-31 | link-layer-dependent errors (Bit 31 = symbol error, Bit | 1881 | | 30 = preamble error, Bit 29 = Start Frame Delimiter | 1882 | | error, Bit 28 = unaligned frame error, Bit 27 = wrong | 1883 | | Inter Frame Gap error, Bit 26 = packet too short error, | 1884 | | Bit 25 = packet too long error, Bit 24 = CRC error, | 1885 | | other?? are 16 bit enough?). | 1886 +--------+----------------------------------------------------------+ 1888 Appendix B. Standardized Block Type Codes 1890 Every Block is uniquely identified by a 32-bit integer value, stored 1891 in the Block Header. 1893 As pointed out in Section 3.1, Block Types codes whose Most 1894 Significant Bit (bit 31) is set to 1 are reserved for local use by 1895 the application. 1897 All the remaining Block Type codes (0x00000000 to 0x7FFFFFFF) are 1898 standardized by this document. A request should be sent to the 1899 authors of this document to add a new Standard Block Type code to the 1900 specification. 1902 Here is a list of the Standardized Block Type Codes. 1904 +-----------------------+-------------------------------------------+ 1905 | Block Type Code | Description | 1906 +-----------------------+-------------------------------------------+ 1907 | 0x00000000 | Reserved ??? | 1908 | 0x00000001 | Interface Description Block (Section 4.2) | 1909 | 0x00000002 | Packet Block (Section 4.5) | 1910 | 0x00000003 | Simple Packet Block (Section 4.4) | 1911 | 0x00000004 | Name Resolution Block (Section 4.6) | 1912 | 0x00000005 | Interface Statistics Block (Section 4.7) | 1913 | 0x00000006 | Enhanced Packet Block (Section 4.3) | 1914 | 0x00000007 | IRIG Timestamp Block (requested by | 1915 | | Gianluca Varenni | 1916 | | , CACE | 1917 | | Technologies LLC) | 1918 | 0x00000008 | Arinc 429 in AFDX Encapsulation | 1919 | | Information Block (requested by Gianluca | 1920 | | Varenni , | 1921 | | CACE Technologies LLC) | 1922 | 0x0A0D0D0A | Section Header Block (Section 4.1) | 1923 | 0x0A0D0A00-0x0A0D0AFF | Reserved. Used to detect trace files | 1924 | | corrupted because of file transfers using | 1925 | | the HTTP protocol in text mode. | 1926 | 0x000A0D0A-0xFF0A0D0A | Reserved. Used to detect trace files | 1927 | | corrupted because of file transfers using | 1928 | | the HTTP protocol in text mode. | 1929 | 0x000A0D0D-0xFF0A0D0D | Reserved. Used to detect trace files | 1930 | | corrupted because of file transfers using | 1931 | | the HTTP protocol in text mode. | 1932 | 0x0D0D0A00-0x0D0D0AFF | Reserved. Used to detect trace files | 1933 | | corrupted because of file transfers using | 1934 | | the FTP protocol in text mode. | 1935 +-----------------------+-------------------------------------------+ 1937 Authors' Addresses 1939 Michael Tuexen (editor) 1940 Muenster University of Applied Sciences 1941 Stegerwaldstrasse 39 1942 Steinfurt 48565 1943 DE 1945 Email: tuexen@fh-muenster.de 1946 Fulvio Risso 1947 Politecnico di Torino 1948 Corso Duca degli Abruzzi, 24 1949 Torino 10129 1950 IT 1952 Email: fulvio.risso@polito.it 1954 Jasper Bongertz 1955 Airbus Defence and Space CyberSecurity 1956 Kanzlei 63c 1957 Meerbusch 40667 1958 DE 1960 Email: jasper@packet-foo.com 1962 Guy Harris 1964 Email: guy@alum.mit.edu