https://bugs.kde.org/show_bug.cgi?id=515707

--- Comment #11 from Kiril Vladimirov <[email protected]> ---
(In reply to Matt from comment #10)
> One thing I wanted to flag: in the duplicate bug 515566, Linus Dierheimer
> suspects their dormitory subnet (100.122.0.0/16) falls within the
> 100.64.0.0/10 range being allowed here. If so, that's a shared multi-tenant
> network. RFC 6598 explicitly distinguishes this range from RFC 1918 private
> address space — it was allocated for carrier-grade NAT where multiple
> subscribers share the same address block.

In theory yes. Not sure whether it's really used at all by carriers these days,
though. I've never seen them used outside of corporate networks and lately
Tailscale.

(In reply to Matt from comment #10)
> As zocker.network suggested in comment 5, would it make sense to have this
> be a user-facing toggle, off by default? That would cover VPN and CGNAT
> users who need it without broadening the filter for everyone else.

I feel that this setting will be tedious to explain. "Check this if you're
using Tailscale"?
Love the idea, though as it would make the tailnet feel really like local
network as before.

(In reply to Matt from comment #10)
> knyipab also raised an interesting point in comment 2 — the current behavior
> discards packets from addresses the user has explicitly entered via "Add
> device by IP." There might be a narrower fix there, though I don't know if
> the code architecture makes that straightforward.

This one is easy to be implemented. The custom device list is easily accessible
where this check happens. Downsides:

- Pairing new devices over Tailscale would be tedious. The device simply
disappears when you're using tailscale and it's not obvious that adding it
manually by IP would work
- Tailscale also has dns resolving inside the tailnet (e.g.
desktop.tail123456.ts.net). If we want to support devices added by hostnames in
the custom device list, that would make things a bit more tedious

I still believe that we should just treat 100.64.0.0/10 as a local network,
given that the real world treats it that way these days. Said that, if
maintainers decide on any of the other two suggested ideas, I'm willing to
submit a MR implementing them.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to