Up until MariaDB 10.3.28, `wsrep_sst_receive_address`'s behaviour was not correct. This configuration on MariaDB 10.3.28:

wsrep_sst_receive_address = http-jda02.dec.ha.cyberfusion.cloud:4444

wsrep_cluster_address="gcomm://[fc00:b6d:cfc:956::8],[fc00:b6d:cfc:956::11],[fc00:b6d:cfc:956::12]"

wsrep_provider_options = "gmcast.listen_addr=tcp://[::]:4567;ist.recv_addr=[fc00:b6d:cfc:956::11]:4568"

wsrep_sst_receive_address = "http-jda02.dec.ha.cyberfusion.cloud:4444"

... causes rsync to bind to :: and 0.0.0.0, while I would've expected it to bind to `fc00:b6d:cfc:956::11` (the IPv6 address that http-jda02.dec.ha.cyberfusion.cloud resolves to).

Starting from MariaDB 10.3.30, this same configuration causes rsync to bind to to `127.0.1.1:4444`, which makes sense, because my `/etc/hosts` contains:

127.0.0.1 localhost.localdomain localhost

127.0.1.1	http-jda02.dec.ha.cyberfusion.cloud http-jda02

I found commit 7e8a89387b which changed a lot of SST-related things, so I guess it's likely that this commit introduced the behaviour change.

Setting the local hostname to resolve to an IP address in 127.0.0.1/8 is quite common, so while this behaviour is correct, I'm not sure it's practical. I think I'll change `wsrep_sst_receive_address` to the node's IPv6 address for now (I didn't do that because of https://jira.mariadb.org/browse/MDEV-26171, which the mentioned commit did fix according to the changelog).