Openstack dosen't allow the gateway to be the first address

Bug #1682094 reported by Fabian Wannenmacher
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Undecided
Nate Johnston

Bug Description

If you try to set the first address of an IPv6 subnet as gateway you get an error.

Example to reproduce for an flat provider network:
$ openstack network create --share --provider-physical-network provider --provider-network-type flat test
$ openstack subnet create --network test --subnet-range 2001:db8::/64 --ip-version 6 --ipv6-address-mode slaac --prefix-length 64 --gateway 200
1:db8:: bull
> HttpException: Bad Request, Invalid input for operation: Gateway is not valid on subnet.

This is annoying, because radvd should be running on the smallest IP. And rdvd runs often on the Gateway.

System:
OpenStack ocata on CentOS

Revision history for this message
Brian Haley (brian-haley) wrote :

Can you try with gateway 2001:db8::1 ? You didn't specify a complete IPv6 address in your example, not sure if it was just a typo.

Changed in neutron:
status: New → Incomplete
Revision history for this message
Fabian Wannenmacher (wanne) wrote :

2001:db8::1 would be the second adress in the subnet 2001:db8::/64. This works perfectly fine.
2001:db8::0 wich can be shortend to 2001:db8:: is the first one.
And of course this is a complete IPv6 address.

Btw. This behavior is obsolete even for IPv4. According to RFC 1878 (1995) modern software will be be capable of all using all zero hosts. But maybe OpenStack is no modern software in the view of 1995.

Revision history for this message
Brian Haley (brian-haley) wrote :

I am not going to engage in a discussion regarding Openstack not being "modern" wrt 1995.

With respect to the all-zeros interface identifier being a valid address, that is debatable. According to RFC 4291 Section 2.6.1, that is the Subnet-Router anycast address. Does Linux let you configure it? Sure. Should you use it? Probably not. With so many address available on the subnet, and the de-facto IPv4 assumption that "dot 1" is the router, which a lot of people want to carry-over to IPv6 (even if they don't need to), I don't see the point in changing the behavior here.

Revision history for this message
Fabian Wannenmacher (wanne) wrote :

I recognized, that there are many people who want to carry-over all that dump IPv4 behaviors to IPv6. That it becomes at least the same crippled as IPv4 was.
Giving /128 to customers is a other of that bad ideas or make TCP-Connection-Tracking (And breaking all non TCP-Protocols) in some middleboxes is an other. (Both used in the official Tutorials of OpenStack.)

But using the first address as gateway is definitive not some strange feature you probably should not use but the most common way to configure gateways. HE does it, many others too. (Also most use fe80:: where OpenStack doesn't recognize that it knows the prefix-length of this subnet.)

Sorry, you can write that:
(net.version == constants.IP_VERSION_4 and (ip == net.network or ip == net[-1]))
and implement IPv6
Or you can write that:
(ip == net.network or (net.version == constants.IP_VERSION_4 and ip == net[-1]))
And implement your own legacy IPv4/CIDR IPv4/IPv6 mixture. Which is maybe not *much* worse but does other than the rest of the world.
I thought it would be obvious what you want to do.

This is the second IPv6 bug in the same Line which is obviously written written for IPv4 from someone who thought only about IPv4 and knows only IPv4.
Please just remove it from the IPv6 implementations.

Python 2 was released 5 years after 1995. Why don't you remove all python 2 features?

Having after 20 years an absolutely shitty support for the actual IP protocol in a new software is one thing. That can be fixed.

But answering bugreports with a lot of bullshit instead of fixing them is an other.

Just close this, stay in the 90s.

Revision history for this message
Brian Haley (brian-haley) wrote :

You did not even respond to my comment - both RFC 4291 and IANA define the zero address of an IPv6 subnet to be reserved for the Subnet-Router anycast address. If you have information that I'm wrong about that please let me know, I've been wrong before.

But please don't try to attack people for having a stance based on fact, it's not productive at all.

Revision history for this message
Brian Haley (brian-haley) wrote :

And just to follow-on with more data...

--> ip -6 a s dev enp0s31f6 scope global
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2620:52:0:1238:2c6d:c30a:2b2c:f18/64 scope global temporary dynamic
       valid_lft 602792sec preferred_lft 83792sec

--> ip -6 r
2620:52:0:1238::/64 dev enp0s31f6 proto kernel metric 256 expires 602751sec pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80:52:0:1238::1fd dev enp0s31f6 proto static metric 100 pref medium
default via fe80:52:0:1238::1fd dev enp0s31f6 proto static metric 100 pref medium

--> ping6 -c 3 2620:52:0:1238::
PING 2620:52:0:1238::(2620:52:0:1238::) 56 data bytes
64 bytes from 2620:52:0:1238:50d3:4ab1:5c21:6080: icmp_seq=1 ttl=64 time=0.403 ms
64 bytes from 2620:52:0:1238:50d3:4ab1:5c21:6080: icmp_seq=2 ttl=64 time=0.473 ms
64 bytes from 2620:52:0:1238:50d3:4ab1:5c21:6080: icmp_seq=3 ttl=64 time=0.205 ms

--- 2620:52:0:1238:: ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2022ms
rtt min/avg/max/mdev = 0.205/0.360/0.473/0.114 ms

--> ip -6 n s to 2620:52:0:1238::
2620:52:0:1238:: dev enp0s31f6 lladdr 08:00:27:80:df:58 router REACHABLE

So there *was* a response to the all-zeros address, and since the ping had a different source address in the response it shows it was an anycast address since anycast addresses shouldn't be used in responses.

Changing this behavior would most likely break something, so I'm marking it Invalid.

Changed in neutron:
status: Incomplete → Invalid
Revision history for this message
Fabian Wannenmacher (wanne) wrote :

Sorry, after reading "Should you use it? Probably not." about implementing RFC 4291, i thought it would be more important to talk about the aims of OpenStack than about some technical details.
I never saw that as a Question.

So back to Section 2.6.1:
RedHat seems to implement IPv6 fully conform to RFC 4291.
The Interface-ID of the gateway is ::1fd but since a gateway it is a router on that subnet so it HAS to respond also to the address 2620:52:0:1238:: .
But in your setup there is a second interface of an router with the ID 50d3:4ab1:5c21:6080 . So 2620:52:0:1238:: and 2620:52:0:1238::1fd are not exchangeable. But in many setups (maybe yours too) all routers are gateways.
So using the :: host-ID is a failsafe way to specify the gateway.
If my assumption is right and 50d3:4ab1:5c21:6080 is a valid gateway too, using ::1fd as gateway fails as soon as ::1fd fails but :: would stay a working gateway as long as one of 50d3:4ab1:5c21:6080 and ::1fd stays alive without any further fail over mechanisms.
(As I sad: This only works, if there is no router which is no gateway in the network.)

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/647484

Changed in neutron:
assignee: nobody → Nate Johnston (nate-johnston)
status: Invalid → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.opendev.org/647484
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1916bc5c0627ca24e312ca55ea62c8df7eb8f158
Submitter: Zuul
Branch: master

commit 1916bc5c0627ca24e312ca55ea62c8df7eb8f158
Author: Nate Johnston <email address hidden>
Date: Mon Mar 25 10:29:23 2019 -0400

    Allow first address in an IPv6 subnet as valid unicast

    When looking at the RFC [1], there's no mention that this can't be the
    gateway address. Permit it.

    [1] https://tools.ietf.org/html/rfc4291#section-2.6.1

    Change-Id: I3f2905c2c4fca02406dfa3c801c166c14389ba41
    Fixes-Bug: #1682094

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/stein)

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/660729

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/rocky)

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/660730

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/queens)

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/660734

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/stein)

