Message-ID: <e685d22c-e28e-8318-f612-07e2d1cd03ab@katalix.com>
Date:   Tue, 19 Feb 2019 16:36:55 +0000
From:   James Chapman <jchapman@...alix.com>
To:     t.martitz@....de
Cc:     davem@...emloft.net, netdev <netdev@...r.kernel.org>
Subject: Re: L2TPv3 offset

On 19/02/2019 13:09, t.martitz@....de wrote:
>
> Hello,
>
> thanks for your quick response.
>
> "James Chapman" <jchapman@...alix.com> schrieb am 19.02.2019 13:40:10:
>
> > Von: "James Chapman" <jchapman@...alix.com>
> > An: t.martitz@....de
> > Kopie: davem@...emloft.net, "netdev" <netdev@...r.kernel.org>
> > Datum: 19.02.2019 13:40
> > Betreff: Re: L2TPv3 offset
> >
> > On 19/02/2019 09:17, t.martitz@....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).

Powered by blists - more mailing lists