I'm seeing a problem with path MTU discovery when a NetBSD router is in
the path.  I can't easily check to see if it's been fixed, but given
how much I seem to push the envelope, I suspect nobody else has even
noticed.

It seems that packets can be refused for forwarding based on a route's
MTU, but the returned UNREACH_NEEDFRAG ICMP error takes its MTU from
the interface's MTU.  If the route's MTU is smaller than the
interface's, this leads to an MTU-D black hole: it keeps returning
unreachables indicating an MTU that in fact won't work.  (I discovered
this on a system where the outgoing interface MTU is 1300 but the route
MTU is 1024.  traceroute -P is smart enough to notice that the returned
UNREACH_NEEDFRAG packets are reporting broken values; the kernel on the
sending host isn't.)

I noticed this with ip_icmp.c 1.41; it appears that ip_icmp.c 1.60 (the
most recent I have at ready hand) has similar trouble - icmp_error
takes an interface pointer, not a route pointer or an MTU value.

Since the destination interface pointer to icmp_error is used solely
for finding MTU values for use in NEEDFRAG unreachables, I intend to
try changing it to take an MTU value there instead; if this fixes
things, I'll send-pr it.  I mention it here in case the assembled
wisdom has something to suggest on the matter.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B