Subject: Re: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some hosts
To: NetBSD Networking Technical Discussion List <>
From: Kevin M. Lahey <>
List: tech-net
Date: 11/22/1998 12:17:21
In message <>Greg A. Woods writes
>[ On Sun, November 22, 1998 at 11:09:57 (-0800), Marc Slemko wrote: ]
>> - 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.
>It seems that may also be possible to work around failing PMTU-D to a
>certain extent on the receiving end too, at least for the case where it
>can be assumed the application will re-try the connection at some
>reasonably close point in the future.  Hmmm...  maybe not:

I think that we definitely need black hole detection in the NetBSD
PMTU implementation;  I wrote the original implementation and have
been meaning to add the black hole detection stuff for some time.

While testing various implementations about six months ago, I found
that there was *one* OS with working BHD:  Windows NT.  Shudder.
I've since been informed that AIX probably has it, too.  I've heard
that Linux has it in their development branch, but I've yet to test it.
AFAIK, though, there is no documented, blessed explanation of how
to do BHD.  Perhaps we can get something out of the tcp-impl group?

>I think I've also shown to some degree that it can also be dealt with in
>the router that's sending the ICMP "needs frag" packets, if only by
>following MCR's suggestion.  If the receiving end can't do black-hole
>detection then indeed routers *should* try to do something about it (at
>least until black-hole detection is a mandatory part of PMTU-D on the
>hosts that use it.

Ouch.  I think that we oughta expect PMTUD implementations to
do BHD.  It is just as efficient (if not more) to do the work
at the end-host, and avoids requiring routers to hold more
state information...