First, a few general comments about this thread not in reply to this
particular message:

- saying that PMTU-D is broken by design because you can setup filters
that results in TCP connections not working is silly.  You can also setup
filters to deny all SYN packets that prevent TCP connections from working;
does that mean TCP connection establishment is broken by design?  It is
arguable that it should have been a TCP option and there was debate about
that, but that is done.

- the place to deal with broken firewalls is at the endpoints, not the
routers.  Some systems already have implemented PMTU-D blackhole
discovery.  This has to be done on the machine trying to perform the
PMTU-D.

- as always, let me reiterate for people who don't understand what the
issue is or why their filters are broken: see
http://www.worldgate.com/~marcs/mtu/

On Sun, 22 Nov 1998, der Mouse wrote:

> > There is no valid reason to disable receipt of the particular ICMP
> > messages in question.  [...]  If you can name one, I'd like to hear
> > it.  Remember, I'm talking about only the messages associated with
> > Path MTU, not any other ICMP messages.
> 
> It's not a question of blocking *receipt* of those packets, but
> blocking *transmission* of them.  Remember, we have host A, trying to
> do PMTU-D, to host B.  But between A and B we have two boxen: a
> firewall F and a router R, in that order.  F lets A's packets through
> but blocks the need-frag ICMP packets from R to A.  The outgoing link
> from R in the direction of B has a small MTU.

No, it is both.  

You can have the router sending the can't fragments inside a filter at B.

Or you can have the router sending the can't fragments that get out to the
Internet fine, but don't get to A because there is a filter near A.

The first is blocking transmission, the second is blocking receipt.  That
is just taking a view of transmission and receipt as being divided down
the middle, with one network on one side transmitting and another network
receiving.

The distinction there is important because it tells you who to blame.  

There are also different reasons for filtering.

If you have the first case, there is no real reason to block the ICMP
can't fragments except to avoid revealing information about your internal
network topology if you filter things so traceroute, etc. don't work.

In the second case (which is the one that I see far more often, since many
people just block all ICMP to web servers), there is a valid reason to
block the can't fragments.  That reason is to avoid a DoS attack based on
forging can't fragment packets telling A that the MTU is very very low
(especially if the implementation don't place a reasonable minimum on the
size it will drop down to).  If you want to filter ICMP can't fragments
for that reason, no problem.  Do it.  But then you need to disable PMTU-D
on your machines that are behind the filter.