1 2 3 Network Working Group L. Degioanni 4 Internet-Draft F. Risso 5 Expires: August 30, 2004 Politecnico di Torino 6 March 2004 7 8 9 PCAP New Generation Dump File Format 10 pcap 11 12 Status of this Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 16 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 25 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 28 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 31 32 This Internet-Draft will expire on August 30, 2004. 33 34 Copyright Notice 35 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 38 Abstract 39 40 This document describes a format to dump captured packets on a file. 41 This format is extensible and it is currently proposed for 42 implementation in the libpcap/WinPcap packet capture library. 43 44 45 46 47 48 49 50 51 52 53 54 55 Degioanni & Risso Expires August 30, 2004 [Page 1] 56 58 Internet-Draft PCAP New Generation Dump File Format March 2004 59 60 61 Table of Contents 62 63 1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. General File Structure . . . . . . . . . . . . . . . . . . . . 4 65 2.1 General Block Structure . . . . . . . . . . . . . . . . . . . 4 66 2.2 Block Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3 Block Hierarchy and Precedence . . . . . . . . . . . . . . . . 5 68 2.4 Data format . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Block Definition . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1 Section Header Block (mandatory) . . . . . . . . . . . . . . . 8 71 3.2 Interface Description Block (mandatory) . . . . . . . . . . . 9 72 3.3 Packet Block (optional) . . . . . . . . . . . . . . . . . . . 13 73 3.4 Simple Packet Block (optional) . . . . . . . . . . . . . . . . 15 74 3.5 Name Resolution Block (optional) . . . . . . . . . . . . . . . 16 75 3.6 Interface Statistics Block (optional) . . . . . . . . . . . . 18 76 4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 5. Experimental Blocks (deserved to a further investigation) . . 23 78 5.1 Other Packet Blocks (experimental) . . . . . . . . . . . . . . 23 79 5.2 Compression Block (experimental) . . . . . . . . . . . . . . . 23 80 5.3 Encryption Block (experimental) . . . . . . . . . . . . . . . 23 81 5.4 Fixed Length Block (experimental) . . . . . . . . . . . . . . 24 82 5.5 Directory Block (experimental) . . . . . . . . . . . . . . . . 25 83 5.6 Traffic Statistics and Monitoring Blocks (experimental) . . . 25 84 5.7 Event/Security Block (experimental) . . . . . . . . . . . . . 25 85 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 7. Most important open issues . . . . . . . . . . . . . . . . . . 28 87 Intellectual Property and Copyright Statements . . . . . . . . 29 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 Degioanni & Risso Expires August 30, 2004 [Page 2] 113 115 Internet-Draft PCAP New Generation Dump File Format March 2004 116 117 118 1. Objectives 119 120 The problem of exchanging packet traces becomes more and more 121 critical every day; unfortunately, no standard solutions exist for 122 this task right now. One of the most accepted packet interchange 123 formats is the one defined by libpcap, which is rather old and does 124 not fit for some of the nowadays applications especially in terms of 125 extensibility. 126 127 This document proposes a new format for dumping packet traces. The 128 following goals are being pursued: 129 130 o Extensibility: aside of some common functionalities, third parties 131 should be able to enrich the information embedded in the file with 132 proprietary extensions, which will be ignored by tools that are 133 not able to understand them. 134 135 o Portability: a capture trace must contain all the information 136 needed to read data independently from network, hardware and 137 operating system of the machine that made the capture. 138 139 o Merge/Append data: it should be possible to add data at the end of 140 a given file, and the resulting file must still be readable. 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 Degioanni & Risso Expires August 30, 2004 [Page 3] 170 172 Internet-Draft PCAP New Generation Dump File Format March 2004 173 174 175 2. General File Structure 176 177 2.1 General Block Structure 178 179 A capture file is organized in blocks, that are appended one to 180 another to form the file. All the blocks share a common format, which 181 is shown in Figure 1. 182 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Block Type | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Block Total Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 / Block Body / 191 / /* variable length, aligned to 32 bits */ / 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Block Total Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 196 Figure 1: Basic block structure. 197 198 The fields have the following meaning: 199 200 o Block Type (32 bits): unique value that identifies the block. 201 Values whose Most Significant Bit (MSB) is equal to 1 are reserved 202 for local use. They allow to save private data to the file and to 203 extend the file format. 204 205 o Block Total Length: total size of this block, in bytes. For 206 instance, a block that does not have a body has a length of 12 207 bytes. 208 209 o Block Body: content of the block. 210 211 o Block Total Length: total size of this block, in bytes. This field 212 is duplicated for permitting backward file navigation. 213 214 This structure, shared among all blocks, makes easy to process a file 215 and to skip unneeded or unknown blocks. Blocks can be nested one 216 inside the others (NOTE: needed?). Some of the blocks are mandatory, 217 i.e. a dump file is not valid if they are not present, other are 218 optional. 219 220 The structure of the blocks allows to define other blocks if needed. 221 A parser that does non understand them can simply ignore their 222 content. 223 224 225 226 Degioanni & Risso Expires August 30, 2004 [Page 4] 227 229 Internet-Draft PCAP New Generation Dump File Format March 2004 230 231 232 2.2 Block Types 233 234 The currently defined blocks are the following: 235 236 1. Section Header Block: it defines the most important 237 characteristics of the capture file. 238 239 2. Interface Description Block: it defines the most important 240 characteristics of the interface(s) used for capturing traffic. 241 242 3. Packet Block: it contains a single captured packet, or a portion 243 of it. 244 245 4. Simple Packet Block: it contains a single captured packet, or a 246 portion of it, with only a minimal set of information about it. 247 248 5. Name Resolution Block: it defines the mapping from numeric 249 addresses present in the packet dump and the canonical name 250 counterpart. 251 252 6. Capture Statistics Block: it defines how to store some 253 statistical data (e.g. packet dropped, etc) which can be useful 254 to undestand the conditions in which the capture has been made. 255 256 7. Compression Marker Block: TODO 257 258 8. Encryption Marker Block: TODO 259 260 9. Fixed Length Marker Block: TODO 261 262 The following blocks instead are considered interesting but the 263 authors believe that they deserve more in-depth discussion before 264 being defined: 265 266 1. Further Packet Blocks 267 268 2. Directory Block 269 270 3. Traffic Statistics and Monitoring Blocks 271 272 4. Alert and Security Blocks 273 274 TODO Currently standardized Block Type codes are specified in 275 Appendix 1. 276 277 2.3 Block Hierarchy and Precedence 278 279 The file must begin with a Section Header Block. However, more than 280 281 282 283 Degioanni & Risso Expires August 30, 2004 [Page 5] 284 286 Internet-Draft PCAP New Generation Dump File Format March 2004 287 288 289 one Section Header Block can be present on the dump, each one 290 covering the data following it till the next one (or the end of 291 file). A Section includes the data delimited by two Section Header 292 Blocks (or by a Section Header Block and the end of the file), 293 including the first Section Header Block. 294 295 In case an application cannot read a Section because of different 296 version number, it must skip everything until the next Section Header 297 Block. Note that, in order to properly skip the blocks until the next 298 section, all blocks must have the fields Type and Length at the 299 beginning. This is a mandatory requirement that must be maintained in 300 future versions of the block format. 301 302 Figure 2 shows two valid files: the first has a typical 303 configuration, with a single Section Header that covers the whole 304 file. The second one contains three headers, and is normally the 305 result of file concatenation. An application that understands only 306 version 1.0 of the file format skips the intermediate section and 307 restart processing the packets after the third Section Header. 308 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | SHB v1.0 | Data | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Typical configuration with a single Section Header Block 313 314 315 |-- 1st Section --|-- 2nd Section --|-- 3rd Section --| 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | SHB v1.0 | Data | SHB V1.1 | Data | SHB V1.0 | Data | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Configuration with three different Section Header Blocks 321 322 Figure 2: File structure example: the Section Header Block. 323 324 NOTE: TO BE COMPLETED with some examples of other blocks 325 326 2.4 Data format 327 328 Data contained in each section will always be saved according to the 329 characteristics (little endian / big endian) of the dumping machine. 330 This refers to all fields that are saved as numbers and that span 331 over two or more bytes. 332 333 The approach of having each section saved in the native format of the 334 generating host is more efficient because it avoids translation of 335 data when reading / writing on the host itself, which is the most 336 common case when generating/processing capture dumps. 337 338 339 340 Degioanni & Risso Expires August 30, 2004 [Page 6] 341 343 Internet-Draft PCAP New Generation Dump File Format March 2004 344 345 346 TODO Probably we have to specify something more here. Is what we're 347 saying enough to avoid any kind of ambiguity?. 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 Degioanni & Risso Expires August 30, 2004 [Page 7] 398 400 Internet-Draft PCAP New Generation Dump File Format March 2004 401 402 403 3. Block Definition 404 405 This section details the format of the body of the blocks currently 406 defined. 407 408 3.1 Section Header Block (mandatory) 409 410 The Section Header Block is mandatory. It identifies the beginning of 411 a section of the capture dump file. Its format is shown in Figure 3. 412 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Magic | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Major | Minor | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 / / 421 / Options (variable) / 422 / / 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 425 Figure 3: Section Header Block format. 426 427 The meaning of the fields is: 428 429 o Magic: magic number, whose value is the hexadecimal number 430 0x1A2B3C4D. This number can be used to distinguish section that 431 have been saved on little-endian machines from the one saved on 432 big-endian machines. 433 434 o Major: number of the current mayor version of the format. Current 435 value is 1. 436 437 o Minor: number of the current minor version of the format. Current 438 value is 0. 439 440 o Options: optionally, a list of options (formatted according to the 441 rules defined in Section 4) can be present. 442 443 Aside form the options defined in Section 4, the following options 444 are valid within this block: 445 446 +----------------+----------------+----------------+----------------+ 447 | Name | Code | Length | Description | 448 +----------------+----------------+----------------+----------------+ 449 | Hardware | 2 | variable | An ascii | 450 | | | | string | 451 452 453 454 Degioanni & Risso Expires August 30, 2004 [Page 8] 455 457 Internet-Draft PCAP New Generation Dump File Format March 2004 458 459 460 | | | | containing the | 461 | | | | description of | 462 | | | | the hardware | 463 | | | | used to create | 464 | | | | this section. | 465 | | | | | 466 | Operating | 3 | variable | An ascii | 467 | System | | | string | 468 | | | | containing the | 469 | | | | name of the | 470 | | | | operating | 471 | | | | system used to | 472 | | | | create this | 473 | | | | section. | 474 | | | | | 475 | User | 3 | variable | An ascii | 476 | Application | | | string | 477 | | | | containing the | 478 | | | | name of the | 479 | | | | application | 480 | | | | used to create | 481 | | | | this section. | 482 +----------------+----------------+----------------+----------------+ 483 484 Table 1 485 486 The Section Header Block does not contain data but it rather 487 identifies a list of blocks (interfaces, packets) that are logically 488 correlated. This block does not contain any reference to the size of 489 the section it is currently delimiting, therefore the reader cannot 490 skip a whole section at once. In case a section must be skipped, the 491 user has to repeatedly skip all the blocks contained within it; this 492 makes the parsing of the file slower but it permits to append several 493 capture dumps at the same file. 494 495 3.2 Interface Description Block (mandatory) 496 497 The Interface Description Block is mandatory. This block is needed to 498 specify the characteristics of the network interface on which the 499 capture has been made. In order to properly associate the captured 500 data to the corresponding interface, the Interface Description Block 501 must be defined before any other block that uses it; therefore, this 502 block is usually placed immediately after the Section Header Block. 503 504 An Interface Description Block is valid only inside the section which 505 it belongs to. The structure of a Interface Description Block is 506 shown in Figure 4. 507 508 509 510 511 Degioanni & Risso Expires August 30, 2004 [Page 9] 512 514 Internet-Draft PCAP New Generation Dump File Format March 2004 515 516 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Interface ID | LinkType | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | SnapLen | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 / / 525 / Options (variable) / 526 / / 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 529 Figure 4: Interface Description Block format. 530 531 The meaning of the fields is: 532 533 o Interface ID: a progressive number that identifies uniquely any 534 interface inside current section. Two Interface Description Blocks 535 can have the same Interface ID only if they are in different 536 sections of the file. The Interface ID is referenced by the packet 537 blocks. 538 539 o LinkType: a value that defines the link layer type of this 540 interface. 541 542 o SnapLen: maximum number of bytes dumped from each packet. The 543 portion of each packet that exceeds this value will not be stored 544 in the file. 545 546 o Options: optionally, a list of options (formatted according to the 547 rules defined in Section 4) can be present. 548 549 In addition to the options defined in Section 4, the following 550 options are valid within this block: 551 552 +----------------+----------------+----------------+----------------+ 553 | Name | Code | Length | Description | 554 +----------------+----------------+----------------+----------------+ 555 | if_name | 2 | Variable | Name of the | 556 | | | | device used to | 557 | | | | capture data. | 558 | | | | | 559 | if_IPv4addr | 3 | 8 | Interface | 560 | | | | network | 561 | | | | address and | 562 | | | | netmask. | 563 | | | | | 564 | if_IPv6addr | 4 | 17 | Interface | 565 566 567 568 Degioanni & Risso Expires August 30, 2004 [Page 10] 569 571 Internet-Draft PCAP New Generation Dump File Format March 2004 572 573 574 | | | | network | 575 | | | | address and | 576 | | | | prefix length | 577 | | | | (stored in the | 578 | | | | last byte). | 579 | | | | | 580 | if_MACaddr | 5 | 6 | Interface | 581 | | | | Hardware MAC | 582 | | | | address (48 | 583 | | | | bits). | 584 | | | | | 585 | if_EUIaddr | 6 | 8 | Interface | 586 | | | | Hardware EUI | 587 | | | | address (64 | 588 | | | | bits), if | 589 | | | | available. | 590 | | | | | 591 | if_speed | 7 | 8 | Interface | 592 | | | | speed (in | 593 | | | | bps). | 594 | | | | | 595 | if_tsaccur | 8 | 1 | Precision of | 596 | | | | timestamps. If | 597 | | | | the Most | 598 | | | | Significant | 599 | | | | Bit is equal | 600 | | | | to zero, the | 601 | | | | remaining bits | 602 | | | | indicates the | 603 | | | | accuracy as as | 604 | | | | a negative | 605 | | | | power of 10 | 606 | | | | (e.g. 6 means | 607 | | | | microsecond | 608 | | | | accuracy). If | 609 | | | | the Most | 610 | | | | Significant | 611 | | | | Bit is equal | 612 | | | | to zero, the | 613 | | | | remaining bits | 614 | | | | indicates the | 615 | | | | accuracy as as | 616 | | | | negative power | 617 | | | | of 2 (e.g. 10 | 618 | | | | means 1/1024 | 619 | | | | of second). If | 620 | | | | this option is | 621 | | | | not present, a | 622 623 624 625 Degioanni & Risso Expires August 30, 2004 [Page 11] 626 628 Internet-Draft PCAP New Generation Dump File Format March 2004 629 630 631 | | | | precision of | 632 | | | | 10^-6 is | 633 | | | | assumed. | 634 | | | | | 635 | if_tzone | 9 | 4 | Time zone for | 636 | | | | GMT support | 637 | | | | (TODO: specify | 638 | | | | better). | 639 | | | | | 640 | if_flags | 10 | 4 | Interface | 641 | | | | flags. (TODO: | 642 | | | | specify | 643 | | | | better. | 644 | | | | Possible | 645 | | | | flags: | 646 | | | | promiscuous, | 647 | | | | inbound/outbou | 648 | | | | nd, traffic | 649 | | | | filtered | 650 | | | | during | 651 | | | | capture). | 652 | | | | | 653 | if_filter | 11 | variable | The filter | 654 | | | | (e.g. "capture | 655 | | | | only TCP | 656 | | | | traffic") used | 657 | | | | to capture | 658 | | | | traffic. The | 659 | | | | first byte of | 660 | | | | the Option | 661 | | | | Data keeps a | 662 | | | | code of the | 663 | | | | filter used | 664 | | | | (e.g. if this | 665 | | | | is a libpcap | 666 | | | | string, or BPF | 667 | | | | bytecode, and | 668 | | | | more). More | 669 | | | | details about | 670 | | | | this format | 671 | | | | will be | 672 | | | | presented in | 673 | | | | Appendix XXX | 674 | | | | (TODO). | 675 | | | | | 676 | if_opersystem | 12 | variable | An ascii | 677 | | | | string | 678 | | | | containing the | 679 680 681 682 Degioanni & Risso Expires August 30, 2004 [Page 12] 683 685 Internet-Draft PCAP New Generation Dump File Format March 2004 686 687 688 | | | | name of the | 689 | | | | operating | 690 | | | | system of the | 691 | | | | machine that | 692 | | | | hosts this | 693 | | | | interface. | 694 | | | | This can be | 695 | | | | different from | 696 | | | | the same | 697 | | | | information | 698 | | | | that can be | 699 | | | | contained by | 700 | | | | the Section | 701 | | | | Header Block | 702 | | | | (Section 3.1) | 703 | | | | because the | 704 | | | | capture can | 705 | | | | have been done | 706 | | | | on a remote | 707 | | | | machine. | 708 +----------------+----------------+----------------+----------------+ 709 710 Table 2 711 712 713 3.3 Packet Block (optional) 714 715 A Packet Block is the standard container for storing the packets 716 coming from the network. The Packet Block is optional because packets 717 can be stored either by means of this block or the Simple Packet 718 Block, which can be used to speed up dump generation. The format of a 719 packet block is shown in Figure 5. 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 Degioanni & Risso Expires August 30, 2004 [Page 13] 740 742 Internet-Draft PCAP New Generation Dump File Format March 2004 743 744 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Interface ID | Drops Count | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Timestamp (High) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Timestamp (Low) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Captured Len | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Packet Len | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | | 759 | Packet Data | 760 | | 761 | /* variable length, byte-aligned */ | 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 / / 765 / Options (variable) / 766 / / 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 769 Figure 5: Packet Block format. 770 771 The Packet Block has the following fields: 772 773 o Interface ID: Specifies the interface this packet comes from, and 774 corresponds to the ID of one of the Interface Description Blocks 775 present in this section of the file (see Figure 4). 776 777 o Drops Count: a local drop counter. It specified the number of 778 packets lost (by the interface and the operating system) between 779 this packet and the preceding one. The value xFFFF (in 780 hexadecimal) is reserved for those systems in which this 781 information is not available. 782 783 o Timestamp (High): the most significative part of the timestamp. in 784 standard Unix format, i.e. from 1/1/1970. 785 786 o Timestamp (Low): the less significative part of the timestamp. The 787 way to interpret this field is specified by the 'ts_accur' option 788 (see Figure 4) of the Interface Description block referenced by 789 this packet. If the Interface Description block does not contain a 790 'ts_accur' option, then this field is expressed in microseconds. 791 792 o Captured Len: number of bytes captured from the packet (i.e. the 793 794 795 796 Degioanni & Risso Expires August 30, 2004 [Page 14] 797 799 Internet-Draft PCAP New Generation Dump File Format March 2004 800 801 802 length of the Packet Data field). It will be the minimum value 803 among the actual Packet Length and the snapshot length (defined in 804 Figure 4). 805 806 o Packet Len: actual length of the packet when it was transmitted on 807 the network. Can be different from Captured Len if the user wants 808 only a snapshot of the packet. 809 810 o Packet Data: the data coming from the network, including 811 link-layer headers. The length of this field is Captured Len. The 812 format of the link-layer headers depends on the LinkType field 813 specified in the Interface Description Block (see Section 3.2) and 814 it is specified in Appendix XXX (TODO). 815 816 o Options: optionally, a list of options (formatted according to the 817 rules defined in Section 4) can be present. 818 819 820 3.4 Simple Packet Block (optional) 821 822 The Simple Packet Block is a lightweight container for storing the 823 packets coming from the network. Its presence is optional. 824 825 A Simple Packet Block is similar to a Packet Block (see Section 3.3), 826 but it is smaller, simpler to process and contains only a minimal set 827 of information. This block is preferred to the standard Packet Block 828 when performance or space occupation are critical factors, such as in 829 sustained traffic dump applications. A capture file can contain both 830 Packet Blocks and Simple Packet Blocks: for example, a capture tool 831 could switch from Packet Blocks to Simple Packet Blocks when the 832 hardware resources become critical. 833 834 The Simple Packet Block does not contain the Interface ID field. 835 Therefore, it must be assumed that all the Simple Packet Blocks have 836 been captured on the interface previously specified in the Interface 837 Description Block. 838 839 Figure 6 shows the format of the Simple Packet Block. 840 841 842 843 844 845 846 847 848 849 850 851 852 853 Degioanni & Risso Expires August 30, 2004 [Page 15] 854 856 Internet-Draft PCAP New Generation Dump File Format March 2004 857 858 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Packet Len | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | | 865 | Packet Data | 866 | | 867 | /* variable length, byte-aligned */ | 868 | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 871 Figure 6: Simple Packet Block format. 872 873 The Packet Block has the following fields: 874 875 o Packet Len: actual length of the packet when it was transmitted on 876 the network. Can be different from captured len if the packet has 877 been truncated. 878 879 o Packet data: the data coming from the network, including 880 link-layers headers. The length of this field can be derived from 881 the field Block Total Length, present in the Block Header. 882 883 The Simple Packet Block does not contain the timestamp because this 884 is one of the most costly operations on PCs. Additionally, there are 885 applications that do not require it; e.g. an Intrusion Detection 886 System is interested in packets, not in their timestamp. 887 888 The Simple Packet Block is very efficient in term of disk space: a 889 snapshot of length 100 bytes requires only 16 bytes of overhead, 890 which corresponds to an efficiency of more than 86%. 891 892 3.5 Name Resolution Block (optional) 893 894 The Name Resolution Block is used to support the correlation of 895 numeric addresses (present in the captured packets) and their 896 corresponding canonical names and it is optional. Having the literal 897 names saved in the file, this prevents the need of a name resolution 898 in a delayed time, when the association between names and addresses 899 can be different from the one in use at capture time. Moreover, The 900 Name Resolution Block avoids the need of issuing a lot of DNS 901 requests every time the trace capture is opened, and allows to have 902 name resolution also when reading the capture with a machine not 903 connected to the network. 904 905 The format of the Name Resolution Block is shown in Figure 7. 906 907 908 909 910 Degioanni & Risso Expires August 30, 2004 [Page 16] 911 913 Internet-Draft PCAP New Generation Dump File Format March 2004 914 915 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Record Type | Record Length | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Record Value | 922 | /* variable length, byte-aligned */ | 923 | + + + + + + + + + + + + + + + + + + + + + + + + + 924 | | | | | 925 +-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + + 926 . . . other records . . . 927 | Record Type == end_of_recs | Record Length == 00 | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 / / 930 / Options (variable) / 931 / / 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 934 Figure 7: Name Resolution Block format. 935 936 A Name Resolution Block is a zero-terminated list of records (in the 937 TLV format), each of which contains an association between a network 938 address and a name. There are three possible types of records: 939 940 +----------------+----------------+----------------+----------------+ 941 | Name | Code | Length | Description | 942 +----------------+----------------+----------------+----------------+ 943 | end_of_recs | 0 | 0 | End of records | 944 | | | | | 945 | ip4_rec | 1 | Variable | Specifies an | 946 | | | | IPv4 address | 947 | | | | (contained in | 948 | | | | the first 4 | 949 | | | | bytes), | 950 | | | | followed by | 951 | | | | one or more | 952 | | | | zero-terminate | 953 | | | | d strings | 954 | | | | containing the | 955 | | | | DNS entries | 956 | | | | for that | 957 | | | | address. | 958 | | | | | 959 | ip6_rec | 1 | Variable | Specifies an | 960 | | | | IPv6 address | 961 | | | | (contained in | 962 | | | | the first 16 | 963 | | | | bytes), | 964 965 966 967 Degioanni & Risso Expires August 30, 2004 [Page 17] 968 970 Internet-Draft PCAP New Generation Dump File Format March 2004 971 972 973 | | | | followed by | 974 | | | | one or more | 975 | | | | zero-terminate | 976 | | | | d strings | 977 | | | | containing the | 978 | | | | DNS entries | 979 | | | | for that | 980 | | | | address. | 981 +----------------+----------------+----------------+----------------+ 982 983 Table 3 984 985 After the list or Name Resolution Records, optionally, a list of 986 options (formatted according to the rules defined in Section 4) can 987 be present. 988 989 A Name Resolution Block is normally placed at the beginning of the 990 file, but no assumptions can be taken about its position. Name 991 Resolution Blocks can be added in a second time by tools that process 992 the file, like network analyzers. 993 994 In addiction to the options defined in Section 4, the following 995 options are valid within this block: 996 997 +----------------+----------------+----------------+----------------+ 998 | Name | Code | Length | Description | 999 +----------------+----------------+----------------+----------------+ 1000 | ns_dnsname | 2 | Variable | An ascii | 1001 | | | | string | 1002 | | | | containing the | 1003 | | | | name of the | 1004 | | | | machine (DNS | 1005 | | | | server) used | 1006 | | | | to perform the | 1007 | | | | name | 1008 | | | | resolution. | 1009 +----------------+----------------+----------------+----------------+ 1010 1011 1012 3.6 Interface Statistics Block (optional) 1013 1014 The Interface Statistics Block contains the capture statistics for a 1015 given interface and it is optional. The statistics are referred to 1016 the interface defined in the current Section identified by the 1017 Interface ID field. 1018 1019 The format of the Interface Statistics Block is shown in Figure 8. 1020 1021 1022 1023 1024 Degioanni & Risso Expires August 30, 2004 [Page 18] 1025 1027 Internet-Draft PCAP New Generation Dump File Format March 2004 1028 1029 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | IfRecv | 1034 | (high + low) | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | IfDrop | 1037 | (high + low) | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | FilterAccept | 1040 | (high + low) | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | OSDrop | 1043 | (high + low) | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | UsrDelivered | 1046 | (high + low) | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Interface ID | Reserved | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 / / 1051 / Options (variable) / 1052 / / 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 1055 Figure 8: Interface Statistics Block format. 1056 1057 The fields have the following meaning: 1058 1059 o IfRecv: number of packets received from the interface during the 1060 capture. This number is reported as a 64 bits value, in which the 1061 most significat bits are located in the first four bytes of the 1062 field. 1063 1064 o IfDrop: number of packets dropped by the interface during the 1065 capture due to lack of resources. 1066 1067 o FilterAccept: number of packets accepeted by filter during current 1068 capture. 1069 1070 o OSDrop: number of packets dropped by the operating system during 1071 the capture. 1072 1073 o UsrDelivered: number of packets delivered to the user. 1074 UsrDelivered can be different from the value 'FilterAccept - 1075 OSDropped' because some packets could still lay in the OS buffers 1076 when the capture ended. 1077 1078 1079 1080 1081 Degioanni & Risso Expires August 30, 2004 [Page 19] 1082 1084 Internet-Draft PCAP New Generation Dump File Format March 2004 1085 1086 1087 o Interface ID: reference to an Interface Description Block. 1088 1089 o Reserved: Reserved to future use. 1090 1091 o Options: optionally, a list of options (formatted according to the 1092 rules defined in Section 4) can be present. 1093 1094 In addiction to the options defined in Section 4, the following 1095 options are valid within this block: 1096 1097 +----------------+----------------+----------------+----------------+ 1098 | Name | Code | Length | Description | 1099 +----------------+----------------+----------------+----------------+ 1100 | isb_starttime | 2 | 8 | Time in which | 1101 | | | | the capture | 1102 | | | | started; time | 1103 | | | | will be stored | 1104 | | | | in two blocks | 1105 | | | | of four bytes | 1106 | | | | each, | 1107 | | | | containing the | 1108 | | | | timestamp in | 1109 | | | | seconds and | 1110 | | | | nanoseconds. | 1111 | | | | | 1112 | isb_endtime | 3 | 8 | Time in which | 1113 | | | | the capture | 1114 | | | | started; time | 1115 | | | | will be stored | 1116 | | | | in two blocks | 1117 | | | | of four bytes | 1118 | | | | each, | 1119 | | | | containing the | 1120 | | | | timestamp in | 1121 | | | | seconds and | 1122 | | | | nanoseconds. | 1123 +----------------+----------------+----------------+----------------+ 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 Degioanni & Risso Expires August 30, 2004 [Page 20] 1139 1141 Internet-Draft PCAP New Generation Dump File Format March 2004 1142 1143 1144 4. Options 1145 1146 Almost all blocks have the possibility to embed optional fields. 1147 Optional fields can be used to insert some information that may be 1148 useful when reading data, but that it is not really needed for packet 1149 processing. Therefore, each tool can be either read the content of 1150 the optional fields (if any), or skip them at once. 1151 1152 Skipping all the optional fields at once is straightforward because 1153 most of the blocks have a fixed length, therefore the field Block 1154 Length (present in the General Block Structure, see Section 2.1) can 1155 be used to skip everything till the next block. 1156 1157 Options are a list of Type - Length - Value fields, each one 1158 containing a single value: 1159 1160 o Option Type (2 bytes): it contains the code that specifies the 1161 type of the current TLV record. Option types whose Most 1162 Significant Bit is equal to one are reserved for local use; 1163 therefore, there is no guarantee that the code used is unique 1164 among all capture files (generated by other applications). In case 1165 of vendor-specific extensions that have to be identified uniquely, 1166 vendors must request an Option Code whose MSB is equal to zero. 1167 1168 o Option Length (2 bytes): it contains the length of the following 1169 'Option Value' field. 1170 1171 o Option Value (variable length): it contains the value of the given 1172 option. The length of this field as been specified by the Option 1173 Length field. 1174 1175 Options may be repeated several times (e.g. an interface that has 1176 several IP addresses associated to it). The option list is terminated 1177 by a special code which is the 'End of Option'. 1178 1179 The format of the optional fields is shown in Figure 9. 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 Degioanni & Risso Expires August 30, 2004 [Page 21] 1196 1198 Internet-Draft PCAP New Generation Dump File Format March 2004 1199 1200 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Option Code | Option Length | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Option Value | 1207 | /* variable length, byte-aligned */ | 1208 | + + + + + + + + + + + + + + + + + + + + + + + + + 1209 | / / / | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 / / 1212 / . . . other options . . . / 1213 / / 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Option Code == opt_endofopt | Option Length == 0 | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 1218 Figure 9: Options format. 1219 1220 The following codes can always be present in any optional field: 1221 1222 +----------------+----------------+----------------+----------------+ 1223 | Name | Code | Length | Description | 1224 +----------------+----------------+----------------+----------------+ 1225 | opt_endofopt | 0 | 0 | End of | 1226 | | | | options: it is | 1227 | | | | used to | 1228 | | | | delimit the | 1229 | | | | end of the | 1230 | | | | optional | 1231 | | | | fields. This | 1232 | | | | block cannot | 1233 | | | | be repeated | 1234 | | | | within a given | 1235 | | | | list of | 1236 | | | | options. | 1237 | | | | | 1238 | opt_comment | 1 | variable | Comment: it is | 1239 | | | | an ascii | 1240 | | | | string | 1241 | | | | containing a | 1242 | | | | comment that | 1243 | | | | is associated | 1244 | | | | to the current | 1245 | | | | block. | 1246 +----------------+----------------+----------------+----------------+ 1247 1248 1249 1250 1251 1252 Degioanni & Risso Expires August 30, 2004 [Page 22] 1253 1255 Internet-Draft PCAP New Generation Dump File Format March 2004 1256 1257 1258 5. Experimental Blocks (deserved to a further investigation) 1259 1260 5.1 Other Packet Blocks (experimental) 1261 1262 Can some other packet blocks (besides the two described in the 1263 previous paragraphs) be useful? 1264 1265 5.2 Compression Block (experimental) 1266 1267 The Compression Block is optional. A file can contain an arbitrary 1268 number of these blocks. A Compression Block, as the name says, is 1269 used to store compressed data. Its format is shown in Figure 10. 1270 1271 0 1 2 3 1272 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 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Compr. Type | | 1275 +-+-+-+-+-+-+-+-+ | 1276 | | 1277 | Compressed Data | 1278 | | 1279 | /* variable length, byte-aligned */ | 1280 | | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 1283 Figure 10: Compression Block format. 1284 1285 The fields have the following meaning: 1286 1287 o Compression Type: specifies the compression algorithm. Possible 1288 values for this field are 0 (uncompressed), 1 (Lempel Ziv), 2 1289 (Gzip), other?? Probably some kind of dumb and fast compression 1290 algorithm could be effective with some types of traffic (for 1291 example web), but which? 1292 1293 o Compressed Data: data of this block. Once decompressed, it is made 1294 of other blocks. 1295 1296 1297 5.3 Encryption Block (experimental) 1298 1299 The Encryption Block is optional. A file can contain an arbitrary 1300 number of these blocks. An Encryption Block is used to sotre 1301 encrypted data. Its format is shown in Figure 11. 1302 1303 1304 1305 1306 1307 1308 1309 Degioanni & Risso Expires August 30, 2004 [Page 23] 1310 1312 Internet-Draft PCAP New Generation Dump File Format March 2004 1313 1314 1315 0 1 2 3 1316 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 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Encr. Type | | 1319 +-+-+-+-+-+-+-+-+ | 1320 | | 1321 | Compressed Data | 1322 | | 1323 | /* variable length, byte-aligned */ | 1324 | | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 1327 Figure 11: Encryption Block format. 1328 1329 The fields have the following meaning: 1330 1331 o Compression Type: specifies the encryption algorithm. Possible 1332 values for this field are ??? NOTE: this block should probably 1333 contain other fields, depending on the encryption algorithm. To be 1334 define precisely. 1335 1336 o Encrypted Data: data of this block. Once decripted, it consists of 1337 other blocks. 1338 1339 1340 5.4 Fixed Length Block (experimental) 1341 1342 The Fixed Length Block is optional. A file can contain an arbitrary 1343 number of these blocks. A Fixed Length Block can be used to optimize 1344 the access to the file. Its format is shown in Figure 12. A Fixed 1345 Length Block stores records with constant size. It contains a set of 1346 Blocks (normally Packet Blocks or Simple Packet Blocks), of wihich it 1347 specifies the size. Knowing this size a priori helps to scan the file 1348 and to load some portions of it without truncating a block, and is 1349 particularly useful with cell-based networks like ATM. 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 Degioanni & Risso Expires August 30, 2004 [Page 24] 1367 1369 Internet-Draft PCAP New Generation Dump File Format March 2004 1370 1371 1372 0 1 2 3 1373 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 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Cell Size | | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1377 | | 1378 | Fixed Size Data | 1379 | | 1380 | /* variable length, byte-aligned */ | 1381 | | 1382 | | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 1385 Figure 12: Fixed Length Block format. 1386 1387 The fields have the following meaning: 1388 1389 o Cell size: the size of the blocks contained in the data field. 1390 1391 o Fixed Size Data: data of this block. 1392 1393 1394 5.5 Directory Block (experimental) 1395 1396 If present, this block contains the following information: 1397 1398 o number of indexed packets (N) 1399 1400 o table with position and length of any indexed packet (N entries) 1401 1402 A directory block must be followed by at least N packets, otherwise 1403 it must be considered invalid. It can be used to efficiently load 1404 portions of the file to memory and to support operations on memory 1405 mapped files. This block can be added by tools like network analyzers 1406 as a consequence of file processing. 1407 1408 5.6 Traffic Statistics and Monitoring Blocks (experimental) 1409 1410 One or more blocks could be defined to contain network statistics or 1411 traffic monitoring information. They could be use to store data 1412 collected from RMON or Netflow probes, or from other network 1413 monitoring tools. 1414 1415 5.7 Event/Security Block (experimental) 1416 1417 This block could be used to store events. Events could contain 1418 generic information (for example network load over 50%, server 1419 down...) or security alerts. An event could be: 1420 1421 1422 1423 Degioanni & Risso Expires August 30, 2004 [Page 25] 1424 1426 Internet-Draft PCAP New Generation Dump File Format March 2004 1427 1428 1429 o skipped, if the application doesn't know how to do with it 1430 1431 o processed independently by the packets. In other words, the 1432 applications skips the packets and processes only the alerts 1433 1434 o processed in relation to packets: for example, a security tool 1435 could load only the packets of the file that are near a security 1436 alert; a monitorg tool could skip the packets captured while the 1437 server was down. 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 Degioanni & Risso Expires August 30, 2004 [Page 26] 1481 1483 Internet-Draft PCAP New Generation Dump File Format March 2004 1484 1485 1486 6. Conclusions 1487 1488 The file format proposed in this document should be very versatile 1489 and satisfy a wide range of applications. In the simplest case, it 1490 can contain a raw dump of the network data, made of a series of 1491 Simple Packet Blocks. In the most complex case, it can be used as a 1492 repository for heterogeneous information. In every case, the file 1493 remains easy to parse and an application can always skip the data it 1494 is not interested in; at the same time, different applications can 1495 share the file, and each of them can benfit of the information 1496 produced by the others. Two or more files can be concatenated 1497 obtaining another valid file. 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 Degioanni & Risso Expires August 30, 2004 [Page 27] 1538 1540 Internet-Draft PCAP New Generation Dump File Format March 2004 1541 1542 1543 7. Most important open issues 1544 1545 o Data, in the file, must be byte or word aligned? Currently, the 1546 structure of this document is not consistent with respect to this 1547 point. 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 Degioanni & Risso Expires August 30, 2004 [Page 28] 1595 1597 Internet-Draft PCAP New Generation Dump File Format March 2004 1598 1599 1600 Intellectual Property Statement 1601 1602 The IETF takes no position regarding the validity or scope of any 1603 intellectual property or other rights that might be claimed to 1604 pertain to the implementation or use of the technology described in 1605 this document or the extent to which any license under such rights 1606 might or might not be available; neither does it represent that it 1607 has made any effort to identify any such rights. Information on the 1608 IETF's procedures with respect to rights in standards-track and 1609 standards-related documentation can be found in BCP-11. Copies of 1610 claims of rights made available for publication and any assurances of 1611 licenses to be made available, or the result of an attempt made to 1612 obtain a general license or permission for the use of such 1613 proprietary rights by implementors or users of this specification can 1614 be obtained from the IETF Secretariat. 1615 1616 The IETF invites any interested party to bring to its attention any 1617 copyrights, patents or patent applications, or other proprietary 1618 rights which may cover technology that may be required to practice 1619 this standard. Please address the information to the IETF Executive 1620 Director. 1621 1622 1623 Full Copyright Statement 1624 1625 Copyright (C) The Internet Society (2004). All Rights Reserved. 1626 1627 This document and translations of it may be copied and furnished to 1628 others, and derivative works that comment on or otherwise explain it 1629 or assist in its implementation may be prepared, copied, published 1630 and distributed, in whole or in part, without restriction of any 1631 kind, provided that the above copyright notice and this paragraph are 1632 included on all such copies and derivative works. However, this 1633 document itself may not be modified in any way, such as by removing 1634 the copyright notice or references to the Internet Society or other 1635 Internet organizations, except as needed for the purpose of 1636 developing Internet standards in which case the procedures for 1637 copyrights defined in the Internet Standards process must be 1638 followed, or as required to translate it into languages other than 1639 English. 1640 1641 The limited permissions granted above are perpetual and will not be 1642 revoked by the Internet Society or its successors or assignees. 1643 1644 This document and the information contained herein is provided on an 1645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1648 1649 1650 1651 Degioanni & Risso Expires August 30, 2004 [Page 29] 1652 1654 Internet-Draft PCAP New Generation Dump File Format March 2004 1655 1656 1657 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1658 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1659 1660 1661 Acknowledgment 1662 1663 Funding for the RFC Editor function is currently provided by the 1664 Internet Society. 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 Degioanni & Risso Expires August 30, 2004 [Page 30] 1709 1711
