Some notes below... Fernando Gont wrote: > 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.
There are two issues: - supporting sending the MPLS header in addition to the IP packet (this is the primary motivation) - supporting sending other information with an IP packet, e.g., the name/ID of the interface on which the error occurred in a router (the latter was indraft-atlas-icmp-unnumbered-01.txt) ... > 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. Agreed, but the statement in the doc says that no such implementations have been identified. Althought they could check the TCP cheksum, they currently don't. > 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. ICMPs in tunnels are meaningful per se only to the tunnel endpoint, i.e., to the source of the tunnel. That endpoint MAY generate a subsequent ICMP back to the source or might not (as per Sec 4 of RFC2003), but full unrolling of all interior headers is not presumed to be possible (see Sec 5 for a solution involving soft-state, albeit cumbersome. If they were, then RFC1122 would require MUST rather than SHOULD for as many payload bytes as possible. > 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....?) It's consistent with a SHOULD to provide a specific case where the SHOULD is not applicable, especially where the case is atypical. Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
