From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F5A2C43381 for ; Tue, 19 Feb 2019 16:37:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 078B021738 for ; Tue, 19 Feb 2019 16:37:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=katalix.com header.i=@katalix.com header.b="JKSUHJH8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729175AbfBSQg7 (ORCPT ); Tue, 19 Feb 2019 11:36:59 -0500 Received: from mail.katalix.com ([82.103.140.233]:57357 "EHLO mail.katalix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725991AbfBSQg7 (ORCPT ); Tue, 19 Feb 2019 11:36:59 -0500 Received: from [192.168.1.16] (82-69-108-24.dsl.in-addr.zen.co.uk [82.69.108.24]) (Authenticated sender: james) by mail.katalix.com (Postfix) with ESMTPSA id 7D25BB8276; Tue, 19 Feb 2019 16:36:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=katalix.com; s=mail; t=1550594215; bh=ATDGLTSFh31gVoxJN9yzafjZlRW4CSfchlh2poDNWno=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=JKSUHJH8G4FBtaIDpxigGMApLc2HgQADb1hlwF1lt1uvXbsO8jOI1bU5kvIpi/GZE fe8CNGRXMyBape+X8+ldbqtn6DfBiTqo+IuWsd+kcYqYv4LnY6KczcqcX+To8nzmah fnAcOkleeSkG8ulUDHoQdMG/aIZVbYCezL0O2CLg= Subject: Re: L2TPv3 offset To: t.martitz@avm.de Cc: davem@davemloft.net, netdev References: <40957000-591c-c871-ddf5-89e05fa958d0@katalix.com> From: James Chapman Openpgp: preference=signencrypt Autocrypt: addr=jchapman@katalix.com; prefer-encrypt=mutual; keydata= mQENBFDmvq0BCACizu6XvQjeWZ1Mnal/oG9AkCs5Rl3GULpnH0mLvPZhU7oKbgx5MHaFDKVJ rQTbNEchbLDN6e5+UD98qa4ebvNx1ZkoOoNxxiuMQGWaLojDKBc9x+baW1CPtX55ikq2LwGr 0glmtUF6Aolpw6GzDrzZEqH+Nb+L3hNTLBfVP+D1scd4R7w2Nw+BSQXPQYjnOEBDDq4fSWoI Cm2E18s3bOHDT9a4ZuB9xLS8ZuYGW6p2SMPFHQb09G82yidgxRIbKsJuOdRTIrQD/Z3mEuT/ 3iZsUFEcUN0T/YBN3a3i0P1uIad7XfdHy95oJTAMyrxnJlnAX3F7YGs80rnrKBLZ8rFfABEB AAG0JEphbWVzIENoYXBtYW4gPGpjaGFwbWFuQGthdGFsaXguY29tPokBOAQTAQIAIgUCUOa+ rQIbIwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQINzVgFp/OkBr2gf7BA4jmtvUOGOO JFsj1fDmbAzyE6Q79H6qnkgYm7QNEw7o+5r7EjaUwsh0w13lNtKNS8g7ZWkiBmSOguJueKph GCdyY/KOHZ7NoJw39dTGVZrvJmyLDn/CQN0saRSJZXWtV31ccjfpJGQEn9Gb0Xci0KjrlH1A cqxzjwTmBUr4S2EHIzCcini1KTtjbtsE+dKP4zqR/T52SXVoYvqMmJOhUhXh62C0mu8FoDM0 iFDEy4B0LcGAJt6zXy+YCqz7dOwhZBB4QX4F1N2BLF3Yd1pv8wBBZE7w70ds7rD7pnIaxXEK D6yCGrsZrdqAJfAgYL1lqkNffZ6uOSQPFOPod9UiZLkBDQRQ5r6tAQgAyROh3s0PyPx2L2Fb jC1mMi4cZSCpeX3zM9aM4aU8P16EDfzBgGv/Sme3JcrYSzIAJqxCvKpR+HoKhPk34HUR/AOk 16pP3lU0rt6lKel2spD1gpMuCWjAaFs+dPyUAw13py4Y5Ej2ww38iKujHyT586U6skk9xixK 1aHmGJx7IqqRXHgjb6ikUlx4PJdAUn2duqasQ8axjykIVK5xGwXnva/pnVprPSIKrydNmXUq BIDtFQ4Qz1PQVvK93KeCVQpxxisYNFRQ5TL6PtgVtK8uunABFdsRqlsw1Ob0+mD5fidITCIJ mYOL8K74RYU4LfhspS4JwT8nmKuJmJVZ5DjY2wARAQABiQEfBBgBAgAJBQJQ5r6tAhsMAAoJ ECDc1YBafzpA9CEH/jJ8Ye73Vgm38iMsxNYJ9Do9JvVJzq7TEduqWzAFew8Ft0F9tZAiY0J3 U2i4vlVWK8Kbnh+44VAKXYzaddLXAxOcZ8YYy+sVfeVoJs3lAH+SuRwt0EplHWvCK5AkUhUN jjIvsQoNBVUP3AcswIqNOrtSkbuUkevNMyPtd0GLS9HVOW0e+7nFce7Ow9ahKA3iGg5Re9rD UlDluVylCCNnUD8Wxgve4K+thRL9T7kxkr7aX7WJ7A4a8ky+r3Daf7OhGN9S/Z/GMSs0E+1P Qm7kZ2e0J6PSfzy9xDtoRXRNigtN2o8DHf/quwckT5T6Z6WiKEaIKdgaXZVhphENThl7lp8= Organization: Katalix Systems Ltd Message-ID: Date: Tue, 19 Feb 2019 16:36:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 19/02/2019 13:09, t.martitz@avm.de wrote: > > Hello, > > thanks for your quick response. > > "James Chapman" schrieb am 19.02.2019 13:40:10: > > > Von: "James Chapman" > > An: t.martitz@avm.de > > Kopie: davem@davemloft.net, "netdev" > > 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 Linu= x > > > 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, wi= ll > > > 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=C2=A0that we can use for pr= etty > > > much the same purpose but I get the feeling that this should only b= e 0 > > > or 4 while we would need 2 or 6. I get this feeling because "ip l2t= p" > > > 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 definin= g a > > new L2SpecificSublayer type since the L2TPv3 header has no offset fie= ld. > > There are two standard L2TPv3 sublayers supported - None and Default.= > > These are fixed size (0 and 4 bytes respectively), hence the kernel n= ow > > 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 Interne= t > > 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 ne= w > 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).