> On Thu, Oct 8, 2020 at 12:31 PM Maciej Żenczykowski
> <zenczykow...@gmail.com> wrote:
> > diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> > index 2a5277758379..598415743f46 100644
> > --- a/include/net/ip6_route.h
> > +++ b/include/net/ip6_route.h
> > @@ -311,19 +311,13 @@ static inline bool rt6_duplicate_nexthop(struct
> > fib6_info *a, struct fib6_info *
> > static inline unsigned int ip6_dst_mtu_forward(const struct dst_entry *dst)
> > {
> > struct inet6_dev *idev;
> > - unsigned int mtu;
> > + unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
> > + if (mtu)
> > + return mtu;
>
> What should happen here if mtu is less than idev->cnf.mtu6? Should the
> code pick the minimum? If not: will picking the higher value work, or
> will the packet be dropped? I suppose we already have this problem
> today if the administrator configures a route with a locked MTU.
This feels like a misconfiguration of some sort (ie maybe should be
denied at route config time), but honestly it could maybe potentially
be useful: for example an ipv6 route out an ipv4 only interface with
ebpf doing translation should/could actually be higher (by 20 or even
28) then device mtu. (Note: this is not the Android case, as we
translate on ingress, not egress, but a setup could be created that
would work, especially if there was no nat44 in the picture and the
ipv6 dst address would directly select the end host)
And either way... it's the same for v4, and it already behave this way
in other places.