Reviewed: https://review.opendev.org/660729
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=49af575efff80f7648842cd7b530a05e1ee7d171
Submitter: Zuul
Branch: stable/stein

commit 49af575efff80f7648842cd7b530a05e1ee7d171
Author: Nate Johnston <email address hidden>
Date: Mon Mar 25 10:29:23 2019 -0400

    Allow first address in an IPv6 subnet as valid unicast

    When looking at the RFC [1], there's no mention that this can't be the
    gateway address. Permit it.

    [1] https://tools.ietf.org/html/rfc4291#section-2.6.1

    Change-Id: I3f2905c2c4fca02406dfa3c801c166c14389ba41
    Fixes-Bug: #1682094
    (cherry picked from commit 1916bc5c0627ca24e312ca55ea62c8df7eb8f158)

tags: added: in-stable-stein
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/queens)

Reviewed: https://review.opendev.org/660734
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=0cd42257aaced0b6da0f43bc5da660b6a664141f
Submitter: Zuul
Branch: stable/queens

commit 0cd42257aaced0b6da0f43bc5da660b6a664141f
Author: Nate Johnston <email address hidden>
Date: Mon Mar 25 10:29:23 2019 -0400

    Allow first address in an IPv6 subnet as valid unicast

    When looking at the RFC [1], there's no mention that this can't be the
    gateway address. Permit it.

    [1] https://tools.ietf.org/html/rfc4291#section-2.6.1

    Change-Id: I3f2905c2c4fca02406dfa3c801c166c14389ba41
    Fixes-Bug: #1682094
    (cherry picked from commit 1916bc5c0627ca24e312ca55ea62c8df7eb8f158)

tags: added: in-stable-queens
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/rocky)

Reviewed: https://review.opendev.org/660730
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=663c727f993106f654f8087f9d5122cee94bf466
Submitter: Zuul
Branch: stable/rocky

commit 663c727f993106f654f8087f9d5122cee94bf466
Author: Nate Johnston <email address hidden>
Date: Mon Mar 25 10:29:23 2019 -0400

    Allow first address in an IPv6 subnet as valid unicast

    When looking at the RFC [1], there's no mention that this can't be the
    gateway address. Permit it.

    [1] https://tools.ietf.org/html/rfc4291#section-2.6.1

    Change-Id: I3f2905c2c4fca02406dfa3c801c166c14389ba41
    Fixes-Bug: #1682094
    (cherry picked from commit 1916bc5c0627ca24e312ca55ea62c8df7eb8f158)

tags: added: in-stable-rocky
tags: added: neutron-proactive-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/677539

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/pike)

Reviewed: https://review.opendev.org/677539
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e37e714b0816a0b95902fdd384cf884643d260d7
Submitter: Zuul
Branch: stable/pike

commit e37e714b0816a0b95902fdd384cf884643d260d7
Author: Nate Johnston <email address hidden>
Date: Mon Mar 25 10:29:23 2019 -0400

    Allow first address in an IPv6 subnet as valid unicast

    When looking at the RFC [1], there's no mention that this can't be the
    gateway address. Permit it.

    [1] https://tools.ietf.org/html/rfc4291#section-2.6.1

    Change-Id: I3f2905c2c4fca02406dfa3c801c166c14389ba41
    Fixes-Bug: #1682094
    (cherry picked from commit 1916bc5c0627ca24e312ca55ea62c8df7eb8f158)
    (cherry picked from commit 0cd42257aaced0b6da0f43bc5da660b6a664141f)

tags: added: in-stable-pike
tags: removed: neutron-proactive-backport-potential
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.