Re: ICMP_UNREACH_NEEDFRAG returns iface MTU instead of route?

[Dave Huang <khym%azeotrope.org@localhost>]

On Sat, Dec 21, 2013 at 03:03:48PM -0500, Dennis Ferguson wrote:
> You can interpret it that way if you want, but that isn't what the text
> really says.  The "MTU of the next-hop network" it is referring to is
> the MTU of the network the outgoing interface is attached to; it is a
> synonym for the next hop interface MTU.  This also means, of course, that
> the text above doesn't really apply to your situation since "exceeds the MTU
> of the next-hop network" is not the reason the datagram is being discarded
> in your case.

How does the OS know what the MTU of the next-hop network is? By
adding a static route, I'm declaring what I want the next hop's
outgoing interface to be. It seems reasonable that I should also be
able to use it to declare what the MTU is, if the default MTU assumed
by the system based on the interface type is incorrect for whatever
reason.

> The reason is that the only
> use I've seen made of the route MTU field is to implement a cache of PMTUs
> discovered by applications running on the local host, and it is normally
> considered quite inappropriate for a router to enforce the PMTUs learned
> by its local applications on packets originated by other hosts.  It is
> possible, however, that the field is no longer used for PMTU discovery
> caching and that the remaining uses actually do require route MTUs to be
> applied to forwarded packets for some reason.

It doesn't seem like NetBSD uses it as a PMTU cache--at least I've
never seen "netstat -r" show any routes added due to PMTU discovery.

> In any case it is clear that something is broken.  What isn't clear, however,
> is whether it is the MTU in the ICMP message or the packet drop which caused
> the message to be sent which is the broken bit.

I was just experimenting with route MTUs when I came across this
problem; I don't have any real need or use for them, so I wouldn't
personally be affected either way. That said, I do think it makes
sense for the route MTU to be a way to administratively set the "MTU
of the next-hop network" for a certain route. Which is what NetBSD
already does-- packets being forwarded through the router that are
larger than the route MTU do get fragmented if DF is not set. This
would also match the Linux behavior, and I think the FreeBSD behavior
too. I haven't actually tried on FreeBSD, but there's a comment in
their ip_input.c:ip_forward() that says, "Try to cache the route MTU
from ip_output so we can consider it for the ICMP_UNREACH_NEEDFRAG
"Next-Hop MTU" field described in RFC1191." followed by
  mtu = ro.ro_rt->rt_rmx.rmx_mtu;

Later, when the ICMP needs frag is sent, the MTU sent back is the
minimum of the interface MTU and the route MTU.
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym%azeotrope.org@localhost |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 38 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++