--- Begin Message ---
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.

--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to