Hi，Bob,
We have a consensus about defining the length field in the Extension Header
among the authors.
We believe that this draft can help address the issues mentioned in
previous eamil.
I also believe that this draft is ready for publication.
Best Regards,
Xiaoming
原始邮件
发件人：Bob Hinden <[email protected]>
发件时间：2025年10月18日 23:25
收件人：[email protected] <[email protected]>
抄送：【外部账号】 <[email protected]>, Gorry Fairhurst <[email protected]>,
Ketan Talaulikar <[email protected]>, hexm4 <[email protected]>
主题：[Int-area] Re: Status of draft-ietf-intarea-icmp-exten-hdr-len-02
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 WWW 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
Date: 2025-10-18 10:18
To: Eric Vyncke (evyncke); [email protected]
CC: [email protected]; xiao.min2; Tal Mizrahi; Gorry Fairhurst; Ketan
Talaulikar
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]
