Date:        Mon, 23 Nov 1998 02:08:42 -0500 (EST)
    From:        woods@most.weird.com (Greg A. Woods)
    Message-ID:  <m0zhq70-0009M2C@most.weird.com>

It is hard to believe that this discussion is still taking place.

  | I think it should be trivial for a router to recognize this situation by
  | keeping a short circular queue of records containing information about
  | hosts which were sent an ICMP "needs frag" bit and when a "enough" ICMP
  | replies have been sent to a listed host, and that host is still sending
  | packets too big then this record would be moved to a second fixed length
  | table.

Then do it, that part of your suggestion is OK, no-one is going to care
if your particular NetBSD based router runs like a dog and consumes Mb's of
state.

  | Any large packets with the DF bit set which arrive from a host
  | listed in the second table should have their DF bit turned off and the
  | packet will then be fragmented and forwarded as necessary.

But that is breaking IP in a very fundamental way (as you have been told
before), and would be a truly horrid thing to do.

Nb: IP, not PMTUD - packets with DF set are a part of the basic IP protocol,
and while the most common reason that you will see them today is for PMTUD,
it isn't the only reason.   For all you know the packets with DF set that
you're blindly suggesting fragmenting might have some other reason for not
being fragmented.

If you really want to find a "solution" for this, configure yourself a tunnel
across the link(s) with the low MTU, and send the DF packets you would 
otherwise fragment across the tunnel (the tunnelled packets can themselves be
fragmented, they'll be reassembled at the remote end of the tunnel, before
being decapsulated and forwarded further).

Just don't ever let me see the code that does all this nonsense.

kre