Subject: Re: TCP_NODELAY and full links (was Re: sup problems?)
To: firstname.lastname@example.org, Sean Doran <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/28/1999 17:39:00
In message <199909290028.RAA27609@lestat.nas.nasa.gov>,
Jason Thorpe writes:
>On Wed, 29 Sep 1999 02:22:18 +0200
> Feico Dillema <firstname.lastname@example.org> wrote:
> > Just a question: why is Path MTU discovery switched off by
> > default in NetBSD. Is there a reason not to enable it
> > by default with:
> > sysctl -w net.inet.ip.mtudisc=1
> > Just curious,
>NetBSD does not yet detect ICMP Black Holes. These Black Holes occur
>when network administrators are allowed to configure firewalls without
>ICMP is required for Path MTU Discovery to work properly (it relies on
>the Needs-Fragmentation ICMP message). If you have a Black Hole, your
>packets will never reach the other endpoint.
Yep. The technical discussion is accurate. But misconfigured
(or overly secure) firewalls are a fact of life: appealing to IETF
recommendations or "adult supervision" isnt going to fix that in a
And people trying to install NetBSD behind such firewalls are not
usually empowered to fix or alter the firewall configuration.
Until reality catches up with how we'd all like things to be, the
most reliable configuration is to ship installation kernels with
path-MTU discovery disabled.
It's a classic example of "be liberal in what you accept, conservative
in what you send". Freebsd does the same thing, for much the same
reasons (or did, a couple of years ago) and when netbsd-current turned
on path-MTU discovery by default, that caused problems for a few users.