Add IPv6 Support

[gmacarthur]

Tracearr Version

supervised-v1.4.28

Deployment Method

Docker - Supervised (all-in-one container)

Host System

Unraid 7.2.7

Connected Media Servers

• Plex
• Jellyfin
• Emby
• None configured yet

Media Server Version(s)

No response

Affected Area

Rules/Violations

Bug Description

I've noticed what appear to be two related issues, my sister's ISP uses IPv6, and the CIDR and Unique IP matching in rules doesn't work.

IPv6 CIDR matching

The IP Range rule does not appear to match IPv6 CIDR ranges. IE, adding the allow rule: 2001:db8:1234:5678::/64 does not match an address within that subnet, such as: 2001:db8:1234:5678:abcd:1234:5678:9abc The rule still triggers instead of treating the address as allowed.

Unique IP detection

The Unique IPs rule appears to compare the full IPv6 address. Devices on the same network have different IPv6 addresses, so they are counted as unique IPs, resulting in false positives.

Steps to Reproduce

1. Create an IP Range rule using an IPv6 CIDR.
2. Stream from a device within that range.
3. The rule does not match.
4. Stream from two devices on the same IPv6 network.
5. Unique IPs treats them as separate IPs.

Docker Compose / Run Command

Relevant Logs

Was this working before?

None

Additional Context

No response

Checklist

• This isn't a duplicate of an existing issue
• Version number filled in above
• Docker compose/run command included (if applicable)
• I have searched the docs at https://docs.tracearr.com

[gmacarthur]

Following up from the PR, I'd like to discuss the approach for IPv6 support.

The main thing I was trying to solve is that Unique IPs currently compares exact IP addresses. That works well for IPv4, but starts to fall over in IPv6, as devices in the same household have different addresses. Same as, IP Range only supports IPv4 today, so IPv6 users can't use your IP based rules.

The approach I prototyped;

• Add IPv6 CIDR support to IP Range, leaving existing IPv4 behaviour unchanged
• When Unique IPs is enabled, compare locations rather than raw addresses:
  • all private/LAN addresses = one household
  • public IPv4 = one location per address
  • public IPv6 = same /64 = one household
• Reuse the same logic for Unique IPs in Window
• On update: existing rules with Unique IPs off stay the same. Rules that already have Unique IPs on would pick up the household behaviour. IPv4 IP Range rules are unchanged; this only adds IPv6 support.

I'm not attached to that implementation if there's a better way of doing it. It was just the approach that made the most sense to me.

A few things I'd like thoughts on, if you'd like to proceed with this:

1. Should household detection be part of Unique IPs?
   Should all LAN addresses count as one location so Unique IPs behaves as users would expect, while the Local Network filter remains the option for ignoring LAN traffic entirely? Or should users need to stack filters to achieve this by design?

2. How should Unique IPs count?
   Should it count distinct locations, or keep the current "drop streams matching this session, then count the remaining" behaviour?

3. What should the default be?
   For new Concurrent Stream Limit rules, should Unique IPs stay off by default, or be enabled in the default template?

4. How should LAN be grouped?
   For Unique IPs, should all private IPv4 addresses count as one household, or only addresses on the same subnet (IE same /24)?

5. What's the right IPv6 boundary?
   Is /64 the right default for a household, or something else (or be config changeable)?

Thank you :D

[connorgallopo]

First off, appreciate you opening this up properly and thinking through the design.

The main thing I'd do is shrink it down. Your proposal is really two changes bundled:

1. Make IPv6 actually work - IPv6 CIDR in IP Range, and compare IPv6 by /64 in Unique IPs
2. Change how LAN is treated - all private addresses = one household

Part 1 is totally safe. For IPv4, comparing "by network" is the same as comparing the address, so nothing changes for existing IPv4 rules. Only IPv6 changes, and we get IPV6 Support. Part 2 changes behavior for existing IPv4 users and opens up all those questions you listed. I'd just drop part 2 from this PR.

So for this one:

• Add isIpInCidr with v4 + v6 (BlockList is the right call). One thing to add - unmap v4-mapped addresses like ::ffff:1.2.3.4 to plain v4 before matching, otherwise a dual-stack client silently fails a v4 CIDR rule. Worth a test.
• Add a small toNetworkKey(ip) helper - v4 returns the address as-is, v6 masks to /64. Hardcode /64 for now.
• Use that helper everywhere IPs already get compared (Unique IPs, Unique IPs in Window, and the same-IP exclude on Concurrent Streams) so it's consistent.
• No config field, no UI, no template/default changes, no LAN grouping.

That last bit is the big win - dropping the configurable prefix kills the schema change, the UI, and all 40 translation files, so it's way easier to review and won't rot with merge conflicts. /64 fixed is the right default anyway, it's the smallest block a LAN is guaranteed and it handles SLAAC / privacy extensions / DHCPv6 all the same since they just change the low 64 bits.

[gmacarthur]

Opened a PR with the Part 1 approach you suggested: #935, thanks for the help 😃