Re: ICMP_UNREACH_NEEDFRAG returns iface MTU instead of route?

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 20 Dec, 2013, at 12:13 , Dave Huang <khym%azeotrope.org@localhost> wrote:

> 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".

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.

I don't think you'll find much help with route MTUs in the standard documents
since I'm pretty sure standard IP doesn't think that routes have associated
MTUs.  This is a non-standard feature someone made up, so someone also gets
to make up what it does and how it does that.

> 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.

NetBSD's current behavior is indeed broken.  If the router is going to
drop the packet because of its size then the ICMP unreachable error it
returns to inform the sender of this must include a packet size that
the router would not drop.

I think Greg's point is a bit different.  Since the bit of the standard
you quote says the reason for returning that error is that "a router was
unable to forward a datagram because it exceeds the MTU of the next-hop
network", then because the packet being forwarded in your case did not
"exceed the MTU of the next-hop network" one could argue that the router
shouldn't be discarding the packet in the first place.  That is, the ICMP
message is correct but the packet discard which prompted its sending
was incorrect.  Since there is no standard for what route MTUs do the
question of what they should do is going to depend on what function they
serve and what is best for that function.

I, like Greg, had the early reaction that the router shouldn't be using
the route MTU when forwarding packets (as opposed to processing packets
originated by the local host-in-the-router).  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.

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.

Dennis Ferguson