[RFE] NAT64 support with neutron

[Irena Berezovsky]

In some deployment scenarios, it is likely that the new clients will be
IPv6-only and they will want to connect to the existing IPv4-only servers.
In order for all of these devices to be able to communicate, they all need to
talk IPv6 or have some sort of translator involved. Translation requires
technology such as NAT64. NAT64 allow IPv6 hosts to communicate
with IPv4 servers by creating a NAT-mapping between the IPv6 and the IPv4
address. While supporting IPv4/IPv6 translation means providing separate IPv4
and IPv6 connectivity thus incurring additional complexity as well as
additional operational and administrative costs, sometimes its a necessary
step towards transition to the pure IPv6 networks.
We would like to propose NAT64 support by following similar method as FIP allocation for fixed IPv4 address, but this time assigning IPv6 address.

Consider the topology like in the following diagram.
Allow to associate a IPv6 floating IP allocated on the "external network" to a fixed IP on private network.

    +------------+
    | external |
    | network |IPv6 floating-ip
    |------------+
                 |
                 |
                 |router gateway port
             +---+-------+
             | router |
             +----+------+
                  |router
                  |interface
                  |
                  |
            +-----+-------+
            | private |
            | network | fixed-ip
            |-------------+
For API, the following changes are necessary:

* Add an extension "nat64" for the feature discovery.
  The extension does not add any resources or attributes to the REST API.

* Allow IPv6 floating IP association via a router gateway interface.

* The existing l3 create floating IP logic should be updated to allow
  IPv6 external subnet for the floating IP allocation.

[Dustin Lundquist (dlundquist)]

This is an unusual deployment of NAT64. NAT64 should be deployed by the client's provider to provide connectivity to the IPv4 internet.

To provide services to IPv6 client it would be preferable to either:

* Configure the servers in a dual stack configuration.
* Use a dual stack load balancer, this as the advantage the the backend servers themselves can be IPv6 only and provide services to both IPv4 and IPv6 clients.

In general routing IPv6 is preferred to NATing IPv6 which in turn is preferred to protocol translation (NAT64).

Implementing NAT64 in the Neutron router would limit future implementations such as an OVS native L3 solution, since protocol translation is significantly more complex than forwarding or NAT.

[Irena Berezovsky (irenab)]

As cloud provider, one wants to enable access to existing IPv4 servers for IPv6 clients.
there are cases, when existing IPv4 servers cannot be changed to have dual stack configuration and then NAT64 is reasonable way to enable this use case.
As for the API, I think it should be possible to enable it for certain backends (i.e. MidoNet), while some backends (native OVs) may not support it.

[John Davidge (john-davidge)]

It sounds to me like the issue you're describing can be solved by using a load balancer with an IPv6 VIP to expose your IPv4-only service. Octavia has recently added support for this. Given that this use case will only be valid until services have been updated for IPv6 I think the proposed change is too heavy for a temporary fix.

[Ryu Ishimoto (ryu-midokura)]

Thanks for the informative comments, Dustin and John.

As for NAT64 use case, as Irena said, this is useful when migration from IPv4 to IPv6 is not so simple in the server side, but still want to provide services to IPv6 clients. I see this as part of the IPv6 migration step. As for the comment about limiting the future native L3 implementations, I'm curious to know what that means. Do you mean that it adds complexity that may interfere with native IPv6 implementations?

John, you're probably right about that, and it's good to know about that option. I'm curious to know about the support for IPv6 VIP -> IPv4 pool members in LBaaS. Was the use case for the support of this feature similar to the one proposed here? If so, I'm still feeling hopeful that it could be brought over to Neutron L3 side as well!

[YAMAMOTO Takashi (yamamoto)]

https://review.openstack.org/#/c/355419/ a spec in networking-midonet

[Armando Migliaccio (armando-migliaccio)]

The spec [1] got abandoned. Does this mean that this is no longer being pursued?

[1] https://review.openstack.org/#/c/355419/3

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]