netdev - Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F632FB6.9010206@katalix.com>
Date:	Fri, 16 Mar 2012 12:19:02 +0000
From:	James Chapman <jchapman@...alix.com>
To:	Benjamin LaHaise <bcrl@...ck.org>
CC:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6

Hi Ben,

Do you have an updated patch to test?

On 15/02/12 08:26, James Chapman wrote:
> This is very timely - I'm keen to see IPv6 support added for L2TPv2 and
> L2TPv3, but we can work on L2TPv2 first.
> 
> On 15/02/12 05:06, Eric Dumazet wrote:
>> Le mardi 14 février 2012 à 17:31 -0500, Benjamin LaHaise a écrit :
>>> Hello folks,
>>>
>>> Below is a patch that adds support for L2TPv2 over UDP over IPv6. 
>>> It's an
>>> RFC at present due to 2 outstanding issues: the first is that struct
>>> pppol2tp_addr and pppol2tpv3_addr have an embedded struct
>>> sockaddr_in, and
>>> these changes have not implemented a replacement of those socket
>>> addresses.
>>> Since the existing pppol2tp{,v3}_addr structures did not place the
>>> sockaddr_in
>>> at the end of the structure, IPv6 addresses cannot be embedded without
>>> changing the ABI.  The question becomes one of how: just add a
>>> version of the
>>> pppol2tp_addr structure with a sockaddr_in6 embedded in it (easily
>>> done, as
>>> the different in address structures can be detected via sin_family in
>>> the
>>> embedded address), or replace it wholesale with a new pppol2tp_addr
>>> that has
>>> the embedded address at the end of the structure?  That is:
>>>
>>>     struct pppol2tp_addr_in6 {
>>>         int            pid;
>>>         int            fd;
>>>         struct sockaddr_in6    addr;
>>>         u16            s_tunnel, s_session;
>>>         u16            d_tunnel, d_session;
>>>     };
>>>
>>> or
>>>
>>>     struct new_pppol2tp_addr {
>>>         int            pid;
>>>         int            fd;
>>>         u32            s_tunnel, s_session;
>>>         u32            d_tunnel, d_session;
>>>         struct sockaddr_in6    addr;
>>>     };
>>>
>> My personal choice would be the latter .
> 
> Certainly put the sockaddr struct at the end in the new ipv6 struct,
> like new_pppol2tp_addr, but we need to retain the ABI. Code already
> handles two different pppol2tp_addr structs for L2TPv2 and L2TPv3, so it
> should be possible to add two more for IPv6 compatibility and have the
> code detect which form is used similar to that in pppol2tp_connect(). My
> preference for the struct naming is pppol2tp_addr_{in6,new}.
> 
>> The second issue still outstanding is that I still have to test the
>> transmit
>> path with IPv6 hardware checksumming.  I've tested with virtio_net and
>> pcnet32 with qemu, but would like to verify on real hardware.
> 
> I'll see if we have suitable hardware here. If I can find some, could
> you share your test code?
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html