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.
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
The only exceptions might be Destination Unreachable and Time
Exceeded, where the Unused field could possibly be used to encode
something useful, like where the IP layer data ends and lower layer
data begins.
Personally, and without thinking too much, adding a new Informational
message type to convey lower layer related informational error data
appears like one possible way to go forward.
Yes, if we want to extend ICMP, we'll definitely need to figure out
how (and how to deal with ICMPv6 as well). The current proposal of
arbitrarily limiting the size of the message seems a bit
questionable to me though.
Here I completely agree with the other Pekka.
--Pekka Nikander
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
