"Custom" link-layer types for pcap and pcapng

[Guy Harris <gharris () sonic net>]

Here's the proposal for "custom" link-layer types I threatened^Wpromised in my earlier email.

A link-layer type value of 0xFFFF will be reserved as LINKTYPE_CUSTOM, with libpcap offering a DLT_CUSTOM.

A custom link-layer type has a 32-bit IANA-registered Private Enterprise Number (PEN):

        https://en.wikipedia.org/wiki/Private_Enterprise_Number

        https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

as is used for custom pcapng blocks and options.

We could either 1) also say it should have a 32-bit per-vendor link-layer type number or 2) say that if the vendor 
plans to use it for more than one type of link-layer header, they have to arrange that the link-layer header should 
begin with information necessary to determine what the *rest* of the link-layer header is.

2) is more along the lines of the way custom block and options work.  However:

        every non-custom block includes a block type, and every non-custom option has an option type, but not every 
*block* in a capture file has a link-layer header type - a pcap header has a link-layer type that applies to all 
packets in the file and a pcapng IDB has a link-layer type that applies to all packets on that interface;

        knowing the link-layer type up front makes it easier to generate BPF filter code for an interface, if we 
support these types for live capture (or if the vendor's private capture mechanism supports it);

so I'm inclined to go with 1).

In that model:

        in pcap files, if the lower 16 bits of the 32-bit link-layer type value is 0xFFFF, the two "Reserved" fields 
(which were formerly a rarely-if-ever-used and not-supported-by-libpcap-or-Wireshark time zone offset and time stamp 
resolution) MUST contain the PEN and vendor-specific link-layer type;

        in pcapng file, if the link-layer type in an IDB is 0xFFFF, the IDB *MUST* contain a new option, containing the 
PEN and vendor-specific link-layer type.

Given that it's for *two* capture file formats, these lists are probably better places for discussion than having two 
pull requests and discussing them in comments there.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe