OME does not appear to work with IPv6 IPs

[json-m]

Describe the bug Attempting to bind to IPv6 only addresses, or including IPv6 addresses seems to fail

To Reproduce Steps to reproduce the behavior:

1. Set <IP>*</IP> in your Server.xml
2. See below:

video-dev:~/ome# docker run -d  --rm --net=host -v /root/ome/Server.xml:/opt/ovenmediaengine/bin/origin_conf/Server.xml ome
4b5142d6f72ba68854c37e975206aaebf3dc8c60bffc1cb83196eeae46528ac4
video-dev:~/ome# netstat -pnlt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN      23385/OvenMediaEngi
tcp        0      0 0.0.0.0:1935            0.0.0.0:*               LISTEN      23385/OvenMediaEngi
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      23385/OvenMediaEngi
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2629/sshd
tcp        0      0 0.0.0.0:3333            0.0.0.0:*               LISTEN      23385/OvenMediaEngi
tcp        0      0 :::22                   :::*                    LISTEN      2629/sshd
video-dev:~/ome# grep IP Server.xml
        <!-- Specify IP address to bind (* means all IPs) -->
        <IP>*</IP>

You can see here OME only binds to all for IPv4 via 0.0.0.0. There is no :: bindings.

I attempted forcing my local v6 address, and trying :: by setting manually in <IP> field in config, but both failed with error included below.

Expected behavior OME would bind to IPv6 addresses

Logs

