[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEfhGiyTGS_ccz1mQquk3VYTG_3eU4+4s+wQpMffRMUaBEcLaQ@mail.gmail.com>
Date: Wed, 26 Apr 2017 13:59:19 -0400
From: Craig Gallek <kraigatgoog@...il.com>
To: Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
"David S . Miller" <davem@...emloft.net>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] ip6_tunnel: Fix missing tunnel encapsulation
limit option
On Wed, Apr 26, 2017 at 1:07 PM, Craig Gallek <kraigatgoog@...il.com> wrote:
> From: Craig Gallek <kraig@...gle.com>
>
> The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
> IPV6_TLV_PADN options when an encapsulation limit is defined (the
> default is a limit of 4). An MTU adjustment is done to account for
> these options as well. However, the options are never present in the
> generated packets.
>
> ipv6_push_nfrag_opts requires that IPV6_RTHDR be present in order to
> include any IPV6_DSTOPTS options. The v6 tunnel code does not
> use routing options, so the encap limit options are not included.
>
> A brief reading of RFC 3542 section 9.2 (specifically the 4th paragraph)
> makes me believe that this requirement in the kernel is incorrect.
Looking more closely, I think I'm wrong here. Specifically, the cmsg
parser puts IPV6_RTHDRDSTOPTS in dst0opt and IPV6_DSTOPTS in dst1opt.
The tunnel code is currently building dst0opt and using
ipv6_push_nfrag_opts. Perhaps it should be building dst1opt and
calling ipv6_push_frag_opts?
Powered by blists - more mailing lists