Like the title says, IPv6 subnets are currently not supported on those fields, with logs throwing “ERROR - Error parsing allowedNetworks ‘2a01:cb08:7c6:dc00::56’: Invalid argument” when IPv6 subnet is present:
As IPv6 is now pretty widespread, it would be nice if we could set IPv6 in those fields, for us with IPv6 at home.
I’m not even sure if it’s a bug or a feature, given that the “/” is stripped in the log, it might be a parsing failure more than a missing feature.
There’s a lot of things that Plex needs to do with IPv6 to get the same functionality as IPv4. Plex doesn’t even push the IPv6 address of PMS up to the Plex servers so that clients can find it through the API.
Can we do anything to help you on this feature?
That looks pretty simple to add this address family to the LAN vs WAN evaluation as the IPv6 family stack is already implemented.
Also, please note that all Apple devices prefer IPv6 when available (and this is a good behavior - enforced by Apple) so there are mismatches from there network posture evaluation.
While I know Apple devices prefer V6, I have 5 here at the house and they’re all running very happily on my V4 lan. Also, those remote from me are using IPv4 without issue.
Are you in a situation where the ISP is IPv6-only?
(Most routers will do 6-4 conversion for you. I’m with Comcast and dual-stack as a result. Remote inbounds are v6 and v4.
I do understand your request.
If I can get a number of “Likes” on this post (SORRY for this), It’ll help me prioritize it with Engineering management as NEEDED
My collection are mainly composed of 4K remuxes blu-rays so I have caped the remote bandwith to 40Mb/s and PMS is transcoding outside (I have a GPU, hw accelaration is working great, I am fine with that).
Sadly my Apple devices in the LAN contact Plex via IPv6 and are considered as outside so the bandwidth is restricted.
(As a network engineer, I would love to have an IPv6 only network and NAT64 but I am not in IPv6 only scenario to be honest.)
So my issue is really focused on LAN devices considered as outside so badly bandwith caped.
YES, I agree, Proper IPv6 support EVERYWHERE is what’s needed. That’s not in dispute. I am willing to help bridge that gap for now.
My Apple devices are, because of my LAN/WiFi configration are IPv4 based. The router does the v4 - v6 conversion as required. The iPad is showing me link-local addresses only. (DHCPv6 is currently disabled)
My provider favors IPv4 but does provide IPv6 (Comcast).
I do not enable DHCPv6 in the PfSense. The tablet, AppleTV, and iPhone are all IPv4. Apple is truly agnostic.
If you’re getting the “Remote” indication for your LAN, then your subnet masking is wrong for the subnets you’ve divided things into.
– If spanning 4 subnets (x.x.0.x → x.x.3.x) then you need a /22 on the PMS host so PMS sees it as local . Subnet mask is critical here.
( I have 3 subnets here and I must be very careful to get netmasking right so PMS doesn’t get stupid on me )
Plex never supported V6
It’s not a bug report
It is a feature request – One that’s become QUITE urgent as the years passed.
There is a bug, a bad bug in there.
Local addresses without auth: <space>192.168.5.0/255.255.255.0
Leading space – which is almost impossible to see, will break the whole thing.
I’m trying to get them to remove all white space before accepting the string in PMS.
Currently, it blindly accepts it from Plex/web then the world breaks.
I’m not sure if I understood everything you listed, but if so, I’m quite sure you’re not doing IPv6 at all, or at least, not the way you think.
There’s no “v4-v6 conversion”. You could NAT, but you cannot NAT IPv6 addresses to IPv4, mostly because there’s not enough space in IPv4 to cover IPv6 addresses. The other way around works and is called NAT64. Basically the DNS server encapsulates IPv4 addresses in IPv6 addresses, and the router does some magic to trick the client into thinking he’s talking to IPv6. But that’s not really the topic here.
The ISPs do not decide which IP address family is proritized. The client does (happy eyeballs) in a dual-stack environment. Basically it tries to speak using IPv6 first but fallback very, very quickly to IPv4 if the IPv6 does not seem to respond, which makes it almost invisible to the user.
Do you enable SLAAC (router advertisements) then ? If not, then you’re not doing IPv6 at all, because your clients don’t have any IPv6 allocated besides the link-locale, which is not usable through a router. You might have an IPv6 at your gateway, but then only the traffic originated by the gateway itself is doing IPv6, if you clients have only IPv4 but no GUA IPv6 addresses (link-locales does not matter).
What he means is that IPv6 is always considered “Remote”, because there’s no way currently to add an IPv6 range as “Local”, therefore all IPv6 traffic is considered remote (that’s why I opened this topic in the first place ).
I’m not sure of what you mean by that.
Speaking to IPv6 GUA means a bit higher latency than IPv4, but in an L2 network, we’re talking nanoseconds here, nothing that matters.
Bandwidth-side, there’s only a 20-bytes penalty per packet in the worst case scenario (MTU 1500, MSS 1460 for IPv6, vs 1480 for IPv4). Most packets are not 1500-bytes anyway, so again, nothing significant.
BUT when you’re going to the internet, not having NAT matters, in a significant way.
If you have proper IPv6 in your LAN, then your router does not need to NAT for IPv6, and NAT is a (very) costly operation for a router. This difference is very significant, and there’s clearly an advantage running IPv6 here.
Finally, regarding the adoption, it’s true that IPv6 is not widespread is should be, but the adoption is accelerating a lot mainly due to the fact that RIPE, APNIC and ARIN (Europe, US and Asia internet registries) exhausted their IPv4 address spaces. They reclaim some, but far less than the demand, and AfriNIC is the only RIR with some IPv4 addresses left.
Thank you for explaining the missing pieces — AND – my not writing clearly.
Please accept my apology.
I see this from my IPv4 workstation.
root@lizum:/etc/netplan# ping google.com
PING google.com(lga34s40-in-x0e.1e100.net (2607:f8b0:4006:824::200e)) 56 data bytes
64 bytes from lga34s40-in-x0e.1e100.net (2607:f8b0:4006:824::200e): icmp_seq=1 ttl=114 time=34.9 ms
64 bytes from lga34s40-in-x0e.1e100.net (2607:f8b0:4006:824::200e): icmp_seq=2 ttl=114 time=30.1 ms
64 bytes from lga34s40-in-x0e.1e100.net (2607:f8b0:4006:824::200e): icmp_seq=3 ttl=114 time=32.8 ms
64 bytes from lga34s40-in-x0e.1e100.net (2607:f8b0:4006:824::200e): icmp_seq=4 ttl=114 time=32.5 ms
– Who did the v4 → v6 here? The workstation or the PfSense DNS server (which has both IPv4 and IPv6) ?
Not needing NAT when going outside your router – YES it does matter a great deal. NAT is slower by definition. I’ve not found a way to quantify / capture it.
– I have done IPv4 speed tests vs IPv6 speed tests and the IPv4 speed tests are faster. Is the test rigged ? Am I misreading?
Lastly, and maybe (likely) this is me being lazy, my PfSense runs on an i5-9300H GhostCanyon with a X710-T2L 10GbE nic in it. Comcast provides up to 2.5 GbE from the current RPHY connection with XB8 modem which I do saturate consistently.
Speedtest by Ookla
Server: Comcast - New Castle, DE (id = 9840)
ISP: Comcast Cable
Latency: 29.68 ms (1.86 ms jitter)
Download: 2280.74 Mbps (data used: 4.0 GB)
Upload: 311.41 Mbps (data used: 545.2 MB)
Packet Loss: Not available.
Result URL: https://www.speedtest.net/result/xxx
[24.03-RELEASE][admin@pfsense]/root:
Complete IPv6 support in PMS
I will try to write up a new request w/justification and see how much interest I can gain.
The biggest challenges I’ve had are:
Old team had no interest (or no knowledge) in completing it
New team is a fraction of the size but is getting a lot of the backlog cleared
– Transcoding improvements are one indication of progress made.
If I can get it accepted and into the schedule, it’ll happen.
).