number of octets returned in ICMP error messages

Steve Deering <deering@pescadero.stanford.edu> Wed, 29 August 1990 01:29 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA03902; Tue, 28 Aug 90 18:29:13 PDT
Received: by decwrl.dec.com; id AA10919; Tue, 28 Aug 90 18:27:58 -0700
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA15231; Tue, 28 Aug 90 18:27:02 PDT
Date: 28 Aug 1990 17:20-PDT
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: number of octets returned in ICMP error messages
To: ietf-rreq@jessica.stanford.edu
Cc: mtudwg
Message-Id: <90/08/28 1720.860@pescadero.stanford.edu>

Last week, Robert Elz posted a message to ietf-rreq concerning the
generation of ICMP error messages, in which he wrote:

>	...
>	This also takes account of another comment from the [Vancouver
>	Router Requirements] meeting.  (Not sending "too many" data bytes
>	back).
>	...
>	Every ICMP error message includes 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, though it is
>	suggested that this number be limited to a reasonable quantity
>	to avoid potential problems (fragmentation, possible datagram
>	too large for recipient, etc) that may otherwise occur.

I'd like to suggest that 8 data octets is "too few", and that we should
recommend (rather than simply allow) more octets than 8.  The reason for
this suggestion is to allow better ICMP support across "tunnels", that is,
paths over which IP datagrams are sent encapsulated inside other IP
datagrams.  Tunneling is being used for various purposes these days,
and I suspect that it will become more and more common in the future.
(For example, the ORWG policy-based routing scheme uses tunnels between
policy routers.)  One particular ICMP service that would work much
better over tunnels if more of the offending datagram were included is
the proposed ICMP MTU discovery strategy.  (As it is, if a datagram is
too large for a hop within a tunnel, the ICMP message returned to the
tunnel entrance does not contain enough information to fabricate an
appropriate ICMP message for the original source.)

A reasonable value, instead of 8, would be somewhere between 68 (enough
for another maximum-size IP header plus 8 data octets) and the number of
octets that will fit without exceeding 576 for the entire ICMP message.

What do y'all think?

Steve