I don't want to drag this unneccisarily long but RFC 792 also states that Echo is (type 0, code 0) and (type 8, code 0) whereas we propose (type 0, some code != 0) and (type 8, some code != 0). Just to be clear, we do not change the semantics of standard Echo _definded by the type/code combinations_ in RFC 792.

I think the group gets where we two are standing on this issue, I would be interested in the opinion of others on this issue, and not to forget the second issue I posted.

Best,

Rolf

Am 07.11.24 um 15:59 schrieb Ron Bonica:
Rolf,

Your draft contradicts RFCs 792, 4443, and RFC 4884.

  *
    RFC 792 and 4443 both say that the code field in both the echo and
    echo reply must equal 0.
  *
    RFC 792 says that "The data received in the echo message must be
    returned in the echo reply message"
  *
    RFC 4443 is more specific, saying that "The data received in the
    ICMPv6 Echo Request message MUST be returned  entirely and
    unmodified in the ICMPv6 Echo Reply message.
  *
    And finally, Section 4 of RFC 4884 enumerates which ICMP messages
    can be extended and which cannot.

Your draft will have to update all of those. Let's chat after you have written the relevant sections of your draft. I wonder if changing the semantic of the data field in the echo and echo reply message will upset some stateful firewalls?

       Ron



 > The IANA considerations section contains our code point allocations and
 > sections 3 and following contains their use. It should be pretty clear
 >from that. What information are you missing in particular?
 >
 >Rolf


Juniper Business Use Only


_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur

_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org

Reply via email to