Hi, I wanted to bring your attention to draft-fenner-intarea-probe-clarification, which is intended as an update to RFC8335 based on a survey of existing implementations and comparing them with the spec. I'm including the "what's changed since RFC8335" section below.
https://datatracker.ietf.org/doc/html/draft-fenner-intarea-probe-clarification-00 7. Changes from RFC 8335 This document updates [RFC8335] to clarify the handling of extra data beyond the ICMP Extension Structure, that data is echoed in the response packet, and checksum handling in the ICMP Extension Structure. Specifically, * Updated Figure 1 to reflect the presence of the ICMP Extension Object and additional data. * Updated Section 2 to mention the ICMP Extension Structure checksum, and extra verbosity about how the Extension Structure does not cover the rest of the packet. * Updated Figure 3 to reflect the presence of the ICMP Extension Structure and additional data. * Added a step in Section 4 about copying data from the request to the response. * Added a step in Section 4.1 about validating the ICMP Extension Structure checksum. * Added section Appendix A.1 to suggest human-readable display of PROBE responses * Clarified in Section 2.1 that the length of an ifName Object is adjusted when padding is added. These changes are intended to make it easier for a new implementor to create an implementation compatible with those that are already deployed, at the same time as keeping the document compatible with those implementations. As the changelog mentions, Appendix A.1 suggests "human-readable" display of PROBE responses. This is of course non-normative, but I included it based on some feedback from an operator about using an existing client. I'm including it here in the hopes of getting some feedback. A.1. Information Display For the PING application, the primary available piece of information is the fact that we received an ICMP Echo Reply. Therefore, the appropriate information to display is all of the available information about the received reply, e.g., size, ttl, etc. However, with PROBE, the primary piece of information is the reported status of the probed interface: the code, status, A, 4, and 6 fields. It's appropriate to convert the combination of the returned values into a "human-readable" response. For example, an application may perform these steps: * If the code field is non-zero, print the code value as described in Section 3. * If the code field is zero, then if the L field sent is zero, print the state value as described in Section 3. * Otherwise, the L field sent is 1; print the state represented by the A, 4, and 6 bits. Sample textual translations for these bits are shown in Table 1. +===+===+===+================================================+ | A | 4 | 6 | Text | +===+===+===+================================================+ | 0 | 0 | 0 | Interface inactive | +---+---+---+------------------------------------------------+ | 1 | 0 | 0 | Interface active, with no ipv4 or ipv6 running | +---+---+---+------------------------------------------------+ | 1 | 0 | 1 | Interface active, with ipv6 running | +---+---+---+------------------------------------------------+ | 1 | 1 | 0 | Interface active, with ipv4 running | +---+---+---+------------------------------------------------+ | 1 | 1 | 1 | Interface active, with ipv4 and ipv6 running | +---+---+---+------------------------------------------------+ Table 1: Sample translations for bit settings Any feedback is appreciated! Bill
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
