PR 44508: UNREACH_NEEDFRAG ICMPs use the wrong mtu

[Mouse]

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

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Motoyuki OHMORI]

Dear Mouse,

IMHO, it seems to be a bug and affect current 6.99.3. I am happy for some
unreasonable servers (i.e., they filter out all ICMP packets) if this bug is
fixed.

Best regards,
--

Post by Mouse
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.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Mouse
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Dennis Ferguson

[...] PR kern/44508 [...]

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 it's fragmented to the route MTU, but I'd have to try it to be
sure. I certainly think it should be.

Post by Dennis Ferguson
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

Conceptually, that may be a defensible stance, but I think it runs into
the unpleasant fact that forwarded packets do use those routes to make
forwarding decisions; it does not make sense to me to use a route's MTU
for locally generated packets using the route but not for packets
forwarded using route.

Post by Dennis Ferguson
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.

I'm not certain it does that. However, I _am_ sure that the behaviour
I saw, the behaviour I've been calling a bug, leads PMTU-D-capable
senders to repeatedly try packet sizes that do not actually get
through. In terms of the test setup sketched in the PR, host B tries
generating packets based on an MTU 1500, but gets told the packets are
too large and it should use-- 1500, the very MTU it did use. In the
case that led me to file the PR, host B believes this and tries MTU
1500 again, failing again, repeatedly, until it gets fed up and kills
the connection with ETIMEDOUT (the cases I was working with were TCP
connections).

This seems broken to me, regardless of the behaviour with DF clear
(though I agree the DF-clear behaviour should fragment based on the
same MTU that it uses as the "drop and send ICMP" threshold for DF-set
packets).

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Mouse

Post by Dennis Ferguson
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.

I'm not certain it does that. However, I _am_ sure that the behaviour
I saw, the behaviour I've been calling a bug, leads PMTU-D-capable
senders to repeatedly try packet sizes that do not actually get
through. In terms of the test setup sketched in the PR, host B tries
generating packets based on an MTU 1500, but gets told the packets are
too large and it should use-- 1500, the very MTU it did use. In the
case that led me to file the PR, host B believes this and tries MTU
1500 again, failing again, repeatedly, until it gets fed up and kills
the connection with ETIMEDOUT (the cases I was working with were TCP
connections).

Yes, that's an inconsistency, and a bug. If it is dropping DF-set packets
based on the route MTU then the ICMP unreachable should be reporting the
route MTU.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de