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

[Jiri Benc]

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.

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

 Jiri

-- 
Jiri Benc