Re: number of octets returned in ICMP error messages

[mogul (Jeffrey Mogul)]

    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.)

I would think that the tunnel entrance would be most interested in
the Path MTU between it and the tunnel exit, which should be available
even in current ICMP messages.  This Path MTU would then become the
"Link MTU" for the tunnel, and the tunnel entrance would then use
this value to provide PMTU discovery services back to the original
source.  Having the original datagram header available would help
avoid a few dropped datagrams right after a decrease in the (tunnel)
Path MTU, but it doesn't seem essential to the PMTU discovery process.

In other words: you're probably right, but it wouldn't be a disaster for
PMTU discovery.
    
    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.
    
As Robert Elz mentioned

    >	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 would argue against "576" because it seems likely that this could
cause problems precisely when one is depending on PMTU discovery;
e.g., on a path that involves an MTU smaller than 576.  Is there
any reason to make it much more than 68?  Do you expect people
to use multiple levels of tunnelling (without being certifiably
insane at the time?)

-Jeff