On Tue, Sep 21, 1999 at 10:45:27AM -0700, Kevin Lahey wrote:
> In message <v6so48u0eq.fsf@kechara.flame.org>M Graff writes
> >It seems people who write firewall rules are idiots these days.  Most
> >places recommend blocking "all ICMP" -- which breaks M$'s
> >implementation of Path MTU discovery quite nicely.
> >
> >Here's the problem.
> >
> >I have a shark running NetBSD, which has a GRE tunnel to another
> >NetBSD box at home.  The GRE takes some overhead, of course, so
> >sometimes packets need to be fragmented.
> >
> >Since ICMP is blocked, the ICMP "host unreachable, MTU is..." packet
> >is filtered on the (in this case) remote web server end.  It also
> >seems that M$ doesn't fall back to a smaller MTU (like we do, right?)
> >to see if the ICMPs are getting lost or not.
> 
> Err, nope.  M$ actually has an option to do black hole detection,
> which you can turn on in the registry (I think).  We don't.
> I've always meant to add this, and I even wrote an Internet Draft
> about PMTU problems, including black hole detection, but I've
> always just sorta backed away from the implementation.
> 
> In this case, though, it sounds like the folks don't have black
> hole detection turned on.
> 
> >So, what would break if I changed the fragmentation semantics to be
> >something like:
> >
> >	if (tcp && dont_fragment_set && must fragment) {
> >		send ICMP packet
> >		fragment and send to host anywat
> >	} else {
> >		normal behavior here
> >	}
> 
> Sounds evil to me, but I guess it'd fix the tunnelling problem.

Yes, but is it _correct_?

That is, is PMTU discovery the one and only application, ever, of using the DF
flag?

(Meaning: are we really allowed to fragment a DF packet anyway?)

	-is

-- 
 * Progress (n.): The process through which Usenet has evolved from
   smart people in front of dumb terminals to dumb people in front of
   smart terminals.  -- obs@burnout.demon.co.uk (obscurity)