yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #55235
[Bug 1614477] [NEW] [RFE] NAT64 support with neutron
Public bug reported:
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.
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
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 |
- +---------------------+
+ +-----------------------+
+ | 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.
+ 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.
+ IPv6 external subnet for the floating IP allocation.
** Description changed:
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".
-
+ 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.
** Description changed:
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 |
- | |
- +----+-------------------------+
+ +------------+
+ | external |
+ | network |
+ | |
+ | |
+ | IPv6 floating-ip |
+ +-------------+----+
+ |
+ |
+ |router gateway port
+ +---------+-----+
+ | |
+ | router |
+ | |
+ +----+----------+
|router
|interface
|
|
- +-------------+-------+
- | private |
- | network |
- | |
- | fixed-ip |
- +---------------------+
+ +-----+-------+
+ | 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.
** Description changed:
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
+ | network |IPv6 floating-ip
+ |------------+
+ |
+ |
+ |router gateway port
+---------+-----+
- | |
| router |
- | |
+----+----------+
|router
|interface
|
|
+-----+-------+
| private |
- | network |
- | |
- | fixed-ip |
- +-------------+
+ | 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.
** Description changed:
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
+ | network |IPv6 floating-ip
|------------+
|
|
|router gateway port
- +---------+-----+
- | router |
- +----+----------+
+ +---+-------+
+ | 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.
** Description changed:
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 |
+ + 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.
** Description changed:
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 +
+ | 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.
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1614477
Title:
[RFE] NAT64 support with neutron
Status in neutron:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614477/+subscriptions
Follow ups
