Re: (with patch!) Re: ICMP_UNREACH_NEEDFRAG returns iface MTU instead of route?

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sat, Dec 28, 2013 at 04:07:25PM -0500, Mouse wrote:
> 
> > I suggest we fix it this way for now and count the dancing angels
> > once we have stopped being stuck with the pins.
> 
> Why the derision?

Because it's been two weeks of arguing about _how_ to fix a fairly
serious bug, while nobody's actually checked anything in to fix it
even in the interim even though we all clearly know at least two
different, very simple, ways how.  Users shouldn't be left in the
lurch like that while we discuss.

> Still, it's no skin off my nose, since my systems won't be affected
> either way; if you really think NetBSD would be better off paying
> attention to route MTUs only sometimes, go for it.

I think that if this discussion illustrates anything, it's that the
notion of a "route MTU" is incoherent -- a back-formed conceptual
rationale for the expedient hack of storing path MTUs in the routing
table, which we're now paying for.

I don't object to storing path MTUs in the routing table, because it
is a central datastructure with properties that make them convenient
to store there and efficient to look up from there (since we already
must do the routing lookup at packet output time).  I *do* object
to the bickering over what seems to me to be the consequent neologism
"route MTU" preventing us from quickly applying an obvious fix to
solve these old, very real, problems for users caused by the original
implementation of path MTU.

Thor