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?
>
>>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
>
> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
