]>

gharris@sonic.net

Sandelman Software Works Inc

mcr+ietf@sandelman.ca http://www.sandelman.ca/

This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. About This Document Status information for this document may be found at . Discussion of this document takes place on the opsawg Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In the late 1980's, Van Jacobson, Steve McCanne, and others at the Network Research Group at Lawrence Berkeley National Laboratory developed the tcpdump program to capture and dissect network traces. The code to capture traffic, using low-level mechanisms in various operating systems, and to read and write network traces to a file was later put into a library named libpcap . Other documents describe the original (legacy) format used by tcpdump (pcap), as well as the revised format (pcapng) which is used by tcpdump and Wireshark . Within those formats each packet that is captured is described by a LINKTYPE value. The LINKTYPE value selects one of many hundred formats for metadata and Layer 2 encapsulation of the packet. This document creates an IANA registry for the LINKTYPE format, establishing the IANA Considerations by which other uses of the pcap and pcapng formats may register new LINKTYPE values.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

IANA Considerations

PCAP Registry IANA is requested to create a new registry group entitled "The PCAP Registry".

LinkType Registry IANA is also requested to create a registry entitled "PCAP LinkType List" under The PCAP registry group (). The registry has the following structure:

• LINKTYPE Name: Indicates the symbolic name for this LinkType. The name is prefixed with "LINKTYPE_" (i.e., LINKTYPE_something).
• LINKTYPE Value: Indicates the integer value assigned for this LinkType.
• Description: Provides a very short description.
• Reference: Indicates an authoritative the document reference for the LinkType or a requester reference.

The LinkType value is a 16-bit number. The policy allocation for the LinkType values is as follows:

• Values from 0 to 32767 must be allocated via Specification Required (). Guidance for Designated Experts is provided in Section X.
• Values from 32768 to 65000 are allocated following a First-Come First-Served policy ().
• Values from 65001 to 65535 are reserved for Private Use ().

The initial version of the registry is provided in . In each case here, the reference should be to and the RFC number to be assigned to this document, which is not repeated each time. The initial values table is based upon the Link type list maintained by libpcap, and published on . Note that historically, values were assigned incrementally following First Come First Served policy, with a preference for a public specification, but with no mandate. Some historical values may have less specification than desired. LinkType values 147 to 162 named LINKTYPE_RESERVED_xx were originally reserved for Private Use. Their use is Deprecated in favour of the values in the 65001-65535 range. In general, Private Use values should never leak out of the entity that uses it. As the First Come First Served range is large and easily obtained, official values are recommended.

• There is often an associated DLT value which is often identical in value, but not universally so. DLT values are associated with specific operation system captures, and are operating system specific, and are thus not subject to standardization.

Initial Values Option A: Initial Values of "PCAP LinkType List" Registry

Value:

0

Name:

LINKTYPE_NULL

Description:

BSD loopback encapsulation

Reference:

Value:

1

Name:

LINKTYPE_ETHERNET

Description:

IEEE 802.3 Ethernet

Reference:

-

Value:

189

Name:

LINKTYPE_USB_LINUX

Description:

USB packets, beginning with a Linux USB header, as specified by the struct usbmon_packet in the Documentation/usb/usbmon.txt file in the Linux source tree. Only the first 48 octets of that header are present. All fields in the header are in host byte order. When performing a live capture, the host byte order is the byte order of the machine on which the packets are captured. When reading a pcap file, the byte order is the byte order for the file, as specified by the file's magic number; when reading a pcapng file, the byte order is the byte order for the section of the pcapng file, as specified by the Section Header Block

Reference:

-

Value:

237

Name:

LINKTYPE_STANAG_5066_D_PDU

Description:

D_PDUs as described by NATO standard STANAG 5066, starting with the synchronization sequence, and including both header and data CRCs. The current version of STANAG 5066 is backwards-compatible with the 1.0.2 version , although newer versions are classified

Reference:

---------------------------------------------- Option B: Initial Values of "PCAP LinkType List" Registry Initial Values of the "PCAP LinkType List" Registry

Value	Name Description	Reference
0	LINKTYPE_NULL BSD loopback encapsulation
1	LINKTYPE_ETHERNET IEEE 802.3 Ethernet
189	LINKTYPE_USB_LINUX USB packets, beginning with a Linux USB header, as specified by the struct usbmon_packet in the Documentation/usb/usbmon.txt file in the Linux source tree. Only the first 48 octets of that header are present. All fields in the header are in host byte order. When performing a live capture, the host byte order is the byte order of the machine on which the packets are captured. When reading a pcap file, the byte order is the byte order for the file, as specified by the file's magic number; when reading a pcapng file, the byte order is the byte order for the section of the pcapng file, as specified by the Section Header Block
237	LINKTYPE_STANAG_5066_D_PDU D_PDUs as described by NATO standard STANAG 5066, starting with the synchronization sequence, and including both header and data CRCs. The current version of STANAG 5066 is backwards-compatible with the 1.0.2 version , although newer versions are classified

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References n.d. n.d. n.d. n.d. 3GPP TS 04.64 n.d. ANSI/ASHRAE Standard 135 n.d. Red Hat, Inc. CodeFactory AB Red Hat, Inc. Imendio AB Collabora Ltd. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. ITU-T Recommendation G.7041/Y.1303 n.d. ITU-T Recommendation G.9959 n.d. ITU-T Recommendation H.222.0 n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. ITU-T Recommendation Q.703 n.d. ITU-T Recommendation Q.704 n.d. ITU-T Recommendation Q.711 n.d. ITU-T Recommendation Q.712 n.d. ITU-T Recommendation Q.713 n.d. ITU-T Recommendation Q.714 radiotap.org n.d. n.d. ITU-T Recommendation Q.920 n.d. ITU-T Recommendation Q.921 n.d. STANAG 5066 n.d. n.d. This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK] This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK] This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community. This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK] This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK] This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK] This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.