The table below lists link-layer header types used in pcap and pcap-ng capture files. The LINKTYPE_ name is the name given to that link-layer header type, and the LINKTYPE_ value is the numerical value used in capture files. The DLT_ name is the name corresponding to the value (specific to the packet capture method and device type) returned by pcap_datalink(3PCAP); in most cases, as pcap-linktype(7) mentions it, the LINKTYPE_ value and DLT_ value are the same, but, in some cases, they differ, for reasons of binary compatibility, with the DLT_ value being different on different platforms.

Note that these values correspond to particular header formats; there might be multiple link-layer header types for a given link-layer protocol, as, for a given link-layer header type, the header for the link-layer protocol might be preceded by a pseudo-header giving additional information, or might be transformed in some way from the way it's specified for that link-layer protocol, e.g. fields in the link-layer protocol header might be removed, added, moved, or modified.

• Values in the range DLT_USER0–DLT_USER15 (147–162, both inclusive) are reserved for private use; if you have some link-layer header type that you want to use within your organization, with the capture files using that link-layer header type not ever be sent outside your organization, you can use one or more of these values. No libpcap release will use these for any purpose, nor will any tcpdump release use them, either.

  Do NOT use these in capture files that you expect anybody not using your private versions of capture-file-reading tools to read; in particular, do NOT use them in products, otherwise you may find that people won't be able to use tcpdump, or snort, or Wireshark, or… to read the capture files from your firewall/intrusion detection/traffic monitoring/etc. appliance, or whatever product uses that link-layer header type value, and you may also find that the developers of those applications will not accept patches to let them read those files.

  Please also be aware that there is an IETF process at: pcaplinktype which will replace all above processes with an IANA.org process.

  Also, do not use them if somebody might send you a capture using them for their private type and tools using them for your private type would have to read them.

• All other values listed in the table below are assigned.

• Any values not listed in the table below are reserved for future use and can be assigned subject to due process.

Please remember that initial prototyping and experimentation can and should be done using the DLT_USERx private use values. If you need a value for a particular set of link-layer headers, you must request one; to do so:

• Subscribe to the mailing list and send a message with the request.

  Please include either an indication of the standard that describes the link-layer headers, a link to a permanent and public page describing the link-layer headers, or a detailed description of the link-layer headers. If the headers do not exactly match the description in a standard or standards—for example, if fields are added, removed, or reordered, or have their size, endianness or format changed—please describe all differences in detail.

• Prepare libpcap changes for the new value:

  • In pcap/dlt.h add the new DLT_ value and the associated comments, increment DLT_MATCHING_MAX.
  • In pcap-common.c add the new LINKTYPE_ value (omit the comments if the previous step explains everything sufficiently well), increment LINKTYPE_MATCHING_MAX.
  • In pcap.c add the new value to dlt_choices[].
  • Check everything and open a pull request with the changes.

• Prepare web site changes for the new value:

  • If there is no other specification readily available for the new header type, create a new htmlsrc/linktypes/LINKTYPE_xxxxx.html file and document the new header structure.
  • In htmlsrc/linktypes.html (this file) add the new value to the bottom of the table.
  • Generate complete HTML files from the file(s) above as explained here.
  • Check everything and open a pull request with the changes.

• Have patience.

  Be ready to answer questions and to address any technical issues that emerge during the review. This sometimes takes longer than expected, but it is important to get every detail right because after the assignment the new header structure should be set in stone.

Do NOT add new values to this list except as explained above. Otherwise, you run the risk of using a value that's already being used for some other purpose, and of having tools that read libpcap-format captures not being able to handle captures with your new link-layer header type value, with no hope that they will ever be changed to do so (as that would destroy their ability to read captures using that value for that other purpose).

Do NOT use any of these link-layer header type values unless your link-layer headers EXACTLY match the specification. If they do not exactly match, request a new link-layer header type for them.