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]

Date:	Wed, 15 Feb 2012 08:26:14 +0000
From:	James Chapman <jchapman@...alix.com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	Benjamin LaHaise <bcrl@...ck.org>
CC:	netdev@...r.kernel.org
Subject: Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6

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?


-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
--
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