O flag is not enabled when ipv6_ra_mode is dhcpv6-stateful

[Yamato Tanaka]

* 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)
~~~

[Brian Haley (brian-haley)]

Hi,

Thanks for the bug.

So I think the code is operating properly based on my reading of the IPv6 RFC.

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

I guess we can do one of two things:

1) Change the docs to say we don't need to set O=1 based on the RFC.

2) Change the code to set it anyways, but still document it's unnecessary.

I would have to look at what radvd does in the second case since we don't want to cause any issues, either by having it complain or worse.

[Yamato Tanaka (yatanaka-1007)]

Hello Brian,
Thank you for answering my doubt.
RFC you provided really makes sense for me.

I guess modifying the document is more safe and reasonable.
I assume there is no problem even if O flag is 0 because no one has not taken care of this topic so far and this behavior complies with the RFC correctly.
I'll proceed with updating the document.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/877601

[OpenStack Infra (hudson-openstack)]

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 <email address hidden>
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

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 23.0.0.0b2 development milestone.