On 19/02/2019 13:09, t.mart...@avm.de wrote: > > Hello, > > thanks for your quick response. > > "James Chapman" <jchap...@katalix.com> schrieb am 19.02.2019 13:40:10: > > > Von: "James Chapman" <jchap...@katalix.com> > > An: t.mart...@avm.de > > Kopie: da...@davemloft.net, "netdev" <netdev@vger.kernel.org> > > Datum: 19.02.2019 13:40 > > Betreff: Re: L2TPv3 offset > > > > On 19/02/2019 09:17, t.mart...@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).
