Pekka,
Thanks for these comments. Response below:
Pekka Nikander wrote:
Some half baked thoughts:
The first is a syntactic question. That is, "Do we want to define a
syntax that allows us to extend ICMP messages?" This syntax must
allow us to extend any ICMP message, including those that currently
end in a variable length field that lacks a length attribute.
In principle, we already have such a mechanism: introducing new message
Types with new message contents. That may even work in practise for
ICMPv6 due to most implementations still being fairly new and
flexible. On the other hand, it may be quite hard for many IPv4
environments.
I considered this and decided that it was impractical for IPv4. In order
to be backwards compatible, an LSR would have to emit two ICMP messages
for each undeliverable datagram. One old-style and one new-style.
The second question is architectural. In the future, do we want to
extend ICMP so that it will contain information that might be useful
for debugging, even if that information is not strictly IP
information (i.e., even if it constitutes a small layer violation).
As long as those messages would be informational, I don't see much
problems.
Including such data in error messages appears more problematic to me:
- new error messages may not be a good idea since the upper layer may
not know how to handle it
- error messages are expected to include as much of the IP packet as
possible, as per Section 2.4.c of
RFC2463 and Section 4.3.2.3 of RFC 1812.
- adding new data to existing error messages is problematic due to the
current syntax
Most legacy ICMP implementations send only the IP header plus the first
eight octets of the original datagram. I am only aware of one vendor who
sends more.
Because most implementations send only 28 octets, I think that it is
unlikely that any legacy applications rely on the integrity of anything
beyond the 128th octet. (The current proposal requires that the first
128 octets are send in tact.)
Your point is well-taken and we did consider it at first. However, these
extentions have been widely deployed for several years and I am not
aware of any legacy applications having broken.
Ron
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
