Hello all,
I'm sending my feedback on draft-bonica-internet-icmp-08.
My main concern with this document is that of backwards
compatibility. However, there are is also a misreading of the IP spec
(wrt IPv4 minimum MTU) which makes it impossible for an
implementation to comply with a requirement stated in this doc as a "MUST".
Here's my feedback:
Page 4, Section 2: Protocol
" designers can make an ICMP message carry additional information by
encoding that information in an extension."
Maybe s/extension/extension object/ ?
Page 4, Section 2:
" This document also addresses a fundamental problem in ICMP
extensibility. Many of the ICMP messages addressed by this memo
include an "original datagram" field. The "original datagram" field
contains the initial octets of the datagram to which the ICMP message
is a response. Although the "original datagram" field is of variable
length, the ICMP message does not include a field that specifies its
length."
I'm not sure I see the "fundamental problem". When it comes to
"extensibility", you can always define a new ICMP type/code.
Page 7, section 4:
" The length attribute represents the length of the "original datagram"
field, measured in 32-bit words. When the length attribute is
specified, the "original datagram" field MUST be zero padded to the
nearest 32-bit boundary. Space for the length attribute is claimed
from reserved octets, whose value was previously required to be zero."
In the case of ICMPv6, this new length field will not accommodate
those cases in which as much information from the original payload is
being including without exceeding IPv6's minimum MTU (i.e., a
one-byte length field is not enough).
Page 10, Section 4.6:
" The ICMP Extension Structure MAY NOT be appended to any of the other
ICMP messages mentioned in Section 4."
Did you mean "MUST NOT"?
Page 12, Section 5.1:
" When a classic application receives an ICMP message that includes
extensions, it will incorrectly interpret those extensions as being
part of the "original datagram" field. Fortunately, the extensions
are guaranteed to begin at least 128 octets beyond the beginning of
the "original datagram" field. So, only those ICMP applications that
process the 129th octet of the "original datagram" field will be
adversely effected. To date, no such applications have been
identified."
I think this assumption is wrong. Some implementations may be
checking the TCP checksum included in the TCP header of the original
datagram. In those cases, these extensions will likely lead to an
error, with the ICMP message being discarded.
Also, if some kind of tunnelling mechanism was in place when the
error was elicited, important information such as TCP's port numbers
may be at (or past) the 129th octet. This may lead to the ICMP error
messagebeing demultiplexed, for example, to the wrong TCP endpoint.
Thus, guaranteeing that the extensions are "at least 128 octets
beyond the original datagram" may not be enough.
Page 13, section 5.3:
Provided that the entire ICMP messages does not exceed the minimum
MTU (576 octets for ICMPv4 or 1280 octets for ICMPv6), there is no
upper limit upon the length of the "original datagram" field.
This is incorrect. IPv4's minimum MTU is 68 octects, not 576 (576 is
the minimum reassembly buffer size). In the case of ICMPv4 The limit
is imposed by the reassembly buffer size, not by the MTU.
Page 13, Section 5.3:
" However, each vendor will decide how many octets to include. Those
wishing to be backward compatible with non-compliant TRACEROUTE
implementations will include exactly 128 octets. Those not requiring
compatibility with non-compliant TRACEROUTE applications may include
more octets."
This is not compliant with RFC 1122 itself. I think this modifies a
"SHOULD" in RFC 1812. (RFC 1812 states that as much information from
the original datagram SHOULD be included, without exceeding....?)
Page 14, Section 6:
" As stated above, the total length of the ICMP message, including
extensions, MUST NOT exceed the minimum protocol MTU. Figure 6
depicts the ICMP Extension Header."
As explained above, this requirement cannot be met: IPv4's minimum
MTU is 68 bytes. You may change this as explained above (s/minimum
MTU/minimum reassembly buffer size/), though.
Page 15, Section 6:
Version: 4 bits
ICMP extension version number. This is version 2.
Version 1 is that used by the non-compliant implementations?
Page 15, Section 6:
" Checksum: 16 bits
The one's complement of the one's complement sum of the data
structure, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value means that
no checksum was transmitted."
You should probably clarify the reason of this checksum, as there
already is a checksum field in ICMP messages.
Kindest regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
