ML2 OpenvSwitch Agent GRE/VXLAN tunnel code does not support IPv6 addresses as tunnel endpoints

[Frode Nordahl]

OpenvSwitch currently does not support IPv6 addresses as endpoints for GRE or VXLAN tunnels. Subsequently the Neutron OpenvSwitch driver and agent is written with support for IPv4-only endpoint addresses in mind. However, there is ongoing work in OpenvSwitch to allow VXLAN tunnels with IPv6 addresses as endpoints. Running a datacenter with support for both IPv4 and IPv6 in the core is currently a necessity, but as soon as OpenvSwitch does support IPv6 endpoint addresses we can do without IPv4 in the core alltogether.

Supporting both IPv4 and IPv6 in a datacenter core fabric is a administrative burden and it would be a great help for operators to be able to run with a IPv6-only core network.

The purpose of this bug report is to start the work to enable Neutron to make use of OpenvSwitch tunnels with IPv6 addresses as endpoints.

It will take some time before
 a) the code is merged and mature within OpenvSwitch
 b) the distributions catch up

But hey, let's start now and be ready when it lands!

Some of the issues at hand for Neutron to support this is:
- Allow IPv6 address in configuration for local_ip

- Sanity check and assertion when IPv6 address is configured and installed OVS version does not support IPv6 endpoints for selected tunnel protocols

- Possibly have separate local_ip settings per tunnel type? (if for example VXLAN gets support before GRE)

- Or separate local_ipv6 setting and use IPv6 when supported/available?

- Interface names are typically limited to 16 characters on Linux - How to generate interface names based on 128 bit destination IPv6 addresses in 16 characters without collisions within a single installation?
 Suggestions:
 - vxlan-<8 byte hex representation of CRC32 checksum>
  - Pro: Compatible with current port/interface naming regime
  - Con: High probability for collisions (but may be good enough?)
 - vxlan-<10 byte hash>
  - Con: Non-standard hash-length
  - Con: Still high probability for collisions
 - <16 byte representation of IPv6 address>
  - Pro: less probability for collisions
  - Con: Still probability for collissions (we loose information when cramming 128 bits into 16 bytes ascii representation)
  - Con: Incompatible with current port/interface naming regime
  - Con: Information about what tunnel type is lost from port/interface name

- Implement sanity checks for local_ip and remote_ip being same IP version

- Migration strategies:
 - Is it possible/feasible to support a installation where some nodes have IPv4 local_ip and some nodes have IPv6 local_ip?
 - Do operators have to do a clean cut?

- Discussion/comments very welcome!

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/257335

[Henry Gessau (gessau)]

I have set this to wishlist without adding marking it as an RFE since we are waiting on OpenvSwitch to release v6 tunnel support.

[Armando Migliaccio (armando-migliaccio)]

Open vSwitch does not currently support IPv6 as tunnel endpoints, so I'd say we can definitely target it for N-1 and potentially consider it for backport

[sean mooney (sean-k-mooney)]

to echo armando's point ovs supports for ipv6 tunnel endpoints was experimental and was removed form the ovs 2.5 release due to numerous bugs. it may be re enabled in master as i have not checked recently but it will not be available in a packaged release until ovs 2.6 which will hopefully be available by the newton release.

[Brian Haley (brian-haley)]

Yes, I believe it is available in master. In the relnote for the OVS patch I mention "2.5+" as where the support lies, so for those on the bleeding edge they could actually get it to work if they built from source.

[Assaf Muller (amuller)]

Note that we compile OVS from source for the functional job, so there's no longer anything stopping us merging things to Neutron that aren't available in a packaged OVS. We can be ready ahead of time so that when OVS 2.6 is released we already have support for IPv6 tunnels. I highly recommend we go down this path and not artificially block ourselves waiting for dependencies.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/257335
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=773394a1887bec6ab4c2ff0308f0e830e9a9089f
Submitter: Jenkins
Branch: master

commit 773394a1887bec6ab4c2ff0308f0e830e9a9089f
Author: Frode Nordahl <email address hidden>
Date: Mon Dec 14 13:51:48 2015 +0100

    OVS: Add support for IPv6 addresses as tunnel endpoints

    Remove IPv4 restriction for local_ip configuration statement.

    Check for IP version mismatch of local_ip and remote_ip before creating
    tunnel.

    Create hash of remote IPv6 address for OVS interface/port name with least
    posibility for collissions.

    Fix existing tests that fail because of the added check for IP version
    and subsequently valid IP addresses in _setup_tunnel_port.

    DocImpact

    Change-Id: I9ec137ef8c688b678a0c61f07e9a01382acbeb13
    Closes-Bug: #1525895

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/318318

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 9.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/318318
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c3892e4df14c151d4f5ce3bf01f26b7807651dd0
Submitter: Jenkins
Branch: stable/mitaka

commit c3892e4df14c151d4f5ce3bf01f26b7807651dd0
Author: Frode Nordahl <email address hidden>
Date: Mon Dec 14 13:51:48 2015 +0100

    OVS: Add support for IPv6 addresses as tunnel endpoints

    Remove IPv4 restriction for local_ip configuration statement.

    Check for IP version mismatch of local_ip and remote_ip before creating
    tunnel.

    Create hash of remote IPv6 address for OVS interface/port name with least
    posibility for collissions.

    Fix existing tests that fail because of the added check for IP version
    and subsequently valid IP addresses in _setup_tunnel_port.

    DocImpact

    Conflicts:
     neutron/tests/common/agents/ovs_agent.py

    Change-Id: I9ec137ef8c688b678a0c61f07e9a01382acbeb13
    Closes-Bug: #1525895

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 8.2.0 release.