vsomeip-library - different behavior between IPv4 and IPv6 when using service discovery

Setup:

vsomeip 3.3.8
Two Xenomai machines (Debian 11) connected via network switch
"Mirrored services" on the two devices. Service 4433.2211 is offered and service 1234.5678 is requested on node 1. Node 2 does the opposite.

Observations:

Running the applications with IPv4 addresses creates the expected behavior. The two applications exchange data.
Running the same applications with IPv6 addresses AND deactivated service discovery AND hard coded IPv6 addresses of the respective clients runs successfully.It shows that my machines are capable to communicate using IPv6.
PROBLEM: Using active service discovery (without hard coded unicast addresses of the services), there is no communication between the two applications (note: Wireshark shows the service discovery communication)
- I noticed that Wireshark displays a ICMPv6 message where it says "Multicast Address Record Changed to exclude: ff0e::1". Which is something I do not understand, because I did not request to exclude the address.

Question

Does anyone know why the nodes do not communicate? Is there anything specific for IPv6 that I need to set?

In my opinion it should be somewhere outside the C++ application. It should be something related to my Xenomai network settings. Or the json configuration files

Appendix: json configuration files and log of node 1

My json file for node 1:

{
"unicast" : "4242::1",
"logging" :
{
"level" : "trace",
"console" : "true",
"file" : { "enable" : "true", "path" : "/usr/cppPlayground/requestResponse2DevicesIpv6/node1.log" },
"dlt" : "false"
},
"applications" :
[
{
"name" : "request-response",
"id" : "0x1"
}
],
"services" :
[
{
"service" : "0x4433",
"instance" : "0x2211",
"unreliable" : "30510"
}
],
"routing" : "request-response",
"service-discovery" :
{
"enable" : "true",
"multicast" : "ff0e::1",
"port" : "30490",
"protocol" : "udp",
"initial_delay_min" : "10",
"initial_delay_max" : "100",
"repetitions_base_delay" : "200",
"repetitions_max" : "10",
"ttl" : "3",
"cyclic_offer_delay" : "2000",
"request_response_delay" : "1500"
}
}

My json file for node 2:

{
"unicast" : "4242::2",
"logging" :
{
"level" : "trace",
"console" : "true",
"file" : { "enable" : "true", "path" : "/usr/CppPlayground/requestResponseMirrored2DevicesIpv6/node2.log" },
"dlt" : "false"
},
"applications" :
[
{
"name" : "request-response-mirrored",
"id" : "0x9"
}
],
"services" :
[
{
"service" : "0x1234",
"instance" : "0x5678",
"unreliable" : "30509"
}
],
"routing" : "request-response-mirrored",
"service-discovery" :
{
"enable" : "true",
"multicast" : "ff0e::1",
"port" : "30490",
"protocol" : "udp",
"initial_delay_min" : "10",
"initial_delay_max" : "100",
"repetitions_base_delay" : "200",
"repetitions_max" : "10",
"ttl" : "3",
"cyclic_offer_delay" : "2000",
"request_response_delay" : "1500"
}
}

The log file for node 1 (started AFTER node 2):

2023-09-15 15:35:21.279421 [info] Using configuration file: "vsomeip-local_IPv6.json".
2023-09-15 15:35:21.281261 [info] Parsed vsomeip configuration in 2ms
2023-09-15 15:35:21.281666 [info] Configuration module loaded.
2023-09-15 15:35:21.282017 [info] Initializing vsomeip (3.3.8) application "request-response".
2023-09-15 15:35:21.282568 [info] Instantiating routing manager [Host].
2023-09-15 15:35:21.283269 [info] create_routing_root: Routing root @ /tmp/vsomeip-0
2023-09-15 15:35:21.283987 [info] Service Discovery enabled. Trying to load module.
2023-09-15 15:35:21.285998 [info] Service Discovery module loaded.
2023-09-15 15:35:21.286556 [info] Application(request-response, 0001) is initialized (11, 100).
2023-09-15 15:35:21.287161 [info] Starting vsomeip application "request-response" (0001) using 2 threads I/O nice 255
2023-09-15 15:35:21.287993 [info] Client [0001] routes unicast:4242::1, prefix:24
2023-09-15 15:35:21.287908 [info] main dispatch thread id from application: 0001 (request-response) is: 7f6d7edde700 TID: 1378
2023-09-15 15:35:21.288016 [info] shutdown thread id from application: 0001 (request-response) is: 7f6d7e5dd700 TID: 1379
2023-09-15 15:35:21.289400 [info] Watchdog is disabled!
2023-09-15 15:35:21.290087 [info] REQUEST(0001): [1234.5678:255.4294967295]
2023-09-15 15:35:21.290180 [info] io thread id from application: 0001 (request-response) is: 7f6d7d5db700 TID: 1381
2023-09-15 15:35:21.290169 [info] io thread id from application: 0001 (request-response) is: 7f6d7fedcec0 TID: 1375
2023-09-15 15:35:21.290694 [info] create_local_server: Listening @ /tmp/vsomeip-1
2023-09-15 15:35:21.292821 [info] OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:21.293393 [info] vSomeIP 3.3.8 | (default)
2023-09-15 15:35:21.293815 [info] Network interface "eno1" state changed: up
2023-09-15 15:35:21.294766 [info] Route "ff00::/8 if: eno1 gw: n/a" state changed: up
2023-09-15 15:35:21.295200 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30490
2023-09-15 15:35:21.295432 [debug] **Joining to multicast group ff0e::1 from 4242::1**
2023-09-15 15:35:21.295805 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30510
2023-09-15 15:35:21.295976 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30490
2023-09-15 15:35:21.296000 [info] SOME/IP routing ready.
2023-09-15 15:35:22.293609 [info] OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:22.294419 [warning] routing_manager_impl::handle_local_offer_service: Application: 0001 is offering: [4433.2211.0.0] offered previously by itself.
2023-09-15 15:35:23.294958 [info] OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:23.295723 [warning] routing_manager_impl::handle_local_offer_service: Application: 0001 is offering: [4433.2211.0.0] offered previously by itself.
*[... all the same as the two messages before...]*
2023-09-15 15:35:29.039199 [info] STOP OFFER(0001): [4433.2211:0.0] (true)
2023-09-15 15:35:29.039906 [info] RELEASE(0001): [1234.5678]
2023-09-15 15:35:30.304243 [info] Stopping vsomeip application "request-response" (0001).

I did analogous steps for IPv6 as I performed for IPv4.

Route multicast address to the ethernet device: sudo ip -6 route add ff0e::1 dev eno1
Start the respective application on both nodes: env VSOMIP_CONFIGURATION...

This way, I was expecting the same behavior as with IPv4. Of course, I tried a lot of other stuff related to network configurations, but nothing to exciting differently than the mentioned approach.

Solution

It's a bug in vsomeip 3.3.8. It does not support service discovery with IPv6. A pull-request was opened some time ago. Unfortunately, the github search did not highlight the pull-request when I searched for relevant keywords...