Mike,
The issue of RFC 1122/1812 compatibility was raised during WG last call.
Specifically, we considered the possibility that some existing applications
might rely upon information contained in the later bytes of the field in
question. (For the purposes of this message, let us refer to that field as
the "user data" field).
In response to this issue, the authors increased the length of the "user
data" field from 28 bytes to 128 bytes. Now we must consider the possibility
that some existing application still might be adversely effected in a
*significant* way.
As you stated, we have not identified any adversely effected applications.
Therefore, we can only speculate upon the kinds of data that applications
might glean from the ICMP user data field. Our best guess is that they would
be looking for routing and session identification information.
Therefore, if the user data field were long enough to contain all network
and transport layer headers, it would be long enough. This is in keeping
with the spirit, if not the letter, of RFC 1812.
A 128 byte length was chosen to accomodate this. It supports a few layers of
IP-in-IP tunneling with moderate use of IP options.
That said, I accept your comments regarding:
-> renaming the document
-> IANA control of Class-Num and C-Type
-> adding verbage wrt the starting displacement of the common header in
the
presence of options on the ICMP header
Ron
-----Original Message-----
From: owner-mpls(_at_)UU(_dot_)NET [mailto:owner-mpls(_at_)UU(_dot_)NET]On
Behalf Of C. M.
Heard
Sent: Monday, August 21, 2000 1:13 AM
To: IETF
Cc: IESG; MPLS
Subject: Re: Last Call: ICMP Extensions for MultiProtocol Label
Switching toProposed Standard
On Fri, 11 Aug 2000, The IESG wrote:
The IESG has received a request from the Multiprotocol Label Switching
Working Group to consider ICMP Extensions for MultiProtocol Label
Switching <draft-ietf-mpls-icmp-02.txt> as a Proposed Standard.
The IESG and the IETF community are urged to carefully evaluate
the above-referenced draft, as the ICMP extensions that it proposes
require *modification of the format* of the ICMPv4 Destination
Unreachable, Time Exceeded, Parameter Problem, Source Quench, and
Redirect messages, and the proposed modifications are not entirely
backward compatible with RFC 1122 and RFC 1812.
The details of the proposal and the rationale for it are in the draft.
Here is a quick overview. The format of ICMPv4 error messages, as
defined in RFCs 792, 1122, and 1812 is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| varies according to message type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Internet Header + at least 8 data octets from original datagram|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC 792 specifies that an ICMP error message must contain the Internet
header plus 64 bits of the original datagram's data. RFC 1122 specifies
that an ICMP error message must contain the Internet header and at least
the first 8 data octets of the datagram that triggered the error; more
than 8 octets MAY be sent; this header and data MUST be unchanged
from the received datagram. RFC 1812 specifies that an ICMP error
message SHOULD contain as much of the original datagram as possible
without the length of the ICMP datagram exceeding 576 bytes. The
returned IP header (and user data) MUST be identical to that which
was received, except that a router is not required to undo any
modifications to the IP header that are normally performed in forwarding
that were performed before the error was detected (e.g., decrementing
the TTL, or updating options).
The draft proposes to change this as follows: the first 128 bytes
following the 8-octet ICMP header will contain the original datagram's
Internet header plus as much data as will fit in 128 bytes; if the
original datagram is shorter than 128 bytes then it will be padded
with 0's. Immediately after the 128 bytes of data from the original
datagram there will be a checjsummed data structure containing TLV-encoded
objects such as an MPLS label stack or additional returned user data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| varies according to message type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Internet Header + as many data octets from original datagram as|
|will fit in 128 bytes (zero padded to 128 bytes if necessary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Data Structure |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed modification breaks the rule that the returned user data
MUST be unchanged from the received datagram.
The IESG and the IETF community are requested to carefully consider
whether breaking this rule is likely to have adverse effects on
deployed implementations. I have not been able to find any applications
that would be adversely affected, but I would like others who are more
knowledgeable to have a hard look.
Assuming that this proposal to modify ICMPv4 is accepted for
standardization, I would suggest that the title of the draft
be changed to reflect the fact that the extension data structure
is not limited to MPLS-specific extensions, but can in principle
accomodate other extensions as well. Also, the extension header
version and extension object Class-Num and C-Type fields will need
to be under IANA control, and the document should have an "IANA
Considerations" section (cf. RFC 2434).
There are also some minor technical issues that I would like to point out.
% According to RFC-792, bytes 0 through 19 of any ICMP message contain
% a header whose format is analogous to that of the IP datagram. Bytes
% 20 through 23 contain an ICMP message type, code and checksum. Bytes
% 24 through 27 contain message specific data.
I think that bytes 0 through 19 are supposed to be the Internet header
of the IP datagram containing the ICMP message. There may be more than
20 bytes if IP options are present, and the draft should mention this.
% Also according to RFC-792, the final field contained by each of the
% ICMP message types listed above begins at byte 28. It reflects the
% IP header and leading 64 bits of the original datagram. [RFC-1812]
% recommends that this final field be extended to include as much of
% the original datagram as possible.
The final field is at offset 28 from the start of the IP datagram
only in the absence if IP options.
[ ... ]
% When an LSR appends the data structure defined herein to an ICMP
% message, the ICMP "total length" MUST be equal to the data structure
% length plus 156. The first octet of the data structure must be
% displaced 156 octets from the beginning of the ICMP message.
The number 156 is accurate only in the absence of IP options.
Cordially,
C. M. Heard
heard(_at_)vvnet(_dot_)com