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  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:	Fri, 16 Mar 2012 12:19:02 +0000
From:	James Chapman <>
To:	Benjamin LaHaise <>
CC:	Eric Dumazet <>,
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
More majordomo info at

Powered by blists - more mailing lists