On Mon, 1 Jun 2015 14:40:41 -0700, Jesse Gross wrote: > On Thu, May 14, 2015 at 11:10 AM, Jiri Benc <[email protected]> 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 _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
