yahoo-eng-team team mailing list archive

[Frode Nordahl <frode.nordahl@xxxxxxxxx>]

Public bug reported:

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!

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525895

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

Status in neutron:
  New

Bug description:
  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!

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525895/+subscriptions