On Aug 30, 2025, at 10:58 AM, Michael Richardson <[email protected]> wrote:
> I don't feel confident that we didn't miss a comment, but posting -11 anyway.
The list of reviews at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/
has comments on various versions of the document.
First and only comment on -04:
https://datatracker.ietf.org/doc/review-ietf-opsawg-pcaplinktype-04-genart-lc-halpern-2024-08-15/
The email thread for that begins at
https://mailarchive.ietf.org/arch/msg/gen-art/cuLKJjZwBKVbeKclE4YB4E4VMz0/. The
original message reports
Major issues:
While it may be vacuous, it is necessary to include a security
considerations section.
which is now fixed and
Minor issues:
(Unclear if this is Major or Minor): The table layout for the IANA
registry
fails to conform to I-D / RFC requirements. Considered as text, it is
much
too wide. Considered as HTML, the normal rendering blocks important
parts
of the table. I recommend asking the RPC and IANA how to format the I-D
so
as to produce a suitable RFC.
which would probably be considered fixed by michael's reformatting of the
LinkType list.
First and only comment on -05:
https://datatracker.ietf.org/doc/review-ietf-opsawg-pcaplinktype-05-intdir-lc-bernardos-2024-08-22/
The email thread for that begins at
https://mailarchive.ietf.org/arch/msg/int-dir/Y_V1GCEOIusCsXwzOHKXyIKf_1w/, and
has only the initial message. The only issue raised in the document that might
not be fixed is
- “Linktypes” and LINKTYPE” are used sometimes with the same meaning (I
guess).
as -11 speaks of LinkTypes - LINKTYPE only appears in the names - but the
Guidance for Designated Experts says:
When the contents of the link type can contain an IPv4 or IPv6
header, then the octets between the beginning of the link type and
the IP header needs to be clear.
...
LinkTypes may be allocated for specifications not publicly available
may be made within the FCFS range. This includes specifications that
might be subject to a security classification. The minimal
requirement is to provide a contact person for that link type.
Michael, I think you wrote that section - should the remaining uses of "link
type" become LinkType? (The first of the two paragraphs is also a bit unclear.)
First comment on -10:
https://datatracker.ietf.org/doc/review-ietf-opsawg-pcaplinktype-10-artart-lc-reschke-2025-06-11/
The email thread for that begins at
https://mailarchive.ietf.org/arch/msg/art/vvNXtopxCuE3_XRil46MhsVs-X8/.
Michael's response at
https://mailarchive.ietf.org/arch/msg/art/vWkGSvdErcws9cbd-tSOAoqJJGo/
addresses these issues.
Second comment on -10:
https://datatracker.ietf.org/doc/review-ietf-opsawg-pcaplinktype-10-tsvart-lc-scharf-2025-06-11/
The email thread for that begins at
https://mailarchive.ietf.org/arch/msg/tsv-art/aQq5q6yK2atsCNx5i0EX7c_R850/.
The only issues that are not addressed are:
- Section 2.2: There may be an implicit assumption that "LinkType Name" is
written in all-capital letters.
as the -11 draft doesn't explicitly indicate that what comes *after* LINKTYPE_
is a combination of capital letters, digits, and underscores - should the draft
be updated to do so? - and
- Section 2.2.2: There may be an implicit assumption that entries in the
registry will only be added, as neither maintenance (e.g., change of a
contact
person) nor removal procedures are specified. As long as only additions
have to
be dealt with, the current specification seems sufficient. Otherwise
additional
considerations on maintenance and removal could make sense, e.g., similar to
RFC 6335.
as we haven't added anything about update or removal features.
I don't expect entries to be removed; RFC 6335 also speaks of "De-Assignment",
"Reuse", and "Revocation", but I don't expect those to be done, either. The
demand for LinkTypes will probably not exceed the values available in the FCFS
range, so I see no need to recycle LinkType values and, even if the need for a
given LinkType may fade away (e.g., LINKTYPE_IEEE802_5), there may still be
capture files using them, so it'd probably be best not to remove them and reuse
the value for a different LinkType.
That just leaves modification, which RFC 6335 doesn't mention. Those would
presumably be editorial modifications to the description or to the reference,
to clarify them or update them. Perhaps there needs to be a procedure for
that, but I'd see it as "run the change past the Designated Experts and either
get the reference changed or, if necessary, produce an I-D -> RFC updating a
particular entry.
See my responses in the thread.
Third comment on -10:
https://datatracker.ietf.org/doc/review-ietf-opsawg-pcaplinktype-10-opsdir-lc-contreras-2025-07-30/
The email thread for that begins at
https://mailarchive.ietf.org/arch/msg/ops-dir/1SdzAfqKhTs2t4Y5gOOHEnPGEQE/.
Issues that might not be resolved are here, along with my response in
https://mailarchive.ietf.org/arch/msg/ops-dir/x7PWidroMCGBjngmS4FnrJdA_SA/ and
my further comment at this time.
The first such issue is:
>> /* Comments */
>> - Section 2.2. It is stated that "LinkType values 147 to 162 named
>> LINKTYPE_RESERVED_xx were originally reserved for Private Use. Their use is
>> Deprecated in favour of the values in the 65001-65535 range." It is not clear
>> to me if this implies that LinkType values 147 to 162 are then available for
>> new allocations or if it is recommended not being used because of their
>> previous usage as reserved values. In any case, a clarification statement for
>> this is advisable. Note that if those values are intended to be allocatable,
>> then it could be convenient to describe any implication in terms of backward
>> compatibility.
>
> They should be treated the same way as the values in the 65001-65535 range,
> and not allocated, to avoid collisions with internal private use of them.
-10 says:
The policy allocation for the LinkType values is as follows:
* Values from 32768 to 65000 must be allocated via Specification
Required (Section 4.6 of [RFC8126]). Guidance for Designated
Experts is provided in Section 2.2.2.
* 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.
* Values from 65001 to 65535 are reserved for Private Use
(Section 4.1 of [RFC8126]).
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.
The initial contents of the table are based upon the Link type list
maintained by libpcap, and published on [TCPDUMP].
Note that historically, values were assigned incrementally following
First Come First Served (FCFS) policy, with a preference for a public
specification, but with no mandate. Some historical values may have
less specification than desired.
LinkType values 147 to 162 named LINKTYPE_RESERVED_xx were originally
reserved for Private Use. Their use is Deprecated in favour of the
values in the 65001-65535 range.
In general, Private Use values should never leak out of the entity
that uses it. As the FCFS range is large and easily obtained,
official values are recommended.
-11 changes the policy allocation bullet list to:
* Values from 0 to 65000 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.
* Values from 65001 to 65535 are reserved for Experimental Use
(Section 4.2 of [RFC8126]).
and changes the paragraph about the 147-162 range to:
LinkType values 147 to 162 named LINKTYPE_RESERVED_xx were originally
reserved for Experimental/Private Use. Their use is Deprecated in
favour of the values in the 65001-65535 range.
The values in the range 147-162 probably SHOULD NOT be used for
Experimental/Private use. This is because 149, which should be avoided due to a
mistake Apple made that might cause programs built using Apple's version of
libpcap to produce files using that value rather than LINKYPE_PKTAP, and other
organizations might have made similar mistakes for that value or other values.
Is
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.
sufficient to indicate that 147-162 are not to be used?
The second such issue is:
>> - No reference is provided for LINKTYPE_ETHERNET even though the
>> description refers to IEEE 802.3 Ethernet. Should not be added a reference to
>> the appropriate specification by IEEE?
>
> We could, although I'm not inclined to refer to a particular *version* of
> 802.3.
My intent there is to avoid somebody asking "can LINKTYPE_ETHERNET be used for
802.3-2028, as the Registry says 802.3-2022 and doesn't mention 02.3-2028?"
The third such issue is:
>> - Link types 11 to 49 are described as "not to be use"
>> values, but there is not justification for it in the text (Section 2.2
>> introduces different cases but not this one). Please provide some information
>> about why these numbers should not be used. Same for values 52 to 98.
>
> The tcpdump.org group somewhat arbitrarily decided to start handing out new
> link-layer type numbers at 100, in order to avoid any unannounced assignments
> by other in the range below that.
Do we need to state this, or is
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.
in -11 sufficient?
The fourth such issue is:
>> - No reference is provided for LINKTYPE_RAW even though the description
>> refers to
>> IPv4 and IPv6. Should not be added a reference to the appropriate
>> specification
>> by IETF?
>
> Yes, we could.
>
>> By the way, it seems to be redundant with Number 228 and 229.
>
> Or, rather, the latter two are redundant with LINKTYPE_RAW, which existed
> long before LINKTYPE_IPV4 and LINKTYPE_IPV6 were assigned.
>
> They were requested in https://seclists.org/tcpdump/2009/q1/193.
>
> I asked the same question in https://seclists.org/tcpdump/2009/q1/194 - "What
> does the link-layer header on those packets look like? Are they just raw IPv4
> packets with no link-layer header? If so, that's DLT_RAW."
>
> He responded in https://seclists.org/tcpdump/2009/q1/195 - "And it sounds
> like DLT_RAW is what to use here - ok."
>
> So I'm not sure why I added them in 2010, but here we are.
Should we point to RFC 791 and 8200 for LINKTYPE_RAW, to 791 for LINKTYPE_IPV4,
and 8200 for LINKTYPE_IPV6 as references?
As for the redundancy, which is the result of historical mistakes, currently
tcpdump reports errors for IPv6 packets on LINKTYPE_IPV4 and IPv4 packets on
LINKTYPE_IPV6, while Wireshark treats LINKTYPE_IPV4 and LINKTYPE_IPV6 as
equivalent to LINKTYPE_RAW. I don't remember any complaints having been made
about either behavior, which probably indicates that nobody's ever written
non-IPv4 packets with LINKTYPE_IPV4 or non-IPv6 packets with LINKTYPE_IPV6. We
probably don't have any need to say anything more about LINKTYPE_IPV4 or
LINKTYPE_IPV6
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
