[ On Tue, November 24, 1998 at 02:33:40 (+1100), Robert Elz wrote: ]
> Subject: Re: This PMTU thread 
>
> Then do it, that part of your suggestion is OK, no-one is going to care
> if your particular NetBSD based router runs like a dog and consumes Mb's of
> state.

You haven't been paying attention Robert.  I'm talking about maybe a
kilobyte per port at most.

>   | Any large packets with the DF bit set which arrive from a host
>   | listed in the second table should have their DF bit turned off and the
>   | packet will then be fragmented and forwarded as necessary.
> 
> But that is breaking IP in a very fundamental way (as you have been told
> before), and would be a truly horrid thing to do.

OK, pretend I'm totally naive:  Why and how?  (but before you start to
answer, read on -- Why and how in the following particular
circumstances?)

> Nb: IP, not PMTUD - packets with DF set are a part of the basic IP protocol,
> and while the most common reason that you will see them today is for PMTUD,
> it isn't the only reason.   For all you know the packets with DF set that
> you're blindly suggesting fragmenting might have some other reason for not
> being fragmented.

My proposed hack will only trigger for TCP or some other protocol that
does retransmission.

My hack is likely only to be enabled on a last-leg PPP hop where the
normal issues of fragmentation will not be a problem.

So far as I can tell "DF" can't be set directly by an application.

What other reasons could packets have the DF bit set?

I've read everything I can find in Stevens' books and I can't see any
valid reasons why my hack won't be both beneficial and safe if used only
where necessary.

If you've got a valid argument then state it -- don't just lean back on
a dusty old pile of RFCs and say "Because they say so".

> If you really want to find a "solution" for this, configure yourself a tunnel
> across the link(s) with the low MTU, and send the DF packets you would 
> otherwise fragment across the tunnel (the tunnelled packets can themselves be
> fragmented, they'll be reassembled at the remote end of the tunnel, before
> being decapsulated and forwarded further).

In most cases where PMTU-D breaks there's no way the affected user can
do what you suggest.  I was lucky enough to have root access to my
upstream router, but most folks aren't so lucky.  I'm *NOT* trying to
solve this problem just for myself.

> Just don't ever let me see the code that does all this nonsense.

I think that if you really take the time think about it you'll find that
it's a rather simple and elegant solution and that it gets applied at
exactly the place where its needed and only there.  When you look at the
tcpdump trace on the router the problem is so self-evident that you just
want to smack someone in the ear.  Until I'd actually read RFC 1191 I
couldn't believe it was being so stupid.  Now even when I understand the
supposed rationale for this lack of clear robustness I'm still surprised
that this "black hole discovery" idea wasn't included in PMTU-D as a
required part of the protocol, but I guess many innovations look so
simple with 20-20 hindsight.

If and when PMTU-D requires black hole detection then my hack becomes
far more redundant and can be done away with.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>