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:

quoted

Le mardi 14 février 2012 à 17:31 -0500, Benjamin LaHaise a écrit :

quoted

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}.

quoted

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?