Inline......
________________________________ From: Ketan Talaulikar <[email protected]> Sent: Thursday, August 21, 2025 12:32 AM To: Ron Bonica <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: Hi Ketan, See inline......[RB] ________________________________ From: Ketan Talaulikar via Datatracker <[email protected]<mailto:[email protected]>> Sent: Tuesday, August 19, 2025 6:50 AM To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[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/<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 -- [email protected] To unsubscribe send an email to [email protected]
