XMPP Service Operators - 2024-11-15

i run a xmpp server with only ipv6 address,and it's surprise that many other servers have ipv6 surport too

We're getting there 🙂

I am always surprised when I see a service not having v6.

(In)famous example: github

I try to be ipv6 first.

Stole Martin's idea of an ipv6 only srv record with higher priority 😀

^5

actually working on improving IPv6 support in Openfire right now (although it should be mostly working already). If I get my changes online, I'd love for you to give it a try, yuki!

Menel/Martin: isn't that what 'happy eyeballs' should do for you? It's supported by Prosody, if I'm not mistaken. It's one of the things I'm building in Openfire. Unsure about other servers.

> actually working on improving IPv6 support in Openfire right now (although it should be mostly working already). If I get my changes online, I'd love for you to give it a try, yuki! you know what? I use openfire and it runs well on a windows machine

Sweet! Well, more IPv6 goodies are on their way to you then :)

we will see

Isn't happy eyeballs about connecting to v4/v6 simultaneously and using whatever succeeds first?

Guus: the srv records are for other servers (and clients) connecting to me. The outgoing stuff is using happy eyeballs, if I understand correctly.

Martin, happy eyeballs does that, but explicitly staggers the start of each simultaneous connection attempt, and tells you to start with the 'preferred family' (defaults to IPv6) to give that the best chance to win. On top of that, it tells you to _wait_ (for a brief moment) for a connection attempt to your preferred family to succeed, in case an attempt for the other family connects sooner. Happy Eyeballs motivation is very much to have a quick _IPv6_ connection (as opposed to having a quick (any) connection) being setup.

Menel, you're right. Giving your IPv6 records a higher priority _should_ make remote entities first exhaust connection attempts over that. This may be your intended goal, but the drawback is that, if IPv6 connectivity is failing for some reason (which may be out of control of both you as well as the remote peer), then establishing the connection will involve quite a bit of time (network timeouts, etc). That directly translates to very poor end-user UX.

If I ever notice issues with that, I will change that.

None of it is end-of-the-world type of issues, but if your goal is to prefer IPv6 connectivity (without making people's life that can't use IPv6 more difficult, causing them to wave angry fists at IPv6), I'd advice to use Happy Eyeballs _instead of_ playing with DNS SRV properties.

That does require the remote entities using a happy eyeballs algorithm, of course, which is not something you can control

Yeah, all supported Prosody versions have happy eyeballs these days

What's the point of preferring v6 over v4?

I still want to point out that happy eyeballs on my machine is unrelated to my srv records that apply to _others_ connecting to me

Holger: it is expected to be more efficient and quick to set up and use, mostly because of the lack of need for stuff like NATs etc.

Menel: that's true, but if the others use software that can use happy eyeballs, then your SRV records could negate any benefits that that would give them.

For c2s it helps me to not use sslh bu still having tcp port 443 for xmpp clients and also a Webserver on that port (with another ip) Because nearly unlimited ipv6 is cheap, and even one ipv4 is expensive (for me) ✏

Guus, Menel: Yes but the scenario is communication between two dual-stack peers, no? I.e. the v4 hacks are set up on both sides already?

Holger: where I said 'setup' I meant "establish the connection" not "configure the network infra". Even if the hacks are already available, it could be desirable to not have to use them. They do have downsides, after all.

I see. Yes I do get the point of avoiding e.g. sslh for incoming c2s.