tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PR 44508: UNREACH_NEEDFRAG ICMPs use the wrong mtu



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

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

> 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                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index