Re: L2TPv3 offset

Re: L2TPv3 offset

[James Chapman]

On 19/02/2019 09:17, t.martitz@avm.de wrote:
>
> Hello,
>
> I saw that you removed the offset option from l2tp sessions in Linux
> 4.16 (commit 900631ee6a2651dc4fbaecb8ef9fa5f1e3378853 l2tp: remove
> configurable payload offset). Since we need something like that I'm
> reaching out to you.
>
Adding netdev.
>
>
> Our use case is pseudo-wire over l2tp, so we encapsulate ethernet
> within l2tpv3. This has lots of benifits for us, but one remarkable
> drawback is that the receiver, who's removing the encapsulation, will
> see a misaligned inner IP header.
>
> So we planned to use the offset to correct that. But I saw that the
> offset was removed not too long ago. Now I see that there is still
> "l2specific_len" / L2TP_ATTR_L2SPEC_LEN that we can use for pretty
> much the same purpose but I get the feeling that this should only be 0
> or 4 while we would need 2 or 6. I get this feeling because "ip l2tp"
> of the iproute2 package does not allow setting this at all and
> hardcodes 0 or 4 based on the type.
>
In L2TPv3, any payload offset would need to be implemented by defining a
new L2SpecificSublayer type since the L2TPv3 header has no offset field.
There are two standard L2TPv3 sublayers supported - None and Default.
These are fixed size (0 and 4 bytes respectively), hence the kernel now
ignores L2TP_ATTR_L2SPEC_LEN since the length can be derived from
L2TP_ATTR_L2SPEC_TYPE. For reference, the set of defined types are
listed at
https://www.iana.org/assignments/l2tp-parameters/l2tp-parameters.xhtml#l2tp-parameters-37.
No L2SpecificSublayer type was ever defined for L2TPv3 to allow a
configurable payload offset in ethernet pseudowires.

>
> So my question is what should we do know? Being based on removed
> functionality is kind of bad, but we must fix the misaligned inner ip
> header.
> We control the sender and receiver so we could apply all kinds of
> hacks, but we would rather find a solution compliant with the Internet
> community.
>
If you really need to insert padding in transmitted L2TPv3 packets
between the L2TPv3 header and its payload, one option is to define a new
L2SpecificHeaderType and patch the kernel to accept it.

If you control both the sender and receiver, is using FOU an option?

James

Re: L2TPv3 offset

[James Chapman]

On 19/02/2019 13:09, t.martitz@avm.de wrote:
>
> Hello,
>
> thanks for your quick response.
>
> "James Chapman" <jchapman@katalix.com> schrieb am 19.02.2019 13:40:10:
>
> > Von: "James Chapman" <jchapman@katalix.com>
> > An: t.martitz@avm.de
> > Kopie: davem@davemloft.net, "netdev" <netdev@vger.kernel.org>
> > Datum: 19.02.2019 13:40
> > Betreff: Re: L2TPv3 offset
> >
> > On 19/02/2019 09:17, t.martitz@avm.de wrote:
> > >
> > > Hello,
> > >
> > > I saw that you removed the offset option from l2tp sessions in Linux
> > > 4.16 (commit 900631ee6a2651dc4fbaecb8ef9fa5f1e3378853 l2tp: remove
> > > configurable payload offset). Since we need something like that I'm
> > > reaching out to you.
> > >
> > Adding netdev.
> > >
> > >
> > > Our use case is pseudo-wire over l2tp, so we encapsulate ethernet
> > > within l2tpv3. This has lots of benifits for us, but one remarkable
> > > drawback is that the receiver, who's removing the encapsulation, will
> > > see a misaligned inner IP header.
> > >
> > > So we planned to use the offset to correct that. But I saw that the
> > > offset was removed not too long ago. Now I see that there is still
> > > "l2specific_len" / L2TP_ATTR_L2SPEC_LEN that we can use for pretty
> > > much the same purpose but I get the feeling that this should only be 0
> > > or 4 while we would need 2 or 6. I get this feeling because "ip l2tp"
> > > of the iproute2 package does not allow setting this at all and
> > > hardcodes 0 or 4 based on the type.
> > >
> > In L2TPv3, any payload offset would need to be implemented by defining a
> > new L2SpecificSublayer type since the L2TPv3 header has no offset field.
> > There are two standard L2TPv3 sublayers supported - None and Default.
> > These are fixed size (0 and 4 bytes respectively), hence the kernel now
> > ignores L2TP_ATTR_L2SPEC_LEN since the length can be derived from
> > L2TP_ATTR_L2SPEC_TYPE. For reference, the set of defined types are
> > listed at
> > https://www.iana.org/assignments/l2tp-parameters/l2tp-
> > parameters.xhtml#l2tp-parameters-37.
> > No L2SpecificSublayer type was ever defined for L2TPv3 to allow a
> > configurable payload offset in ethernet pseudowires.
>
>
> So are we the only ones to encapsulate Ethernet within L2TPv3? It's
> hard to believe.
>
No of course not.
>
>
> Because everytime a LCCE decapsulates such traffic it'll suffer from
> unaligned access to the inner IP header (likewise for the outer IP
> header when encapsulating). It's a fundamental assumption that the IP
> header is word-aligned in Linux so I'm surprised this isn't solved
> already. And now the only way "fix" without patching the kernel is
> being removed.
>
It was removed to prevent the possibility of sending non-compliant
L2TPv3 packets into the network. L2TPv3 allows for new
L2SpecificSublayer header types to be defined. It's a shame that one
hasn't been added to allow for this.

Are you using a CPU that can't do unaligned word accesses?

>
> >
> > So my question is what should we do know? Being based on removed
> > functionality is kind of bad, but we must fix the misaligned inner ip
> > header.
> > We control the sender and receiver so we could apply all kinds of
> > hacks, but we would rather find a solution compliant with the Internet
> > community.
> >
> If you really need to insert padding in transmitted L2TPv3 packets
> between the L2TPv3 header and its payload, one option is to define a new
> L2SpecificHeaderType and patch the kernel to accept it.
>
> If you control both the sender and receiver, is using FOU an option?
>

What does FOU refer to?

Foo-Over-UDP. See ip-fou(8).

Re: L2TPv3 offset

[Guillaume Nault]

On Tue, Feb 19, 2019 at 04:36:55PM +0000, James Chapman wrote:
> On 19/02/2019 13:09, t.martitz@avm.de wrote:
> >
> > Because everytime a LCCE decapsulates such traffic it'll suffer from
> > unaligned access to the inner IP header (likewise for the outer IP
> > header when encapsulating). It's a fundamental assumption that the IP
> > header is word-aligned in Linux so I'm surprised this isn't solved
> > already. And now the only way "fix" without patching the kernel is
> > being removed.
> >
IIUC, you'd be perfectly fine running without offset if the stack was
properly handling the alignment problems created by the encapsulated
ethernet header.

Unaligned headers is a fundamental problem when tunneling ethernet
frames. I'd expect other encapsulation modules (vxlan, geneve,
gretap...) to have the same issues (but I'd be happy to be proven
wrong).

The topic has been discussed a few years ago:
https://lore.kernel.org/netdev/20160922.015242.735026657310158125.davem@davemloft.net/
I might very well have missed some discussions, but I don't remember
any patch aimed at tackling this problem so far.