Floating IPs should not allocate IPv6 addresses

Bug #1752903 reported by Dr. Jens Harbott
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Won't Fix
Medium
Unassigned

Bug Description

When there are both IPv4 and IPv6 subnets on the public network, the port that a floating IP allocates there gets assigned addresses from both subnets. Since a floation IP is a pure IPv4 construct, allocating an IPv6 address for it is completely useless and should be avoided, because it will for example block removing the IPv6 subnet without a good reason. Seen in Pike as well as in master.

Tags: l3-ipam-dhcp
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

please be careful when fixing this. there is networking-midonet fip64 extension. https://developer.openstack.org/api-ref/network/v2/index.html#fip64

Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
tags: added: l3-ipam-dhcp
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

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

Changed in neutron:
assignee: nobody → Dongcan Ye (hellochosen)
status: Confirmed → In Progress
Revision history for this message
Slawek Kaplonski (slaweq) wrote : auto-abandon-script

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Changed in neutron:
assignee: Dongcan Ye (hellochosen) → nobody
status: In Progress → New
tags: added: timeout-abandon
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/599494
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Changed in neutron:
status: New → Confirmed
tags: removed: timeout-abandon
Revision history for this message
LIU Yulong (dragon889) wrote :

Add service type [1] to your subnets of public network, then it will overcome the 'problem'.
It's a bit complicated because there are some deployment and usage situations:

1. None DVR and IPv4 only
(1) public network has only one subnet which is serving for floating IP and external gateways.
set "network:floatingip", "network:router_gateway" to this subnet.

(2) public network two types of subnet, one is for floating IP, one for external gatewy.
set "network:floatingip" one
set "network:router_gateway" to another

2. DVR and IPv4 only
(1) public network has only one subnet which is serving for floating IP and external gateways.
set "network:floatingip", "network:router_gateway", "network:floatingip_agent_gateway" to this subnet.

(2) public network two types of subnet, one is for floating IP, one for external gatewy.
set "network:floatingip" one
set "network:router_gateway", "network:floatingip_agent_gateway" to another

3. None DVR and IPv4 + IPv6
4. DVR and IPv4 + IPv6

For 3. and 4., the public network may have one IPv6 subnet, set "network:router_gateway" and "network:floatingip_agent_gateway" to it.

But for now, DVR with IPv6 in compute node does not work.

[1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/subnet-service-types.html

Changed in neutron:
status: Confirmed → Won't Fix
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.