OK. I'm convinced.
I will update the draft and resubmit it in a few hours.
-ron
Jari Arkko wrote:
> 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
