Re: ICMP_UNREACH_NEEDFRAG returns iface MTU instead of route?

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

On Fri, Dec 20, 2013 at 11:01:03AM -0500, Greg Troxel wrote:
> That's a good question.  I would suggest reading the standards, and
> checking what other systems do.  My quick reaction is that MTU on a
> route is a local matter used to choose MTU on outgoing packets that are
> originated, and I don't see why it would affect forwarding.  But I can
> also see that a philosophy that it's better to send ICMP fragmentation
> required as soon as possible.

RFC 1191 says, "When a router is unable to forward a datagram because
it exceeds the MTU of the next-hop network and its Don't Fragment bit
is set, the router is required to return an ICMP Destination
Unreachable message to the source of the datagram, with the Code
indicating "fragmentation needed and DF set". To support the Path MTU
Discovery technique specified in this memo, the router MUST include
the MTU of that next-hop network in the low-order 16 bits of the ICMP
header field that is labelled "unused" in the ICMP specification [7]."

It seems reasonable to me to interpret the route's MTU as specifying
"MTU of the next-hop network".

I checked a Debian Linux system (running kernel 2.6.32-5-686), and it
returns the route MTU. E.g., repeating the same type of test as I did
earlier: ip route add 149.20.53.86 dev eth0 mtu 1200

Then from another machine, pinged 149.20.53.86 with a 1300-byte packet
and DF set. The MTU returned in the ICMP fragmentation needed packet
was 1200.

NetBSD's current behavior would seem to break PMTU discovery... it
won't forward DF packets larger than the route MTU, but then it tells
the sender that larger packets are OK.
-- 
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++