Re: [Int-area] Re: AD evaluation of draft-bonica-internet-icmp

[Joe Touch <[e-mail]>]

Ron Bonica wrote:
> 
> Jari Arkko wrote:
>> Ron, all,
>>
>> I have reviewed this specification. I have a few technical issues
>> and one question to the community about IPv6 support in this
>> space.
>>
>> Technical issues:
>>
>>
>>>      - 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").
>>
> 
> Jari,
> 
> In the interest of getting the draft published, I am willing to make
> this change, but before doing so, I would like to push back a little bit.
> 
> 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?

FWIW, it might be cleaner to state the specific current subset, and
state 'and future messages'; that avoids any ambiguity.

>>> 5.  Backwards Compatibility
>>
>> I have some unease about this section, mainly due
>> to the central role that the interoperability with
>> the currently deployed extension scheme that is
>> not compatible with what this spec says. It is
>> indeed important that we document how to
>> stay interoperable to the old extension scheme.
>> However, Section 5.5 almost recommends
>> making a non-compliant implementation due to
>> the backwards compatibility reasons. I would
>> suggest requiring compliant behaviour and
>> then allowing backwards compatibility mode
>> to be enabled through configuration or traceroute
>> option. Perhaps also some editorial changes.
> 
> 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.
> 
>                                           Ron

The doc ought to state that if the checksum fails, the implementation
MUST NOT interpret the message as containing an extension - again, for
clarity.

Joe


> 
>> This issue was also raised by the two reviewers
>> that I asked to look at this spec (Joe Touch and
>> Pekka Savola; thanks for your reviews! The detais
>> have been forwarded to Ron.).
>>
>> The question:
>>
>> In the discussion on the int-area list it was brought up that
>> that we need to "accept reality" in the IPv4 world but for IPv6
>> we should design something better. Now, as it turns out, one
>> of reasons for doing this, MPLS traceroute, *has* already
>> been implemented for IPv6, by at least one large vendor.
>> I'd like to get input from this list whether this fact changes
>> any of the conclusions we've had on this topic so far.
>> Including, for instance, that the draft should be silent on
>> IPv6.
>>
>> --Jari
>>
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area