Re: PR 44508: UNREACH_NEEDFRAG ICMPs use the wrong mtu

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

On 14 Jun, 2012, at 11:51 , Mouse wrote:

> Over a year ago, I filed PR kern/44508, pointing out something I
> considered a bug with UNREACH_NEEDFRAG ICMP generation.  (To save people
> looking up the PR, the issue is that it uses the outgoing interface's
> MTU even if the relevant route's MTU is smaller.)  It affects 4.0.1 and
> 5.1; I don't know about anything else.
> 
> I haven't heard anything back at all.  Am I the only one who cares
> about this?  Do other people not consider it a bug?  Is it just that
> nobody noticed?  Or what?  I'd like to see the fix pulled up to
> netbsd-4 and netbsd-5, if that's not too unrealistic a goal.  (If it
> affects -current and/or netbsd-6 too, it might be nice to fix them,
> though they're of less immediate concern to me.)

I'm curious about what happens when a big packet arrives without the
DF bit set (but I can't look since I only have email access right now).
Does it get fragmented down to the route MTU or is it forwarded without
doing that if it fits through the interface?

I think there is no standard answer about whether this is a bug or not
since the standards for routers don't think that routes have MTUs
associated with them (despite the text early in RFC 1191 suggesting
that this might happen some day).  This is hence a non-standard
feature of the implementation which I guess can be made to behave
any way that is useful to the implementation.  That said, I always
thought that the route MTU and the other fields in the same structure
were intended as a host path characteristics cache to be consulted when
packets were originated by the local host but not necessarily when
packets were forwarded through the box (in the same way that a
host-in-a-router might discover path MTUs for transport sessions it
is participating in but would not enforce them on traffic being
forwarded through the router), but I can also see the utility of
doing it your way in the case you are describing if there are no
unfortunate side effects of this (like a router enforcing the PMTUs
its transport protocols have learned on non-local traffic).

It seems to me that it would clearly be a bug if the box reported a
different MTU in ICMP packets sent in response to packets with the DF
flag set than it used to fragment packets sent with the DF flag clear.
If there is no inconsistency, however, then whether it is a bug or a
feature would seem to depend on one's opinion of what the feature is
supposed to do.

Dennis Ferguson