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 > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