[2020-05-04 05:25:37.777] E 1 Socket | socket.cpp:533  | [0x55e71268e1b0] [#4] Could not bind to [v6]2601:280:c100:2af:215:5dff:XXXX:XXXX:1935 (-1)
[2020-05-04 05:25:37.777] E 1 Socket | socket.cpp:1041 | [#258] Invalid state: 1 (expected: _state(1) == SocketState::Listening)
[2020-05-04 05:25:37.777] E 1 RtmpProvider | rtmp_server.cpp:33   | Could not initialize phyiscal port for RTMP server: [v6]2601:280:c100:2af:215:5dff:XXXX:XXXX:1935
[2020-05-04 05:25:37.777] E 1 RtmpProvider | rtmp_provider.cpp:27   | An error occurred while creating RtmpProvider
[2020-05-04 05:25:37.777] E 1 OvenMediaEngine | main.cpp:148  | Failed to initializeRTMP Provider module

I censored address above.

Server (please complete the following information):

• OS: Alpine Linux v3.11
• OvenMediaEngine Version: latest dev commit as of this issue
• Branch: dev

This is run in a docker container using --net=host, I have verified I can see the v6 address from inside the container.

[json-m]

Server config attached

Server.txt

[getroot]

OME does not yet support IPV6. We will apply soon in the future.

[alex-jhones]

I experience the same symptoms and ask about it. What is the difference between IPV6 and IPV4 for OME internal processing? When testing with a mobile phone, it seems that the old phone is connected to IPV4 and the new 5G phone is connected to IPV6, which eventually affects the connection coverage. Chrome's web oven player does not have this problem, but it appears when implemented in the Android Client environment in the same connection order. If so, is the web oven player always connected to IPV4? I'm curious what is the difference between Signaling in Server and Client internally and what is considered in IPV6 implementation in the future.

[getroot]

Are new 5G phones really using only IPV6? I think 5G phones also support IPV4. Otherwise, you won't be able to access most websites using that phone. IPV6 is still rarely used in the real world. Isn't it? If you think my experience is insufficient, please tell me.

So, the priority for IPV6 support is not high for us. Of course we will support it. For IPV4 and IPV6, there is no significant difference at the socket level. It will be supported by updating our ov::Socket module.

[json-m]

Are new 5G phones really using only IPV6? I think 5G phones also support IPV4.

I am not sure about 5G, but in 4G (LTE specifically) the supporting infrastructure requires IPv6 and supports IPv4.

I did some quick searches, but didn't really see any discussion about something similar for 5G. Might exist, but 5G is still pretty new so there could just not be any discussion on it. I don't have access to any 5G devices (or 5G coverage) to test, either.

For LTE, in the US at least, you are typically either on a dualstack (ie. AT&T) or a CG-NAT (ie. T-Mobile) deployment. T-Mobile has talked about their experience with an IPv6 only network at NANOG, https://pc.nanog.org/static/published/meetings/NANOG73/1645/20180625_Lagerholm_T-Mobile_S_Journey_To_v1.pdf

Otherwise, you won't be able to access most websites using that phone. IPV6 is still rarely used in the real world. Isn't it? If you think my experience is insufficient, please tell me.

Even under CG-NAT scenarios you would be able to access the website, but these NAT gateways are often under heavy load and sometimes do not have great performance.

As far as IPv6 usage, in my own data I see about 30-40% of traffic as being IPv6. On mobile focused applications, this has reached as high as nearly 60%. Google's own tracking of IPv6 deployment largely supports this as well, https://www.google.com/intl/en/ipv6/statistics.html.

On availability, corporate networks typically don't see any IPv6 support, but many residential ISPs will give you native IPv6 if you have a modern modem/router.

Currently a large blocker for more widespread use of IPv6 is actually enablement/deployment on the service side. Github for example does not support IPv6 at all, despite having and announcing IPv6 address space.

[jcdmacleod]

You are likely seeing IPv4 over IPv6, many EU networks are doing this now. It is now standard from the largest cable provider in the EU. You get an IPv6 address and any IPv4 is CGNAT - NAT64. Similar to what you see in mobile networks, but instead of you getting an RFC 1918 address, you get an IPv6 address.

Most modern OS’s preference IPv6 over IPv4 and if A and AAAA records exist, the host speaks IPv6 but the service does not, it will fail.

IPv6 adoption varies by country and traffic type. However it exists and it passes a fair amount of traffic as has already been discussed.

At the IX ports we manage for clients nearly all IPv6 is CDN traffic. Therefore having a video application that does not speak IPv6 is very short sighted in my opinion. I also know networks that will only deploy an application if it is dual-stack capable.

[GregOriol]

I'd like to +1 this task, because almost all servers/instances now have IPv6 in addition to IPv4, and it is not very clear why one should omit setting an AAAA record because of this OME specificity

At least, it should probably be added as a strong warning in the docs

[getroot]

@GregOriol

If the domain has only IPv6 addresses applied, then the packets will definitely not reach the OME. It is difficult to use IPv6 in my development environment, so I am wondering how to support this IPv6... I will think about this a little more.

[GregOriol]

Would it be possible to sponsor such a task?

[getroot]

@GregOriol Thanks for the good suggestion. We welcome financial support for the maintenance of the OME project. However, sponsorships are not accepted on the condition that the task must be completed by the specified time. Because it's hard for us to promise that.

Should you use AAAA records? If so, could you please share the case? If it affects a lot of people, we can increase the priority of the IPv6 support task.

Most Korean ISPs do not yet offer IPv6 addresses. So I've never really thought deeply about IPv6. Maybe I should think about it from now on.

[GregOriol]

IPv6 is indeed not very common at the user level, but it seems to be getting more and more now, and even more on mobile networks (4G/5G). I do only know 1 out of 10 home networks that have it right now in France, but all 4G operators seem to use it. Enterprise networks seem to have it more often too.

The main issue for me is for sysadmins who configure OME and servers: when you get a server for it, either a cloud instance or a baremetal, you always get IPv4+IPv6 now, so you naturally set up A and AAAA records for it. But with an AAAA record and on a IPv6 ready network, this breaks the access to the stream. You have to disable the AAAA record to make the IPv6 devices switch back to IPv4.

I don't know how you could develop this feature without having an IPv6 network yourself though, maybe with some remote browser service (browserstack maybe?) or via commandline from one server to another...

[command-tab]

Happy to make available a cloud host with IPv6 records if that would help with development or testing.

[getroot]

https://github.com/AirenSoft/OvenMediaEngine/issues/449#issuecomment-1014081495

According to basisbit's analysis, network performance is unreliable in DualStack Lite and CGNAT environments. I didn't expect to have this kind of problem in a global environment (I haven't experienced it yet, as most of Korea is an IPv4-only network), and if IPv6 support can solve this problem, I will make this task a top priority.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[GregOriol]

Please do not close the issue, it should be taken into account some day!

[json-m]

for anyone watching this issue, https://github.com/AirenSoft/OvenMediaEngine/issues/1044 was posted - thank you OME team!