It appears only RFC1918 address ranges are included as “private” networks. I, and it appears several other Plex users have begun using more recent additions to the “private, non-routable addresses ranges” provided by RFC5735.
In my case, I’ve had to completely re-ip my entire network 3 times now due to VPN address range collisions with the companies I work for (and have worked for). 10.0.0.0/8 is nearly always chosen by large corporations for their internal network. More recently I’ve been forced off of 192.168.0.0/16 by labs within the corporate network that are being routed by other non-routable networks (don’t get me started). 172.16.0.0/12 holds the default range for Docker, which I’m now finding collisions for. Not by Docker itself, but for presumed test equipment for containers.
A few months back I put in a lot of research looking for an esoteric private IP address space that will at least give me a few years before I have to re-IP again. Judging from the forum search for ‘198.18’, I found 5 other posts of users also in this address space.
RFC5735 gives a list of “special use” address ranges, but not all of them are suitable for a “private address range”. Of note “reserved for future use” and Multicast are in there, which obviously are not suitable for any equipment. However, there are 4 networks TEST-NET-1,2,3 and RFC2544’s benchmark testing 198.18.0.0/15. The 3 TEST-NET ranges, while I would argue should be added as “private” ranges to plex’s whitelist, are not worth me fighting for: They’re only /24.
The benchmark test network though is a very large 198.18.0.0/15 that’s more attractive to us DIY and homelab types. This network is “made to minimize the chance of conflict in case a testing device were to be accidentally connected to part of the Internet” (C.2.2 RFC2544) and assigned by IANA as private.
I would like to invite @franckpicard@dlasher@jpalmerlee@julez who it appear have all had the same issues as I with this network not being whitelisted. Relevant posts:
I disagree. Each of those ranges has a specific purpose.
Adding additional bogon/martian/squatter/cowboy ranges to Plex would be inappropriate. Plex should not codify nonstandard use of reserved/allocated/assigned space.
For some networks it would be great if Plex didn’t hardcode ranges. It would be nice if the RFC1918 ranges were the default, but could be edited. (I also understand why Plex has made the current choice.)
The entire RFC1918/5735 range has a purpose. Exemption from being used on the public internet. While some ranges (169.254 or multicast ranges) will potentially cause network issues for a user, nothing else in that range will. It’s behind your own firewalls, off the internet.
Plex would in no way be “blessing” or encouraging the use of the space, rather they would be acknowledging that RFC’s change, and updates have been made.
Precisely. Either make them editable, or include the entire range from the most current RFC, which you can read below:
I say this as someone who has regularly attended IETF/ARIN/etc meetings: there’s no technically valid reason I can think of to exempt additional “private” ranges from being used by a product primarily LAN consumed.
There aren’t any additional “private” ranges. RFC1918 continues to describe the private ranges for local network assignment and use.
The various other designated ranges all have specific designated purposes, and it would be inappropriate for Plex to treat them as synonyms for “private”.
RFC2544 continues to describe the purpose of the (weird) “benchmarking” range.
Given that Plex is a software application, not an internet governing agency, it’s inappropriate for Plex to define whether a range is usable on a LAN or not, it’s not their responsibility. They started with the (3) blocks that everybody knows from RFC-1918 (from 1996). The internet changes, RFC’s get updated, we now have RFC-6890, time to update to include the rest.
In a world that continues to consume IP addresses at a record pace, applications that live on private LAN space, are allowed to use any IP address range within the very clearly defined “Special Purpose Addresses”. Any internet service provider worth their salt already has a BOGON ACL, and is either discard routing, or just dropping, any traffic to/from those addresses.
It is a reasonable request that Plex not block addresses in the RFC-6890 space from being used as LAN addresses in their application.
Agreed! That’s why they’re following the very mature standard.
I’ll say again that I’m a fan of making it a hidden config option.
Some of us have genuine real public routable IPv4 addresses … and that’s part of why I’m so mad about address mis-use. When a random ISP in New Zealand chooses to use your duly-assigned IP addresses for “internal” purposes, it really breaks stuff.
Been there, had it happen. I remember well a very large NSP who used 2.x.x.x as their internal space because at the time, nobody else did. What a massive and painful project as soon as the 2…x.x.x space started being allocated out.
Agreed - it’s perfect to be tucked in the “ADVANCED” sections of the server config.
I appreciate the added context @Volts provides and I agree any potential for a subnet to be reallocated would disqualify it from consideration. So far 198.18.0.0/15 is still a good candidate as the landscape for opening this up would be akin to making 192.168.0.0/16 allocatable - it’s just not gonna happen.
Just a reminder that RFC-6890 is from April 2013. Fairly “mature”
BOGON lists exist for a reason : Bogon IP Address Ranges - IPinfo.io - they are actively filtered from the public internet, and will never be (as of 2025) routable addresses. PERFECT for the LAN.
How about it Plex Devs? Time to add the rest of the RFC-1918/2544/6890/8190 space to allowable IP ranges? Give us an “advanced” option to enable/disable specific blocks?
