Hi, Speaking as an Int Area participant, given the IESG DISCUSS comments and that the authors appear to disagree, I think this should be sent back to the working group.
Given the lack of consensus among the authors, I conclude it should no longer be a w.g. draft. The authors can, of course, continue working on the draft to resolve the issues. Bob > On Oct 17, 2025, at 11:01 PM, [email protected] wrote: > > Hi, Ron and Eric, > > I have the different opinions. > > I believe that this draft should be expected to solve two issues.. > > The first issue is obvious. According to RFC4884, the Extension Structure > contains exactly one Extension Header followed by one or more objects. > Actually, there may exist more objects containd by one Extension Header, as > described in the previous versions of draft-ietf-6man-icmpv6-reflection-11. > If there is no length field in the Extension Header, it will be difficult for > the receiver to parse these objects (except for assuming one object). > > The second issue is that the Extension Structure must be appended to the end > of an ICMP message according to RFC4884, if and only if this ICMP message has > the reserved space for a length attribute representing the length of the > "original datagram" (optional data) field. However, the following ICMP > messages are not extensible as currently defined, because these messages lack > spaces for a length attribute.: > - ICMPv4 Destination Unreachable > - ICMPv4 Time Exceeded > - ICMPv4 Parameter Problem > -ICMPv4 Echo Request/Reply > - ICMPv6 Destination Unreachable > - ICMPv6 Packet Too Big > - ICMPv6 Time Exceeded > - ICMPv6 Parameter Problem > -ICMPv6 Echo Request/Reply > If a length field is added to the ICMP Extension Header, the above-mentioned > ICMP messages can be extensible by inserting an extension structure before > the original datagram or the optional data field. > > As decribed in draft-ietf-intarea-rfc8335bis-01, the main difference between > this darft and RFC8335 is that the optional data field is appended to the > Extension Structure. The length field in the Extension Header can help to > determine the offset of the optional data field even if the Extension Header > contains more objects. > > Best Regards, > Xiaoming > [email protected] > > From: 【外部账号】Ron Bonica <mailto:[email protected]> > Date: 2025-10-18 10:18 > To: Eric Vyncke (evyncke) <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > CC: [email protected] <mailto:[email protected]>; xiao.min2 > <mailto:[email protected]>; Tal Mizrahi > <mailto:[email protected]>; Gorry Fairhurst > <mailto:[email protected]>; Ketan Talaulikar <mailto:[email protected]> > Subject: Re: Status of draft-ietf-intarea-icmp-exten-hdr-len-02 > Hi Eric, > > I believe that this draft should be withdrawn. Initially, the draft had the > following goals: > > To correct an oversight in RFC 4884. > To rescue the ICMP Extended Echo Request/Reply from misuse. > > While the first goal is laudable, it isn't worth the effort. Generally > speaking, a variable length data structure should include a length attribute. > If it doesn't, its length must be inferred. While various techniques allow us > to infer length, each technique introduces its unique drawbacks. > > As Ketan points out, the second goal is not attainable. Currently, ICMP > implementations infer extension structure length by subtracting the extension > structure offset from the total length of the ICMP message. This works, so > long as the extension structure is the last item in the ICMP message. > > Some years ago, RFC 8335 implementations added information to the ICMP > Extended Echo Request/Reply messages. Rather than encoding this information > in the extension structure, they encoded it after the extension structure. > So, in the Extended Echo Request/Reply messages, we can no longer infer the > extension structure length using the old technique. We must assume that in > ICMP Extended Echo Request/Reply messages, the extension structure contains > exactly one object. So, its length can be calculated by adding the extension > header length to the length of the one and only object. > > We would not have had this problem if the Extended Echo Request/Reply had a > length attribute on day one. However, it's too late to rescue the ICMP > Extended Echo Request/Reply messages by adding one. The only way to maintain > backwards compatibility with legacy PROBE implementations is to limit the > number of objects that the extension structure can carry in the Extended Echo > Request/Reply. > > > Ron > > > > > > Juniper Business Use Only > From: Eric Vyncke (evyncke) <[email protected]> > Sent: Friday, October 17, 2025 4:48 AM > To: [email protected] <[email protected]> > Cc: Ron Bonica <[email protected]>; [email protected] > <[email protected]>; xiao.min2 <[email protected]>; Tal Mizrahi > <[email protected]>; Gorry Fairhurst <[email protected]>; Ketan > Talaulikar <[email protected]> > Subject: Status of draft-ietf-intarea-icmp-exten-hdr-len-02 > > [External Email. Be cautious of content] > > Dear authors, dear intarea WG, > > It seems that this I-D has reached a dead-end based on all email discussions > after the IESG evaluation and the blocking DISCUSS ballot by Gorry and Ketan > (in cc). > > I sincerely think that this I-D should be removed and not published anymore, > especially in the light of draft-ietf-intarea-rfc8335bis, which is in WG Last > Call. > > What do you and the intarea WG think about this removal ? > > Regards > > -éric (after discussion with the intarea WG chairs) > > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
