Re: [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Mon, 21 Dec 2020 18:39:24 -0800
>
> (Resent, from the correct address this time.)
>
> On Dec 21, 2020, at 5:51 PM, Michael Richardson <mcr+ietf () 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.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers