On Jun 9, 2025, at 8:17 PM, Guy Harris <[email protected]> wrote: > On Jun 9, 2025, at 5:29 PM, Mahesh Jethanandani <[email protected]> > wrote: > >> Section 2.2, paragraph 8 >>> * Values from 0 to 32767 are allocated following a First-Come First- >>> Served policy (Section 4.4 of [RFC8126]). Note that this category >>> includes the historical allocations which have an uneven level of >>> definition. >> >> What happens if a value in this range has been in use historically? > > For values that have already been allocated and appear in this document, but > that have historically been used by somebody for another purpose, the value > in the document overrides the other purpose, and people trying to read files > using the value for its historical purpose will have to find some way to work > around the problem, such as "allocate a new value for that purpose, start > using that new value, and use a tool to modify pcap and pcapng files using > the value with its historical meaning with the new value. > > For values > 301, which is the highest allocated value at present, the answer > is the same. > > For values < 301 not documented here, we should probably fill them in, even > if it's only with "Reserved for XXX".
All the values from 0 to 301 are covered, in some fashion, in the document. The subrange 11-49 is marked as "do not use"; some of those are in the problematic range of "same DLT_ name, different values". If anything in that subrange was used historically, it can be, but it may be a case of "good luck getting it read the same way on an OS other than the one on which the capture was made", for the aforementioned "same DLT_ name, different values" issue. No value in that subrange should *ever* be allocated. The subrange 52-98, which is marked as "Reserved"/"Do not use these values", was deliberately skipped because 50 and 51 were used by NetBSD, and, when I started handing out new LINKTYPE_ numbers, I wanted to skip that range to avoid collisions. If anything in that subrange was used historically, it can be. No value in that subrange should *ever* be allocated. If any historical use of a value in the remaining subranges 0-10, 50-51, or 98-301, including values described as "Reserved for ...", doesn't match this document, they lose. This includes 208, which is marked as "Reserved for an unspecified link-layer type"; the pcap/dlt.h header for libpcap says "is reserved for an as-yet-unspecified proprietary link-layer type, as requested by Will Barker" - I think he asked for it as some internal type, similar to IBM's request for LINKTYPE_IBM_SP, which was assigned 145 and is described as "Reserved for IBM SP switch", and LINKTYPE_IBM_SN, which was assigned 146, and it described as "Reserved for IBM Next Federation switch". (A mechanism by which an organization can specify a link-layer header type that's independent of the version managed via the registry might be useful. The pcapng mechanisms for block and option types, wherein there are block and option type values that are reserved for "custom blocks" and "custom options", and where the block or option contents begins with a Private Enterprise Number, suggests a similar mechanism for LinkTypes, with one LinkType value reserved for "custom LinkTypes", and with, for pcapng, the Interface Description Block also providing a Private Enterprise Number as an option. It might be possible to reuse one of the currently-unused fields in the pcap file header to hold the PEN. However, that's a discussion for another day and another I-D.) > Fixed in the Editor's Copy. ...which can be found at https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.html. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
