[Int-area] 回复：Re: Status of draft-ietf-intarea-icmp-exten-hdr-len-02

[Xiaoming He <[e-mail]>]

Hi, Ron,


I think the another main motivation for defining the length field in the Extension Header of this draft is to address the issues of these ICMP messages not extensible. Especially for ICMP Echo Request/Reply, it may need to be extended in many scenarios.


Because the standard ICMP messages (including ICMP Echo Request/Reply ) end with the original datagram (optional data) field, it is also preferable for the extended ICMP messages to maintain the same format by inserting the Extension Structure in front of the data field.


Best Regards,
Xiaoming


         原始邮件
         
       
发件人：Ron Bonica <rbonica=[e-mail]&gt;
发件时间：2025年10月23日 05:54
收件人：[e-mail] <[e-mail]&gt;, Eric Vyncke (evyncke) <[e-mail]&gt;, [e-mail] <[e-mail]&gt;
抄送：【外部账号】 <[e-mail]&gt;, Gorry Fairhurst <[e-mail]&gt;, Ketan Talaulikar <[e-mail]&gt;
主题：[Int-area] Re: Status of draft-ietf-intarea-icmp-exten-hdr-len-02



 Xioming,

 
 I have no problem with sending the document back to the WG.

 
 Your first point is correct. If the Extension Header had a length attribute, we could add things to the ICMP message after&nbsp;the Extension Structure. However, some on the IESG have asked why you would ever want to add anything after the Extension Structure. Alternatively, you could encode additional information in a new Extension Object and put the new Extension Object inside&nbsp;the Extension Structure.&nbsp;

 
 I don't have any strong opinions on this matter. But if the WG wants to progress the draft on this point alone, won't object.

 
 I'm not sure that I agree regarding your second point, because it requires the Extension Structure to precede the original data field. Switching the position of these two fields was never discussed in draft-ietf-intarea-icmp-exten-hdr-len. Moreover, it would  cause backward compatibility problems that could propagate to the transport layer.

 
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Ron

 

 

 

 

 

 

 


 
 Juniper Business Use Only

From:&nbsp;[e-mail] <[e-mail]&gt;
 Sent:&nbsp;Saturday, October 18, 2025 2:01 AM
 To:&nbsp;Ron Bonica <[e-mail]&gt;; Eric Vyncke (evyncke) <[e-mail]&gt;; [e-mail] <[e-mail]&gt;
 Cc:&nbsp;【外部账号】 <[e-mail]&gt;; Tal Mizrahi <[e-mail]&gt;; Gorry Fairhurst <[e-mail]&gt;; Ketan Talaulikar <[e-mail]&gt;
 Subject:&nbsp;Re: Re: Status of draft-ietf-intarea-icmp-exten-hdr-len-02 
&nbsp;

[External Email. Be cautious of content]

 
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.&nbsp; 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.:
&nbsp; &nbsp; &nbsp; - ICMPv4 Destination Unreachable
&nbsp; &nbsp; &nbsp; - ICMPv4 Time Exceeded
&nbsp; &nbsp; &nbsp; - ICMPv4 Parameter Problem
&nbsp; &nbsp; &nbsp; &nbsp;-ICMPv4 Echo Request/Reply
&nbsp; &nbsp; &nbsp; - ICMPv6 Destination Unreachable
&nbsp; &nbsp; &nbsp; - ICMPv6 Packet Too Big
&nbsp; &nbsp; &nbsp; - ICMPv6 Time Exceeded
&nbsp; &nbsp; &nbsp; - ICMPv6 Parameter Problem
&nbsp; &nbsp; &nbsp; &nbsp;-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&nbsp;the Extension Header contains more objects.

 
Best Regards,
Xiaoming

[e-mail]

&nbsp;
From:&nbsp;【外部账号】Ron Bonica
Date:&nbsp;2025-10-18&nbsp;10:18
To:&nbsp;Eric Vyncke (evyncke);  [e-mail]
CC:&nbsp;[e-mail]; xiao.min2;  Tal Mizrahi; Gorry Fairhurst;  Ketan Talaulikar
Subject:&nbsp;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.&nbsp;


To rescue the ICMP Extended Echo Request/Reply&nbsp;from misuse.&nbsp;


 
 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&nbsp;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&nbsp;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.

 
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Ron

 

 

 

 


 
 Juniper Business Use Only

From:&nbsp;Eric Vyncke (evyncke) <[e-mail]&gt;
 Sent:&nbsp;Friday, October 17, 2025 4:48 AM
 To:&nbsp;[e-mail] <[e-mail]&gt;
 Cc:&nbsp;Ron Bonica <[e-mail]&gt;; [e-mail] <[e-mail]&gt;; xiao.min2 <[e-mail]&gt;; Tal Mizrahi <[e-mail]&gt;; Gorry Fairhurst <[e-mail]&gt;; Ketan Talaulikar <[e-mail]&gt;
 Subject:&nbsp;Status of draft-ietf-intarea-icmp-exten-hdr-len-02  
&nbsp;

[External Email. Be cautious of content]

 

Dear authors, dear intarea WG,

&nbsp;

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).

&nbsp;

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.

&nbsp;

What do you and the intarea WG think about this removal ?

&nbsp;

Regards

&nbsp;

-éric (after discussion with the intarea WG chairs)

&nbsp;