IPv6 does not require you to open your machine to the Internet, even without making use of a NAT. Sure you get an IP that’s valid on the whole internet, but that doesn’t mean that anyone can send you traffic.

Are these restrictions set out by the ISP or the dorm?

If you don’t do business with the ISP, then you don’t have to agree to and follow their terms.

So as long as the dorms doesn’t have rules against setting up your own WiFi, then you should be well within your rights to purchase an Internet connection from another provider, but since you are likely not allowed to get your own line installed, you are probably restricted to ISPs that provide a service over the cellular network.

Of course using a cellular connection will give you worse latencies for online games, but at least you can have your own WiFi with low latency for your VR.

If you want to be nice, you could then run as much of your Internet network over ethernet as possible, so you congest the air waves as little as possible, possibly only running the VR headset over WiFi, and maybe even only enabling the WiFi radio when you want to play VR. If all your WiFi devices support 5GHz, you might also completely disable your 2.4GHz WiFi, to leave the most congested frequencies alone.

To lower the chance of someone complaining about your WiFi, you should configure it as a “hidden network”, such that it doesn’t broadcast an SSID, and therefore doesn’t show up when people are looking for WiFi networks to connect to.

In case of YouTube you can actually dump the link into VLC, and it will happily buffer the whole video while paused. This probably works with other sites, but I have only tested YouTube.

Alternatively you can of course just download the video with yt-dlp, and then play it locally

I really don’t see much benefit to running two clusters.

I’m also running single clusters with multiple ingress controllers both at home and at work.

If you are concerned with blast radius, you should probably first look into setting up Network Policies to ensure that pods can’t talk to things they shouldn’t.

There is of course still the risk of something escaping the container, but the risk is rather low in comparison. There are options out there for hardening the container runtime further.

You might also look into adding things that can monitor the cluster for intrusions or prevent them. Stuff like running CrowdSec on your ingresses, and using Falco to watch for various malicious behaviour.

Even if it does, do they actually read it?

The whole point of NixOS is that it’s “immutable” and “declarative”.

In essence this means that you store the entire system configuration in a bunch of text files in a single directory. So your bootloader configuration, all your installed packages, every system service, every filesystem mounts, and even your partition layout and dotfiles, all of it in a common shared configuration.

There’s even a concept called flakes, which lock the specific version of everything, so if you copy all your config to another computer (or reinstall), then applying the config will restore every system configuration to exactly that state. So if you like how you configured your machine, and want another machine exactly like it, you just copy all your configuration to the other machine, and run the nixos-rebuild command. Now the two machines are configured exactly identically, all the same package, all the same services, all the same configurations, even all the same versions if you make use of flakes.

It also means that you can reason about your entire system setup just by looking at those configs. Is that piece of config in the files? Then that’s how your system is configured. If that piece of config isn’t there, then that is not how your system is configured.

Want to install an application, just add it to the list in your config, and run the nixos-rebuild command. Now you have that installed. Don’t want it anymore? Just remove it from the list, and rerun nixos-rebuild.

On top of that NixOS stores every generation of your config, so even if you break something, you just restart and pick the previous config generation, and your system starts up exactly as it was before you broke it, and you can go and resolve the issue in the config that broke your system.

If you’ve ever done any programming, and made use of a dependency management tool that stores a dependency lock file, this is very similar, but for your entire operating system.

If you’ve ever managed infrastructure via Terraform, then this feels like that, but for your entire system configuration.