Hi Ron, Thanks for your responses.
In summary : 1) There can be one and only one ICMP Extension Structure in a PDU per RFC4884. This remains unchanged. 2) The introduction of the length field removes the restriction that the ICMP Extension Structure is only present towards the end of the PDU. i.e., it can now be anywhere in the PDU. Please clarify the above in the document. Now, coming to the backward compatibility aspect. Let us say a new use-case that is using the encoding scheme proposed in this document generates a PDU with the ICMP Extension Structure that is somewhere in the middle of the PDU (i.e., not last) - another TLV or something else is encoded after this structure. Then this packet arrives for processing at a node that does not understand this new encoding and hence ignores the length field. It then starts parsing the individual objects in the structure, one by one (each object has its length so unknown objects are skipped over). At one point, it has parsed all the objects encoded by the sender, but it would not know that it has reached the end of the ICMP structure since it didn't understand the length field. So, it continues to read what follows the ICMP Extension Structure and will end up wrongly decoding what follows as arbitrary ICMP extension objects until the end of the PDU. This is a problem and therefore the proposed encoding solution is not backwards compatible. The solution is simple - bump up the ICMP Extension Structure to 3. This way, any old node recognizes it as an unknown/unsupported structure and ignores it (likely drops the packet). It is more robust than reading garbage. There is no downside since a use-case that uses this new encoding scheme is yet to be defined. I hope that clarifies the last remaining point in my DISCUSS position. Thanks, Ketan PS: My responses may be slow next week On Fri, Aug 22, 2025 at 1:10 AM Ron Bonica <[email protected]> wrote: > Responses to the comments, below [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? > > 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? > > 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. > > > ---------------------------------------------------------------------- > 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? > > Sadly, RFC 4884 doesn't make an explicit statement about how many > extension headers are allowed in an ICMP message. However, the following > text from the Abstract of RFC 4884 implies that there can only be one. > > "Multi-part messages are supported by an ICMP extension structure. The > extension structure is situated at the end of the ICMP message. It > includes an extension header followed by one or more extension objects. > Each extension object contains an object header and object payload. All > object headers share a common format." > > If you like I say make an explicit statement in this document. > > > 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? > > That is odd. It is the motivation of for the document. I can add text. > > > > > > Juniper Business Use Only >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
