-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, all,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or forward
this review.
The primary purpose of the document is to extend supplemental
information carried in ICMP responses to support diagnostics, notably by
supporting interface naming information. The document describes one use
of extended ICMP (RFC4884), which was developed for this purpose as well
as to support MPLS diagnostics.
This document would extend the information available to transport
protocols, notably for destination unreachable, time exceeded, and
parameter problem ICMP messages. This document does describe a use of
extended ICMPs that, if deployed widely, would provide additional
information to transport protocols which could be useful diagnostically,
but is not expected to impact the operation of these transport protocols.
Issues of backward compatibility of legacy transports with extended
ICMPs are discussed in Section 5.1 of RFC4884, and is not affected by
the particular extension described in this document. This document does
describe a use of extended ICMPs that would be expected to be seen by
legacy transport protocols, however.
For stateful transports, such as TCP, SCTP, and DCCP, the extended ICMP
described by this document could provide useful diagnostic information,
but should not affect protocol operation. UDP is not directly affected
by this extension, but is anticipated to pass the extended information
up to the application; revised traceroute applications would provide
this information, if available (i.e., on stacks that support it), to the
user.
Note that there are potential issues of interaction of extended ICMP
(RFC4884) with legacy transports, and which affect whether more than 128
bytes of header are available in the ICMP response, as well as whether
full-packet inspection (e.g., checksum verification or other
authentication) can even be performed. This further advocates for
conservative approaches in parsing ICMP responses, especially requiring
that new implementations support RFC4884 extensions and do not
anticipate a full packet in the ICMP payload. This document does not
alter that effect, but, as noted above, would be the first use of
extended ICMP expected to widely interact with transport protocols.
There is no need to modify this document to address these issues; the
are sufficiently addressed in RFC4884.
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknaVlkACgkQE5f5cImnZrultgCg6qfzz3FvMk+lAlKQMaURGoqS
h6EAni49Df5WeeT4VNsgcxT6HftjuPho
=faI/
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf