> *Something* needs to be done since it's clear that there will be
> ongoing problems with broken PMTUD.  Either the protocol needs fixing
> (and I admit I've not yet read the RFCs to see if the problem is
> actually in the protocol, or just in NetBSD-1.3.2's implementation of
> it),

As I recall, the question was whether NetBSD's behavior as a *router*
should be changed.  This has nothing at all to do with its
implementation of PMTU-D, which kicks in when the NetBSD machine is one
of the *endpoints* of the connection.  (In the terminology of my other
recent message on the subject, the proposal affected what NetBSD should
do if it's R, not A or B.)

> I currently cannot get e-mail from at least one known site unless
> either they fix their firewall or I find some way to ensure the path
> MTU is 1500 bytes all the way through.

I currently cannot get email from at least one site unless they fix
their open relays and come off the RBL.

Big schmeel.  I don't consider lack of connectivity with broken sites
to be an issue worth worrying about, much less breaking[%] NetBSD for.

[%] This is admittedly a loaded word.  I use it because that's exactly
what I see this as: causing NetBSD to violate the IP spec by sometimes
fragmenting and forwarding packets that are specifically marked DF.

> Since I can't control their firewall, and I have other reasons not to
> want to change the path MTU in this case, I want to find some way to
> disable PMTUD on my end.

Fine, so disable it.  This is orthogonal to proposing that NetBSD
should fragment and forward packets marked DF (even if it does send
back a need-frag ICMP).

> That means either breaking PMTUD by always ignoring the DF bit, or
> finding some way of ignoring the DF bit after PMTUD has failed to get
> the packet size down as necessary.

No; since your host is an end system, it means just turning off PMTU-D
(at least for that connection), in which case your host won't be
setting DF and nobody along the path should ever be sending back
need-frag ICMPs.

> If indeed PMTUD is not robust as designed then "we" also should be
> putting forward proposals to get it fixed at the RFC level.

Saying that PMTU-D is broken-as-designed because it fails when hosts
drop need-frag ICMPs is like saying TCP is broken-as-designed because
it fails when hosts drop data-free segments (ie, pure ACK).  The only
sense I can see in which the analogy can be considered unreasonable is
that the former is somewhat commoner in today's Internet.

In short, blame the broken box, not the protocol.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B