On Jun 10, 2025, at 4:22 PM, Carlos Pignataro <[email protected]> wrote:
> 5. Main reference for TCPDUMP. The text: > The initial version of the registry is provided in Section 2.2.1. In > each case here, the reference should be set to [TCPDUMP] and the RFC > number to be assigned to this document, which is not repeated each > time. > > Points to https://www.tcpdump.org/linktypes.html, but that webpage currently > includes the list of values that is similar but different from the one in the > RFC-to-be. Will this page remove the list in favor of pointing to the RFC? I believe the intent is that the registry established by the RFC would replace the list, in which case the page could point to the RFC and the repository. Note, however, that many of the references for the LINKTYPE_ values are descriptions under https://www.tcpdump.org/linktypes/, so it's not as if that stuff could be removed, unless we have another home for those descriptions. > The private use description in that webpage is conflicting with the RFC also. That page refers to the LINKTYPE_USERn values; that was the historical range for private use. Unfortunately, at least one user of a private type has had their private type leak out into the world (and also let some "local" pcapng block types and options escape, but so it goes), so perhaps adding that range to the "do not assign these, and you probably shouldn't use them, either, as they may complain" area, as described in the current Editor's Copy of the I-D (thanks and a tip of the hat to Mahesh Jethanandani for requesting a clarification). The Editor's Copy (which incorporates some suggestions from Jethanandani) is at https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.html, and the relevant part says Values from 0 to 32767 are allocated following a First-Come First-Served policy (Section 4.4 of [RFC8126]). Values in the ranges 0-10, 50-51, and 98-301 are already assigned; values in the ranges 11-49 and 52-97 MUST not be assigned. > 6. Descriptions: > Many descriptions are changed (streamlined) from [TCPDUMP]. > Quite a number of them start like this: > Description Reserved for […] > > Is the “Reserved for” really meaningful and important when putting this in an > RFC? I would remove all the “Reserved for “. Those are values assigned to the purpose in question, but for which we don't have a good reference and don't have a good detailed description to turn into a page on tcpdump.org. The description is lacking either because 1) it'd take some work to look at code, both tcpdump/Wireshark dissection code and code that generates the packets or 2) the packets require some ugly hacks to interpret them, as they're platform-dependent (PF packet filter logging has entered the chat). > Also, how are some of the replacements chosen? E.g., > LINKTYPE_ENC 109 Encapsulated packets for IPsec. > vs. > Description Reserved for OpenBSD IPSEC encapsulation Chosen with a goal to indicate what it's for without giving details we don't have yet. The idea is that those can be filled in later with a subsequent I-D/RFC. > Also: “IPsec" capitalization Fixed in the Editor's Copy. > These seem to come from the code itself: > #define LINKTYPE_ENC 109 /* OpenBSD IPSEC enc */ > #define LINKTYPE_HIPPI 111 /* NetBSD HIPPI */ > > I guess overall question — has there been an exhaustive comparison / review > of the Descriptions? No. > Like, 208: > /* > * 208 is reserved for an as-yet-unspecified proprietary link-layer > * type, as requested by Will Barker. > */ > > Name Reserved > Number 208 > Description Reserved for an unspecified link-layer type > > The name does not start with LINKTYPE_ The email that resulted in that assignment was https://marc.info/?l=tcpdump-workers&m=119626256708614&w=2 "In addition is it acceptable to have one further value defined for our own proprietary encapsulation type?" The rest of the story was in the thread, but, rereading it, it sounds as if he wanted the assignment before they figured out what packets would look like. He spoke of contributing a dissector to Wireshark but this did not happen, so here we are. This would be another candidate for the "don't assign this, don't use it" list. > Or > Name LINKTYPE_WIHART > Number 223 > Description Reserved for Wireless HART (Highway Addressable Remote > Transducer) > > Has a Reference: > /* > * WirelessHART (Highway Addressable Remote Transducer) > * From the HART Communication Foundation > * IEC/PAS 62591 I provided references for some of the "Reserved for"; perhaps those should be omitted, and only added in a followup I-D/RFC giving either the reference or a pointer to a LINKTYPE_ page on tcpdump.org explaining the relationship between the relevant part of the standard and the format in the capture file. > And, is this one missing? > 32 DLT_REDBACK_SMARTEDGE Redback SmartEdge 400/800. It's missing the phrase "Reserved for". :-) It's also missing from the map of regions of the FCFS space. There might be enough code in the Wireshark dissector to be able to generate a LINKTYPE_REDBACK_SMARTEDGE.html page. > Which one is 201: > LINKTYPE_IPMB_LINUX 209 > LINKTYPE_I2C_LINUX 209 201 is LINKTYPE_BLUETOOTH_HCI_H4_WITH_PHDR, not either of them. 209 is LINKTYPE_I2C_LINUX; LINKTYPE_IPMB_LINUX is a legacy name in the code for it. They're just two names for he same thing. > Nits: > > 1. Mis-indentation on the paragraph describing the DLTs. As in "it's indented"? Michael, is that to set it apart as an FYI note?
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
