Gorry,
Regarding Item 3, would you accept the following alternative text for Section 1.
OLD>
The ICMP Extension Structure [RFC4884] does not have a length field. This means
it is expected to be the last element of an ICMP message. However, there are
cases where additional fields need to be inserted after the ICMP Extension
Structure.
For example, [I-D.ietf-intarea-rfc8335bis] enhances the PROBE utility
by adding a new field to ICMP Extended Echo and ICMP Extended Echo
Reply messages. To maintain compatibility with existing PROBE
implementations, this new field is placed after the ICMP Extension
Structure.
Because the ICMP Extension Structure does not have a length field,
[I-D.ietf-intarea-rfc8335bis] requires implementations to determine
the length of the extension structure from the known message format
and the assumption that these packets contain only a single ICMP
Extension Object.
This special handling for PROBE packets is not ideal. For future use, a
mechanism to explicitly specify the extension structure length
would be beneficial.
This document adds a length field to the ICMP Extension Header. It does not
define data items that might follow the ICMP Extension
Structure.
The specifications of this document apply to all ICMP Extension Structures,
regardless of whether they appear in ICMPv4 [RFC0792] or ICMPv6 [RFC4443]
messages. This document UPDATES [RFC4884].
<OLD
NEW>
The ICMP Extension Structure [RFC4884] has variable length. However, it does
not include a field that reflects its length. Therefore, implementations can
parse the ICMP Extension Structure only when it appears at the end of an ICMP
message.
It is good practice for a variable-length data structure to include a field
that reflects its length. This allows implementations to parse the structure
even when it does not appear at the end of a message. The ICMP Extension
Structure includes reserved bits that are available for this purpose.
This document adds a length field to the ICMP Extension Header. It does not
define data items that might follow the ICMP Extension Structure.
The specifications of this document apply to all ICMP Extension Structures,
regardless of whether they appear in ICMPv4 [RFC0792] or ICMPv6 [RFC4443]
messages.
This document UPDATES [RFC4884].
<NEW
Ron
Juniper Business Use Only
________________________________
From: Gorry Fairhurst via Datatracker <nore...@ietf.org>
Sent: Wednesday, August 13, 2025 5:19 AM
To: The IESG <i...@ietf.org>
Cc: draft-ietf-intarea-icmp-exten-hdr-...@ietf.org
<draft-ietf-intarea-icmp-exten-hdr-...@ietf.org>; intarea-cha...@ietf.org
<intarea-cha...@ietf.org>; int-area@ietf.org <int-area@ietf.org>;
g...@gigix.net <g...@gigix.net>; g...@gigix.net <g...@gigix.net>
Subject: Gorry Fairhurst's Discuss on draft-ietf-intarea-icmp-exten-hdr-len-05:
(with DISCUSS and COMMENT)
[External Email. Be cautious of content]
Gorry Fairhurst has entered the following ballot position for
draft-ietf-intarea-icmp-exten-hdr-len-05: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DkI_J3IH2rhsM-bBLn78Irzi7uc0aVmcJ2fv0tHH1My0Iv5dpWrYmmswv1APQEk1OV-WzyxGL-Df16s$
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-intarea-icmp-exten-hdr-len/__;!!NEt6yMaO-gk!DkI_J3IH2rhsM-bBLn78Irzi7uc0aVmcJ2fv0tHH1My0Iv5dpWrYmmswv1APQEk1OV-WzyxG4_S6sy0$
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thanks for the work is described in this document. I read this I-D as proposing
addition structure to the format of the ICMP payload.
As noted in
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/__;!!NEt6yMaO-gk!DkI_J3IH2rhsM-bBLn78Irzi7uc0aVmcJ2fv0tHH1My0Iv5dpWrYmmswv1APQEk1OV-WzyxGZeTwSHQ$
,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.
Please find below the following blocking DISCUSS points:
(1) Will this document when published update RFC 4443 (ICMPv6),
or is this ONLY for IPv4?
(2) Based on (1) above: The I-D states the length is measured in 4-byte words.
This could be appropriate for IPv4, please indicate whether this is also the
case for IPv6 or ought that to be 8-byte aligned?
(3) I am sure there could be useful uses and I would like to understand the
motivation for this new header; please explain. I would expect this to be
described clearly in the intro of this I-D.
(4) Please specify what the *receiver* action should be if the new length field
does not equal the sum of component objects. Is this malformed message
to be sliently discarded, the extension to be ignored (and what about
any following extensions), or something else?
(The TSV-ART review has more text that might be useful background).
(5) What is the *receiver* action when the received padding is malformed
and does not align to a 4-byte boundary? Is this malformed message
to be sliently discarded, the extension to be ignored (and what about
any following extensions), or something else?
(6) Please could you clarify whether a conformant implementation of RFC 4884
is permitted to discard a message when Reserved field is zero on receipt?
- Where does RFC 4884 state this or os this undefined in that RFC?
(This is related to text at the start of section 4 of the new I-D).
(The TSV-ART review might be useful background).
Finally, since many of the above details can be hard to see, I would like to
discuss if section 5 of this I-D can be made much more clear concerning the
specific text that it updates in RFC 4884, by citing the relevent sections
in RFC 4884 and quoting the OLD text and the NEW text.
text.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Please find below the following comments that I hope will help improve the next
in the next revision of this draft:
* Thanks for Joe Touch's TSV-ART review here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-intarea-icmp-exten-hdr-len-04-tsvart-lc-touch-2025-08-01/__;!!NEt6yMaO-gk!DkI_J3IH2rhsM-bBLn78Irzi7uc0aVmcJ2fv0tHH1My0Iv5dpWrYmmswv1APQEk1OV-WzyxGMChIxYY$
- please read and consider these as inputs to the next revision of this I-D.
* The I-D says in para 1 of sect 1:
"This means it is expected to be the last element of an ICMP message."
A similar claim is made at the start of section 3.
- I am not sure this is necessarily so, the length can be calculated by the sum
of the objects and the header, and hence I do not see the claim in RFC4884.
* As I understand, RFC4884 supports an extension header with
"one or more extension objects”. Each object already contains a length field
in that object. So, does the proposed change to the Reserved field basically
indicate the sum of these lengths plus the length of the extension header?
(If so, this could be made more clear in the introduction.)
* [I-D.ietf-intarea-rfc8335bis] is cited several times, but as I would expect,
rfc8335bis does not depend upon this I-D. It does not even reference it.
If this is not important to this draft, why is it discussed here? Could
this text simply be removed, this could by a clearer motivation?
* The I-D states:
"Therefore, implementation MUST NOT drop packets if this field is
set to 0."
- This new formal requirement seems odd to me. I'd expect that an implementation
of this I-D is allowed to drop packets if configured to do so? - If so then,
perhaps a helpful way is to explicitly state the original text from RFC4884,
and the replacement text after this is updated that permits this new field
to be used.
* Section 4 as written appears to add a new normative requirement on
an old specification, stating:
"The ICMP Extension Structure MUST be the final item in the ICMP packet."
- Please justify or remove this requirment (e.g. replace by /MUST/can/).
* Since this I-D could be read as a method for adding additional "bytes"
to an ICMP message payload, I think some text clarifying the sender processing
for IPv6 would be very helpful (if IPv6 is supported).
For ICMPv6, I expect the original datagram" field always contains as many octets
as possible without causing the ICMP message to exceed the minimum
IPv6 MTU (i.e., 1280 octets).
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
