[ovs-dev] [RFC PATCH kernel 04/10] openvswitch: IPv6 type of tunnel vports

[Jesse Gross]

On Tue, Jun 2, 2015 at 8:58 AM, Jiri Benc <jbenc at redhat.com> wrote:
> On Mon, 1 Jun 2015 14:40:41 -0700, Jesse Gross wrote:
>> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc <jbenc at redhat.com> wrote:
>> > diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
>> > index 4d26da40b01f..ba7ae3b05308 100644
>> > --- a/include/uapi/linux/openvswitch.h
>> > +++ b/include/uapi/linux/openvswitch.h
>> > @@ -267,6 +267,7 @@ enum {
>> >         OVS_TUNNEL_ATTR_UNSPEC,
>> >         OVS_TUNNEL_ATTR_DST_PORT, /* 16-bit UDP port, used by L4 tunnels. */
>> >         OVS_TUNNEL_ATTR_EXTENSION,
>> > +       OVS_TUNNEL_ATTR_OVER_IPV6,/* when present, tunneling over IPv6 */
>>
>> This is perhaps a flaw in the existing interface but old kernels will
>> silently ignore requests for v6 tunnels and create v4 ones instead,
>> which seems like a bad thing.
>
> They'll refuse any flow, though, because they'll see empty ipv4 dst
> address, thus nothing will really break.

That's true although it would be nice to handle it a little more gracefully.

> I don't think there's a mechanism in place to query kernel data path
> capabilities, thus there's no straightforward way to detect this.

I think we will likely need to implement one at some point - this is
particularly an issue with extensible tunnels if you need to do
per-packet operations. However, it's probably not relevant at this
point for the purposes of IPv6.

>> I also think that it is important to figure out how to model
>> simultaneous v4 and v6 tunnels on the same port as it seems like a
>> reasonable thing to do, even if it is not supported initially. If they
>> share the same vport in the kernel so they can bind at the same time
>> then I guess this flag isn't really needed.
>
> Thinking about that more, one option is calling
> kernel_setsockopt(IPV6_V6ONLY) in udp_sock_create6. Not sure it will be
> acceptable but I don't see any reason against this.
>
>> However, perhaps this is all moot anyways assuming the that netdevice
>> based model is accepted as the ports would presumably be configured
>> directly through that.
>
> The kernel tunneling implementation differentiates ipv4 and ipv6
> tunnels, thus we'll still need different kind of ports.

I agree that it currently differentiates but I'm not sure that it
needs to. For device based tunnels, we already share sockets so why
not open always open a single dual stack socket and then let
individual devices or flows have addresses that are matched
appropriately? I guess this seems fairly clean to me and would
completely avoid the concerns you had earlier about using the right
port type or switching port types.