At 17:31 27/09/2006, Joe Touch wrote:
> 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)
Good. This is what I said I was missing.
> 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.
Unless you have assessed every existing implementation (which is very
unlikely), the statement "No such implementations have been
identified" doesn't mean much.
Again, this is not at all a killer for the document. I just mean that
some text should be included both on this and on the possibility of
overwriting some fields that may lead to unexpected results.
> 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.
There may be more than one instance of tunelling. In some scenarios
it may be possible to unroll the interior headers - one per tunnel endpoint.
Also, by overwriting the 129th byte, you may overwrite the TCP ACK.
And there are firewall implementations (OpenBSD's PF, at least) which
check the ACK field when it's available.
If they were, then RFC1122 would require MUST rather than
SHOULD for as many payload bytes as possible.
RFC1222 was written, as all other specs, by humans.
Also, I don't think tunnels were as common in 1989 as they are nowadays.
Last, but not least, enforcing a such a MUST for ICMP would not make
much sense. If you really mean a MUST, you wouldn't be using
non-reliable signalling, after all.
> 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.
Agreed.
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
