SRT with IPv6

[lelegard]

Hi,

In the SRT API docs, it is mentioned that sockaddr structures can contain IPv4 or IPv6 addresses. Is there anything special to be taken care of in the creation of a SRT socket when it will be used with IPv6?

Specifically, the now obsolete function srt_socket() had an address family parameter AF_INET or AF_INET6, just like the BSD API socket() function. The new function srt_create_socket() does not mention the address family. This is of course easier but I wonder if there is some hidden constraint on IPv6. Any parameter to set prior to using IPv6 on that socket?

I noticed the following note in the doc for srt_bind: "When you bind an IPv6 wildcard address, note that the SRTO_IPV6ONLY option must be set on the socket explicitly to 1 or 0 prior to calling this function." So did I...

Is there anything else to take care of about IPv6?

NB: I am reviewing the TSDuck code base to make sure that it is compatible with IPv6. This question is part of that effort.

Thanks

[ethouris]

The reason why - in distinction to the BSD socket API - you don't specify the IP version when creating the SRT socket is that the internal UDP socket - which's creation does require specifying AF_INET or AF_INET6 - is created at the moment when the SRT socket is bound. Which of the IP version is used, it depends on the binding address. In case when you connect the socket without binding, the default binding uses the default address, but of the same family as the connection endpoint address. That's not only to make things easier, we had to do this because of the required API consistency with groups. In case of groups you don't specify the IP version because you can have IPv4 and IPv6 connections in the same group.

This IPV6ONLY option is necessary to be set explicitly because it decides about the range of binding address (I don't know why they did it trhis way - it could be easier if this was a field in sockaddr_in6), but this is provided as a socket option, while the default value isn't defined by the standard, and it can be even potentially modified in runtime. That's why you need to set it before binding to IPv6 address.

There is one thing that still isn't done correctly in SRT, but it touches upon only the file mode, or more precisely, all cases when you want to use the maximum possible capacity in the packets. The actual maximum payload size in a single packet is 1456, but this is true only for IPv4 - for IPv6 you have a limit of 1444 bytes, but SRT doesn't exactly enforce it. There's a PR to fix it, but it's still in the schedule.

That's the only problem I know is still not resolved. Many problems were reported before by our development teams some time ago, and they should be all fixed now.

[lelegard]

Thank you @ethouris for the detailed answer.

So, as far as I understand, there is only IPV6ONLY to care about on the application side.

About IPV6ONLY, I noticed that OpenBSD does not support it. More precisely, this is a read-only option (see man ip6 on an OpenBSD system). On OpenBSD, there is no mixed IPv4-IPv6 socket. IPV6ONLY is hard-coded to 1. Trying to change it results in an "invalid argument" error. I don't know how far SRT supports BSD systems but this may be an issue for mixed IPv4-IPv6 groups since you have to create two separate sockets.

I am not sure if anyone uses OpenBSD in the video/TV/streaming industry. I know that FreeBSD is widely used by a large operator but FreeBSD is the only BSD system that works well, at least in all requirements of my TSDuck project. OpenBSD, NetBSD and DragonFlyBSD all suffer from obsolete or weird stuff.