yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #91528
[Bug 2011687] Re: O flag is not enabled when ipv6_ra_mode is dhcpv6-stateful
Reviewed: https://review.opendev.org/c/openstack/neutron/+/877601
Committed: https://opendev.org/openstack/neutron/commit/c97dcfd03fccd8bfc011a26a2cbc62b4e6fa52ad
Submitter: "Zuul (22348)"
Branch: master
commit c97dcfd03fccd8bfc011a26a2cbc62b4e6fa52ad
Author: Yamato Tanaka <yatanaka@xxxxxxxxxx>
Date: Thu Mar 16 18:15:34 2023 +0900
doc: state that O flag can be 0 in dhcpv6-stateful
The current document states that O flag will be 1 when ipv6_ra_mode is
dhcpv6_stateful, but the actual implementations of both ml2/OVS and
ml2/OVN set O flag to 0 according to the following implementations:
ML2/OVS
https://github.com/openstack/neutron/blob/f545c002dc699f849026ccd1bad403b2933373aa/neutron/agent/linux/ra.py#L53-L55
ML2/OVN
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/controller/pinctrl.c#L3733-L3734
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/lib/actions.c#L3349-L3350
This actual behavior looks correct because O flag can be either 1 or 0
when M flag is 1, according to the following statement of RFC 4861:
https://www.rfc-editor.org/rfc/rfc4861#section-4.2
If the M flag is set, the O flag is redundant and can be ignored
because DHCPv6 will return all available configuration information.
To make consistency between the documet and actually behavior, this
commit changes the document to state that O flag can be either 1 or 0
when ipv6_ra_mode is dhcpv6_stateful.
Closes-Bug: #2011687
Change-Id: Id61031d7e707d0ba7b007bae0c9e0f59b8b40f8b
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2011687
Title:
O flag is not enabled when ipv6_ra_mode is dhcpv6-stateful
Status in neutron:
Fix Released
Bug description:
* Summary (Bug title): keep it small, possibly one line.
When ipv6_ra_mode is dhcpv6-stateful, both M flag and O flag should be 1, but actually only M flag is 1 and O flag is 0 in router advertisement packets.
ml2/OVS and ml2/OVN have the same behavior.
* High level description: provide a brief sentence (a couple of lines) of what are you trying to accomplish, or would like to accomplish differently.
According to the following document, both M flag and O flag will be 1
when ipv6_ra_mode is dhcpv6-stateful.
https://docs.openstack.org/neutron/latest/admin/config-ipv6.html
> Setting DHCPv6-stateless for ipv6_ra_mode configures the neutron router with an radvd agent to send
> Router Advertisements. The list below captures the values set for the address configuration
> flags in the Router Advertisement messages in this scenario. Similarly, setting DHCPv6-
> stateless for ipv6_address_mode configures neutron DHCP implementation to provide the additional network information.
> - Autonomous Address Configuration Flag = 1
> - Managed Address Configuration Flag = 0
> - Other Configuration Flag = 1
But actually only M flag is 1 and O flag is 0.
This behavior comes from the following implementations:
ML2/OVS
https://github.com/openstack/neutron/blob/f545c002dc699f849026ccd1bad403b2933373aa/neutron/agent/linux/ra.py#L53-L55
ML2/OVN
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/controller/pinctrl.c#L3733-L3734
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/lib/actions.c#L3349-L3350
I tested a RHEL 8 instance and the instance could obtain DNS server information from DHCPv6 even though O flag is 0.
Therefore some kind of operating system is not affected even if O flag is 0.
But actually there is a difference between the document and actual behavior.
Which one is correct and which should I modify?
* Pre-conditions: what is the initial state of your system? Please consider enumerating resources available in the system, if useful in diagnosing the problem. Who are you? A regular tenant or a super-user? Are you describing service-to-service interaction?
ml2/OVS or ml2/OVN
* Step-by-step reproduction steps: CLI commands or API requests are great; please, consider using http://paste.openstack.org for long outputs.
I confirmed this behavior on Train-based-OpenStack (Red Hat OpenStack
Platform 16.2)
1. Deploy OpenStack with ml2/OVS or ml2/OVN
2. Create a router and a tenant network/subnet with ipv6_stateful by the following commands
openstack network create ipv6_stateful
openstack subnet create --ip-version 6 --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful --network ipv6_stateful --subnet-range fc00:2::/64 ipv6_stateful --gateway fc00:2::1 --dns-nameserver 2001:4860:4860::8888
openstack router create router1
openstack router add subnet router1 ipv6_stateful
3. Create an instance on the network
openstack server create --flavor flavor --image rhel-8.2-290
--network ipv6_stateful --security-group sg --key-name keypair
ipv6_stateful
4. Take packet capture of Router Advertisement packets on the instance
* Expected output: what did you hope to see?
Both M flag and O flag are 1,
* Actual output: did the system silently fail (in this case log traces are useful)?
Only M flag is 1 and O flag is 0.
* Version:
I confirmed this behavior on Train-based-OpenStack (Red Hat OpenStack Platform 16.2)
But as far as I checked the implementation, the latest version should have the same behavior.
* Perceived severity: is this a blocker for you?
Serverity is low.
I just wander why there is the difference between document and actual behavior.
* Attachments: consider attaching logs, truncated log snippets are rarely useful.
The following is the excerpt of actual packet captures.
<ML2/OVN>
~~~
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x2a73 [correct]
[Checksum Status: Good]
Cur hop limit: 255
Flags: 0x80, Managed address configuration, Prf (Default Router Preference): Medium
1... .... = Managed address configuration: Set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : fa:16:3e:de:92:07)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: fa:16:3e:de:92:07 (fa:16:3e:de:92:07)
ICMPv6 Option (MTU : 1442)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1442
ICMPv6 Option (Prefix information : fc00:2::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: Infinity (4294967295)
Preferred Lifetime: Infinity (4294967295)
Reserved
Prefix: fc00:2::
~~~
<ml2/OVS>
~~~
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x986a [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x80, Managed address configuration, Prf (Default Router Preference): Medium
1... .... = Managed address configuration: Set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 300
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : fc00:2::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 86400
Preferred Lifetime: 14400
Reserved
Prefix: fc00:2::
ICMPv6 Option (MTU : 1450)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1450
ICMPv6 Option (Source link-layer address : fa:16:3e:a6:2f:3d)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: fa:16:3e:a6:2f:3d (fa:16:3e:a6:2f:3d)
~~~
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2011687/+subscriptions
References