The MPLS WG Archive

[Ron Bonica <rbonica@mci.net>]

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@UU.NET [mailto:owner-mpls@UU.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@vvnet.com
>
>
>