Subject: RE: Last call for draft-ietf-mpls-icmp-00.txt

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 16 Nov 1999 13:35:53 -0800 (PST)

Ron Bonica wrote:
>
> To date, I have not found any applications that rely upon the extra user
> data provided by RFC 1812 style ICMP messages. This, however, doesn't prove
> much of anything. I may have looked in the wrong places.

Neither have I, although I just posted a message to the tcp-impl list
asking if any such applications exist.

> Therefore, I suggest the following course of action:
>
> Wait a reasonable period of time (2 weeks?).
>
> If nobody finds any applications that rely upon the extra user data provided
> by RFC 1812 style ICMP messages (beyond displaying it), issue a new version
> of draft-ietf-mpls-icmp with some verbage that stating that
> draft-ietf-mpls-icmp supersedes of RFC 1812 wrt this issue.
>
> If somebody finds an application that relies upon the extra user data in RFC
> 1812 style ICMP messages (beyond displaying it), issue a new version of
> draft-ietf-mpls-icmp. The new draft will include some verbage stating that
> when a router emits an ICMP message with extensions, it must include a 64
> byte user data field. The 64 byte user data field contains the first 64
> bytes of the original IP datagram and is likely to contain all IP and
> transport layer headers. Extensions will follow the user data.
>
> Is this agreeable to you?

Instead of forever fixing the amount of returned user data allow me to
suggest an alternative:  replace the common header and object headers
with a common trailer and object trailers.  The common trailer would
appear at the _end_ of the ICMP packet, and the first object trailer
would immediately precede it.  Under this proposal extended Destination
Unreachable, Parameter Problem, Source Quench, and Time Exceeded mesages
would look something like this:

        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             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Pointer/unused |             unused                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Header + 8 or more bytes of payload from original datagram |
       //              ^^^^^^^                                         //
  +--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    //                                                              //
  |    |           (Object Contents, e.g., MPLS label stack)           |
  |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +--- |             Length            |   Class-Num   |     C-type    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Vers |     (Reserved)        |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format would allow a router to return as much of the original user
data as it wishes, subject to the 576-byte limitation on the total length
of the IP datagram containing the ICMP error message.  You might want to
require that the returned user data be chopped on an 8 byte boundary;  in
that case one would need to suppress the extention trailer or else pad the
returned user data if the original datagram contained less than 8 bytes of
user data.

As for how much user data a router SHOULD return (and whether to suppress
the trailer or pad the user data in case of a short datagram), that depends
on what turns up regarding applications which use the extra data.  A two
week wait is enough time for me.

One other point:  regardless of how these issues are resolved, if the
draft goes forward it not only must explicitly state that it suspersedes
RFC 1812 but also must include some words stating why it is not expected
to harm existing applications.  This need not be much -- if (as appears
likely) we are not able to find any applications that make use of returned
user daya beyond the first 8 bytes then one a sentence say just that would
be sufficient.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 23 Nov 1999 14:04:47 -0500

> From: Ron Bonica <[email-masked]>

    >> If the objective is to return enough user data to accomodate one level
    >> IPv4-in-IPv4 tunnelling then the fixed size area should be at least 68
    >> bytes long. That would accomodate a maximum-size IPv4 header plus the
    >> first 8 bytes of the transport header.

    > Given that a) it is better to send too much user data than too little,
    > and b) we prefer field lengths that are even powers of 2, the right
    > field length is probably 128 bytes.

Errr, powers of two are nice - but when you start getting into bigger numbers
(so the jumps get bigger), and you're talking about packet lengths (as opposed
to the size of a number a field can hold), they are less critical. (E.g. the
576 byte "minimum-maximum IP packet size" number.)

In this case, though, I don't think it's too critical - we won't be sending
around a lot of these packets, and a couple of dozen extra bytes of data is
not a big deal.

	Noel