[RFE]Support NAT64

Bug #1810905 reported by zhaobo
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Invalid
Wishlist
Unassigned

Bug Description

Currentlly, Neutron FIP just support NAT v4 to v4. But the ipv6 is the future, we must face it sooner or later.

I check the old related RFE and BPs[1], seems many customers or developers want it.

In our country, goverment push to use ipv6 internally, so we can quickly move from internal ipv4 network to ipv6 network. But the infrastructure can't keep up with the ipv6 transition, so maybe the external(public) ip address is still ipv4. So for NAT64, we want internal ipv4 nat to extenal ipv6, and internal ipv6 nat to extenal ipv4(eventhough this is a not valid case in theory, but this is a real issue need to be considered.)

Also we found the midonet already support more NAT cases, including part of above mentioned, so we need a standard one in Neutron can fix the issue.

[1] https://bugs.launchpad.net/neutron/+bug/1614477
    https://bugs.launchpad.net/neutron/+bug/1787792
    https://bugs.launchpad.net/neutron/+bug/1774463
    https://blueprints.launchpad.net/neutron/+spec/nat64

Tags: api rfe
zhaobo (zhaobo6)
tags: added: api rfe
Revision history for this message
Antonio Ojea (aojea) wrote :

Our experience with midonet with NAT64 is that is hard to scale, FIP addresses work as a 1-1 mapping (IPv4 FIP <--> internal IPv6. ) and because of the huge difference between the IPv6 and IPv4 network address space is not a great solution in the long term. I think that for that scenario will make more sense to implement a lbaas service that allows you to use an IPv4 FIP and use ipv6 hosts as backends.

I really think that for the cloud use base is better to configure a dual stack environment, so you can have VMs using ipv4, ipv6 or both. If is not possible to create an IPv6 uplink in your datacenter you always can create it using a 6in4 tunnel. I think that it could be useful to add a feature to neutron that allows us to create an IPv6 uplink using a 6in4 tunnel against a tunnel broker or other router.

Revision history for this message
zhaobo (zhaobo6) wrote :

@Antonio, Hi, Thanks for your nice experience and quick reply. You are correct, many companies here are running in a dual stack env now for past the transition period, and this situation case should take a period for now in our country.

1. For the first one, IPv4 FIP <-> Internal IPv6, seem Lbaas is a possible solution.And now, we use the static configuration on the outgoing device. But it's hard to maintain or change, so we want the experience or suggestion from community experts.
2. For dual stack, that's right. It's impossible to run a single stack in this kind situation, so we keep our internal env, running dual stack env now. As you mentioned IPv6 unlink setting, for us, it's not clear for how to do that in neutron now. ;-(. So how to do that with a reasonable usecase and not affect too much towards current Neutron model, especially the Router/subnet resources.

Revision history for this message
zhaobo (zhaobo6) wrote :

So We wish the experts can discuss this again, and give some advice to us. Then we can take over the implementation. ;-)

Miguel Lavalle (minsel)
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

@Antonio,

midonet fip64 associates ipv6 floating ip to ipv4 private ip.
anyway i agree lbaas based solution can be an alternative though.

@zhaobo,

i have a few questions:

- do you have an implementation idea? (i'm curious because midonet implementation is a bit tricky as ovs datapath doesn't support the necessary transformation)

- do you need both of 6-4 and 4-6?

Revision history for this message
Miguel Lavalle (minsel) wrote :

@zhaobo,

Last week, during the Neutron drivers meeting, I asked Yamamoto to help us triage this RFE. Any responses to his questions?

Revision history for this message
Miguel Lavalle (minsel) wrote :

It's been more than four months since last time we heard from submitter. Marking this RFE as invalid. If there is interest in continue the conversation, please fell free to change the status back to "New"

Changed in neutron:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.