Ron Bonica wrote: >>> - An ICMP Extension Structure MAY be appended to any ICMP message >>> except for those excluded below. >>> >>> >>Given the nature the extensions we can do at this stage, >>and the goals of this draft, I think it would be much better >>if the draft explicitly restricted itself to a known subset of ICMP >>messages (as opposed to "any"). >> >> >> >... > >Why would we want to restrict the applicability of the extension >structure more than we need to? I agree that it makes no sense to ever >extend some ICMP messages (e.g., Source Quench). But if someone, >someday, finds that he needs to add information to the Parameter Problem >message, why should he not use the extension structure defined in this >draft? > > I do not worry about the extension to Destination Unreachable, Parameter Problem, Source Quench, or Time Exceeded messages.
My issue was the statement in the draft that indicated you can use this extension mechanism on any ICMP message except those explicitly listed. As you note in the draft, the extension mechanism is unsuitable for some types of messages. For instance, Echo Request/Reply cannot be extended due to lack of a suitable reserved field, and RFC 4065 messages already have their own option structure. The current IANA registry lists ~ 40 ICMP Type values -- and there could be more in the future. We should not say anything about existing messages without analysis of the suitability of this mechanism for them, and obviously its hard to say what future ICMP messages might look like. And if it turns out that people are going to do this this also for IPv6, it has many ICMP messages where this style of extension would be inappropriate since another option mechanism already exists. I would suggest that we limit this draft to extend the messages that we know can and should be extended. This may be the four messages that you already cover in Section 4. Or if you can see some other message that need this, lets list them too, explicitly. >Agreed. I will replace the last two paragraphs of section 5.5 with the >following: > >To ease transition yet encourage compliant implementation, compliant >TRACETOUE implementations MAY include a non-default operation mode >to also interpret non-compliant responses. Specifically, when a >TRACEROUTE application operating in non-compliant mode receives an ICMP >message that contains 144 octets or more in its payload and does not >specify a length attribute, it will parse for a valid extension header >beginning at octet 137. If the application detects a valid version and >checksum, it will treat the following octets as an extension structure. > > This text looks good to me. --Jari _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
