Hello!
> > >From another hand, if it is an ICMP from beyond another end of tunnel,
> > it is problem of original senders to handle them. Gateways even do not
> > see such ICMPs, which are destined not for them.
>
> Agreed. But this falls apart when the gateway is the original sender :)
I see now. It is really another missing link. The case when we are gateway
and sender from the same address altogether is missed.
Well, I think they are just to be reflected directly in dst->pmtu.
Apparently, incoming ICMPs are to be run not only through raw IP dsts
but also though policy to find matching bundles and make
dst->pmtu = min(new_pmtu, dst->pmtu) on them.
> that within each bundle, the MTU may still differ depending on the
> final destination address.
It is not _within_. Bundles are created per address pair, in your
case 192.168.0.2 -> 10.10.10.10 should be a separate bundle.
Even if we will start to do more aggressive aggregation, pmtu
discovery must result in cloning, compare with raw IPv6, where
pmtu discovery causes cloning of routes with prefix length < 128.
Actually, this even does not change things comparing to existing
understanding (not the code though :-(), because after we start
to collect pmtu on SAs, we have to recalculate dst->pmtu too,
it would be kind of expensive to run through bundle and take
minimum of all the dst->pmtu-overhead_at_this_level for
each packet, so we have to precalculate the result and store it
at top level.
Alexey
|