Hi Ron, My point was not whether those documents propose putting ICMP Extension Structure at a position other than at the end of the PDU, but that there may be users of this structure beyond the PROBE.
Could you please respond to the questions that I placed in the comments sections? They will help improve my understanding of the actual proposal. Thanks, Ketan On Thu, Aug 21, 2025 at 9:19 PM Ron Bonica <rbon...@juniper.net> wrote: > Inline...... > > > ------------------------------ > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > *Sent:* Thursday, August 21, 2025 12:32 AM > *To:* Ron Bonica <rbon...@juniper.net> > *Cc:* The IESG <i...@ietf.org>; > 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> > *Subject:* Re: Ketan Talaulikar's Discuss on > draft-ietf-intarea-icmp-exten-hdr-len-07: (with DISCUSS and COMMENT) > > *[External Email. Be cautious of content]* > > 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 <rbon...@juniper.net> wrote: > > Hi Ketan, > > See inline......[RB] > > > ------------------------------ > *From:* Ketan Talaulikar via Datatracker <nore...@ietf.org> > *Sent:* Tuesday, August 19, 2025 6:50 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:* 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/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc4884/referencedby/__;!!NEt6yMaO-gk!Ebh1O9pqeFvInnwWB8PImgpyOcPfVzLHlon1qpcetkpGoD1uPmKVUDuTBkVNLTz_uUdzAna2BeHKeHb7MkYl$> > (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? > > [RB] I have just take a quick look through all of the RFCs in > https://datatracker.ietf.org/doc/rfc4884/referencedby/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc4884/referencedby/__;!!NEt6yMaO-gk!Ebh1O9pqeFvInnwWB8PImgpyOcPfVzLHlon1qpcetkpGoD1uPmKVUDuTBkVNLTz_uUdzAna2BeHKeHb7MkYl$>. > I may have missed something, but I don't think that any of them add > anything after the ICMP Extension Structure. > > I have not looked at the documents that are not yet RFCs. But they MUST > NOT add anything after the extension structure unless the extension header > has a length attribute. > > Ron > > > 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 > > Juniper Business Use Only > >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
