[ovs-dev] [PATCHv4] tunnel: Add layer 2 IPv6 GRE encapsulation support.

Ben Pfaff blp at ovn.org
Thu Jun 27 14:51:59 UTC 2019


On Thu, Jun 27, 2019 at 06:31:24AM +0000, Eli Britstein wrote:
> 
> On 6/27/2019 1:21 AM, Gregory Rose wrote:
> >
> > On 6/26/2019 11:59 AM, Ben Pfaff wrote:
> >> On Wed, Jun 26, 2019 at 08:22:07AM -0700, William Tu wrote:
> >>> The patch adds ip6gretap support. Tunnel type 'ip6gretap' is a layer 
> >>> 2 GRE
> >>> tunnel over IPv6, carrying inner ethernet packets and encap with GRE 
> >>> header
> >>> with outer IPv6 header.  Encapsulation of layer 3 packet over IPv6 
> >>> GRE, ip6gre,
> >>> is not supported yet.  I tested it by running:
> >>>    # make check-kernel TESTSUITEFLAGS='-k ip6gretap'
> >>> under kernel 5.2 and for userspace:
> >>>    # make check TESTSUITEFLAGS='-k ip6gretap'
> >>>
> >>> Signed-off-by: William Tu <u9012063 at gmail.com>
> >>> Signed-off-by: Eli Britstein <elibr at mellanox.com>
> >>> Co-authored-by: Eli Britstein <elibr at mellanox.com>
> >>> Tested-by: Greg Rose <gvrose8192 at gmail.com>
> >>> Reviewed-by: Greg Rose <gvrose8192 at gmail.com>
> >> Thanks for working to generalize OVS tunnel support.
> >>
> >> For IPv4 GRE, we use the "gre" tunnel type and then we use
> >> options:packet_type to control whether the tunnel carries L2 or L3
> >> packets.  Is there a reason that IPv6 GRE should be different?
> >
> > Hi Ben,
> >
> > unfortunately there is a reason that ipv6 gre is different and that is 
> > because it uses the ARPHRD_IP6GRE HW type.  That
> > is not currently supported by openvswitch so the best we can do for 
> > ipv6 gre is support the L2 tap driver which uses
> > the ARPHRD_ETHER type.
> >
> > Thanks,
> >
> > - Greg
> >
> >>    That is,
> >> why not just have an "ip6gre" type and then use options:packet_type to
> >> control what packets flow through it?
> >>
> >> (Actually, is there a reason why we should have a separate ip6gre at
> >> all?  That is, why not just use "gre" and then control whether the outer
> >> protocol is IPv4 or IPv6 based on whether the local and remote IPs are
> >> IPv4 or IPv6?)
> 
> Hi Ben,
> 
> I had a similar comment in 
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359940.html
> 
> The pro points are clear. The cons are that there are already 
> "ip6erspan" separately from "erspan" (unless we do the same work to 
> unite them too). Regarding "ip6gre" vs "ip6gretap", I thought it might 
> be confusing as the type of the netdev is "ip6gretap" (for L2) and there 
> is "ip6gre" type for L3. In IPv4 case, it is like this too 
> ("gre"/"gretap", but there is support for both, so "gre" is more user 
> friendly). In IPv6 case, as William and Greg commented, L3 over IPv6 GRE 
> is not supported (at least yet).

I'd like to separate the current limitations from the desired "user
interface".  I understand that we can't currently support the full
matrix of outer IPv4/IPv6 versus inner packet type.  I am not sure that
that is a good reason to distinguish them from a configuration point of
view, especially if we ultimately might support the full matrix.  If
your configuration is orthogonal, then as you add support for new cells
in the matrix, you actually *delete* documentation that describes
limitations; if it is not, then you have to add documentation that
describes the new way to configure whatever new cell you added.


More information about the dev mailing list