Hi Ron, Thanks for your quick response and update. More thanks for clarifying/confirming that the PROBE mechanism has figured its way out with rfc8335bis and doesn't need this. So, we are looking for improvement (or "fixing"?) of the encoding of the ICMP Extension Structure.
Please check inline below for more detailed responses. Request you to also respond on the points in the comment portion as it would help in getting a closure on the 3rd point in the discuss portion. On Thu, Aug 21, 2025 at 2:00 AM Ron Bonica <[email protected]> wrote: > Hi Ketan, > > See inline......[RB] > > > ------------------------------ > *From:* Ketan Talaulikar via Datatracker <[email protected]> > *Sent:* Tuesday, August 19, 2025 6:50 AM > *To:* The IESG <[email protected]> > *Cc:* [email protected] < > [email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]> > *Subject:* Ketan Talaulikar's Discuss on > draft-ietf-intarea-icmp-exten-hdr-len-07: (with DISCUSS and COMMENT) > > [External Email. Be cautious of content] > > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-intarea-icmp-exten-hdr-len-07: 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!AXjO93HXCQNmYLqSSJ9Sfs3ymYwxAFRjDfZVi7-VHBPMBPdlHV-HOHratk7K_qWIM1swhRBH9U1izpg$ > 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!AXjO93HXCQNmYLqSSJ9Sfs3ymYwxAFRjDfZVi7-VHBPMBPdlHV-HOHratk7K_qWIM1swhRBHu4m5T9U$ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to the authors and the WG for their efforts on this document. I > agree > with the sentiment that the length field should have been introduced in the > ICMP Extension Structure from the outset in RFC4884. > > I support Gorry's DISCUSS position. I have somewhat similar questions on > certain points that remain open and I will attempt to perhaps ask them in a > different way. > > discuss #1 > > Section 1 says "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." > > However, per RFC4884 section 7, there can be only a single ICMP Extension > Structure (at the end of the PDU) but it can contain one or more ICMP > Extension > Objects. This is possible since each extension object has its own length > field > to allow parsing of multiple objects. Am I missing something? > > [RB] I have posted a version 8 with a new introduction. The motivation for > this draft no longer has anything to do with I-D.ietf-intarea-rfc8335bis. > The motivation is simply because we should have done it this way in the > first place (as you say above). > KT> This point is addressed by the v8. Thanks. > > discuss #2 > > Section 1 says "This special handling for PROBE packets is not ideal. For > future use, a mechanism to explicitly specify the extension structure > length > would be beneficial." > > However, draft-ietf-intarea-rfc8355bis does not identify any such > limitation > and neither does it require or need the extensions in this document. Is > this > about RFC 8355 instead? Am I missing something? Could the authors/WG please > share some more context? > > From what I see, the introduction of this new format with a length would > relax > the requirement for an ICMP Extension Structure to be only towards the end > of > the PDU. However, I don't see any such requirements or use-case and if > there > were something, it could perhaps be just as easily modeled as an extension > object within the current extension structure? > > Further, section 4 says "The length of the ICMP Extension Structure can be > inferred from other fields in the packet (e.g., > [I-D.ietf-intarea-rfc8335bis]." > but I am not sure that this is the case with this document. Is this again > about > RFC 8355? > > > [RB] Again, this draft no longer mentions RFC 8445 or > I-D.ietf-intarea-rfc8335bis. > KT> This point as well is addressed. > > discuss #3 > > Section 4 claims that the proposed encoding is backward compatible (i.e., > it > would allow the ICMP Extension Structure to be placed in position other > than at > the end of the PDU), but that claim is false since backward compatibility > works > only if the structure were at the end and in that case there is no use of > this > new encoding in the first place. > > To me, the new encoding would be backward compatible if older > implementations > are able to parse over it (when the extension structure is not at the end) > and/or be able to detect an unsupported version/type and discard it. > > Using a new structure version (3) could have been a more robust mechanism > that > is backward compatible and would be recognized /parsed by older > implementations > and handled as an exception. This also allows for the new version of > extension > structure to be use when there is a requirement for it to be placed other > than > towards the end of the PDU. At the same time, the old version can be > continued > to be used where it can be placed towards the end of the PDU. > > I do not see whether the WG has considered this aspect during the > progression > of this document and I would like to discuss the same. > > [RB] Currently, the only applications that put anything after the ICMP > Extension Headers do so in violation of RFC 8335. This document shouldn't > have to worry about backwards compatibility with them. > > If I-D.ietf-intarea-rfc8335bis is published, they will no longer be in > violation. They will be backwards compatible because of some special > processing rules that Bill Fenner both documents and decries in his > document. > KT> I am not fully convinced of this. Looking at https://datatracker.ietf.org/doc/rfc4884/referencedby/ (and I have not gone through them individually), I get an impression that there may be quite some code out there for parsing the ICMP Extension Structure. The change as proposed is not really backward compatible, in and by itself, but bumping up the version would be (let's say ... more robustly) backwards compatible. Since we are creating something new for usage that has not yet been presented, why not be super careful and bump up the version? Thanks, Ketan > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please find below some questions/comments: > > 1) It is not clear if this new encoding now allow for multiple ICMP > Extension > Structure to be present in the PDU. I believe it is still only one? Can > this be > clarified? > > 2) I find it odd that the document does not callout that the introduction > of > the length field alleviates the requirement for the ICMP Structure to be > only > at the end of the PDU. Does that restriction still apply? > > > > > Juniper Business Use Only >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
