[pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations
Guy Harris
guy at alum.mit.edu
Tue Dec 22 02:23:34 UTC 2020
On Dec 21, 2020, at 5:51 PM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:
> The short of it is:
>
> 1) reserve bits 16:28 of linktype as zero.
In pcap files, presumably; you have only bits 0:15 in pcapng IDBs.
Note that the registry is for both pcap and pcapng, so the specs should say that.
> 2) lower 32K Specification Required (any document),
> upper 32K First Come First Served
>
> Details:
> The Registry has three sections according to {{RFC8126}}:
> * values from 0 to 32767 are marked as Specification Required.
> * except that values 147 to 162 are reserved for Private Use
> * values from 32768 to 65000 are marked as First-Come First-Served.
> * values from 65000 to 65536 are marked as Private Use.
Presumably "to 65535" - 65536 doesn't fit in the 16-bit pcapng field.
So, for FCFS, does that mean anybody who wants a linktype can just grab one?
And, as per my idea of using 65535 to mean "custom linktype", similar to pcapng custom blocks and options, with either:
the pcap file header/pcanng IDB option containing a Private Enterprise Number and private linktype number;
the pcap file header/pcanng IDB option containing a Private Enterprise Number, with any linktype specifier being in the link-level header;
the Private Enterprise Number and anything else being in the link-level header;
should we reserver 65535?
> I did some editing of the description field to shorten in a lot, but I got
> tired about 30% through the list, not sure if we should even include that
> column.
> There are many entries like:
> LINKTYPE_PPP_ETHER | 51 |PPPoE; per RFC 2516
That one's there for NetBSD; I *think* the packet contains just a PPPoE header and payload. I may have to dig into the NetBSD code to see what they do.
More information about the pcap-ng-format
mailing list