Description of problem:
A vlan provider network is created with an IPv4 subnet and an IPv6 subnet (with slaac).
A router is created and connected to that external network.
A port is created on that network.
A VM instance is created using that port (both RHEL9.0 and centos-stream-9 have been used).

We can access the instance using the following command from the compute node where the instance is spawned (root password needs to be configured on the image):
podman exec -ituroot nova_virtqemud virsh console <instance>

The instance obtains its IPv4 address during boot. However, its eth0 doesn't have an IPv6 global address (it has IPv4 and IPv6 link-local addresses).

The following flow exists in the compute since the moment the instance was created:
[root@cmp-2-0 ~]# ovs-ofctl dump-flows br-int |  grep "icmp_type=133.*20.01.0d.b9"
 cookie=0xfd928287, duration=2858.181s, table=16, n_packets=1, n_bytes=62, idle_age=2301, priority=50,icmp6,reg14=0x1,metadata=0x3,ipv6_dst=ff02::2,nw_ttl=255,icmp_type=133,icmp_code=0 actions=controller(userdata=00.00.00.08.00.00.00.00.00.01.de.10.00.00.00.65.86.00.00.00.ff.00.ff.ff.00.00.00.00.00.00.00.00.01.01.fa.16.3e.80.75.0b.05.01.00.00.00.00.05.dc.03.04.40.c0.ff.ff.ff.ff.ff.ff.ff.ff.00.00.00.00.20.01.0d.b9.00.00.00.00.00.00.00.00.00.00.00.00,pause),resubmit(,17)  



The previous flow had n_packets=0 for several minutes and the icmpv6 packets captured on the VM showed that it sends periodically RS messages that are not replied (these packets were captured after the VM was booted and it got its IPv4 address via DHCP):
11:03:50.955536 fa:16:3e:87:56:3f > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: (flowlabel 0x320f8, hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::f816:3eff:fe87:563f > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 8
11:06:02.445531 fa:16:3e:87:56:3f > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: (flowlabel 0x320f8, hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::f816:3eff:fe87:563f > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 8


Finally, one of the RS messages is replied with an RA message and then the IPv6 global address is added to the VM's eth0:
11:10:24.285042 fa:16:3e:87:56:3f > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: (flowlabel 0x320f8, hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::f816:3eff:fe87:563f > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 8
11:10:24.287477 fa:16:3e:80:75:0b > fa:16:3e:87:56:3f, ethertype IPv6 (0x86dd), length 118: (flowlabel 0x320f8, hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::f816:3eff:fe80:750b > fe80::f816:3eff:fe87:563f: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 255, Flags [none], pref medium, router lifetime 65535s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): fa:16:3e:80:75:0b
          mtu option (5), length 8 (1):  1500
          prefix info option (3), length 32 (4): 2001:db9::/64, Flags [onlink, auto], valid time infinity, pref. time infinity



icmpv6 traffic was captured on the compute node where this VM was running and the unreplied RS messages were captured on the tap interface and on the br-vlan.107 interface - finally, the replied RS message and its corresponding RA were only captured on the tap interface.


Version-Release number of selected component (if applicable):
RHOS-17.1-RHEL-9-20221130.n.1

How reproducible:
very often it takes more than 2 minutes to obtain the IPv6 prefix - sometimes it takes 6+ minutes

Steps to Reproduce:
run this playbook: https://gitlab.cee.redhat.com/eolivare/bgp-playbooks-templates/-/blob/master/playbooks/frrempest_only_vlan_provider.yml
using the following command: ansible-playbook -i `ir workspace inventory` playbooks/frrempest_only_vlan_provider.yml -vv


Actual results:
the VM receives its IPv6 prefix in a reasonable amount of time


Expected results:
it takes too long for the VM to receive its IPv6 preffix and several RS messages are not replied