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 A8A04C43381 for ; Tue, 19 Feb 2019 12:45:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 771EB217D9 for ; Tue, 19 Feb 2019 12:45:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=katalix.com header.i=@katalix.com header.b="0DxJex5Q" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727276AbfBSMpb (ORCPT ); Tue, 19 Feb 2019 07:45:31 -0500 Received: from mail.katalix.com ([82.103.140.233]:57217 "EHLO mail.katalix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726977AbfBSMpa (ORCPT ); Tue, 19 Feb 2019 07:45:30 -0500 X-Greylist: delayed 315 seconds by postgrey-1.27 at vger.kernel.org; Tue, 19 Feb 2019 07:45:29 EST 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 3C133B823B; Tue, 19 Feb 2019 12:40:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=katalix.com; s=mail; t=1550580011; bh=CD54sw1W7HqwUiOQXWYaWOi//kUuRFBGcF/RIzNGQIQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=0DxJex5QIeof8gKWj8F8Kwh8IdLN2N7/BcIrdUDSh/ySLT7aDn81nO87tL3UCHjCO m6tAEhDCdJif42xuj/vKIodWEIzmYh0A9z1/mKOZ9GmobzUu0+JSYByDDwIsYZaHSV zVO5Vh74AwgoVGNXKR5qpSn3MrplxSwSm+q1dcqw= Subject: Re: L2TPv3 offset To: t.martitz@avm.de Cc: davem@davemloft.net, netdev References: 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: <40957000-591c-c871-ddf5-89e05fa958d0@katalix.com> Date: Tue, 19 Feb 2019 12:40:10 +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 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=C2=A0that 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#l2= tp-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