quoted

 The next question I have is about the behavior of the new setting
 in the presence of an RA MTU option.  It seems like the sysctl
 doesn't override that RA MTU option, but rather just clamps it.

 And then if it's in range, this controls only whether the default
 route has it's MTU adjusted.

 That doesn't make any sense to me if we then go and do the
 rt6_mtu_change() call unconditionally.  The route metric update
 and the rt6_mtu_change() go hand in hand.

Agreed but that gets interesting:

I guess during testing the cnf.mtu6 value was equal to the newly
announced mtu value, so the rt6_mtu_change call does not happen. We
update cnf.mtu6 so a second RA packet would actually bring the system
into the desired state but we have a moment where the default route
carries a too big MTU. That's not good.

Agreed.

Easiest solution is to reorder those calls but that also leaves us with
a time frame where we carry the incorrect MTU on the default route.
Otherwise we must conditionally filter out the default routes.
Roman, any ideas?

I think, such approach will work on practise, but looks not very beatiful.

May be, a better idea is to serarate per-route and per-device MTU,
so an updating of per-device MTU will not affect per-route MTU.
Actual MTU can always been calculated as min(route_mtu, device_mtu),
but we wouldn't need to update mtu on each route on receiving RA MTU option, 
for instance.

Do you see any problems with such approach?

Thanks,
Roman