In IPv6 world you wouldn't get 2001::/112, you'd get 2001:1234:5678:90ab::/48. So your building might actually be at best something like 2001:1234:5678:90ab:1::.
It doesn't matter if the wifi is encrypted or not. All that matters is that you share the network with an attacker. You can ARP poison just fine, encrypted or open, wifi or wired.
Wireless costs more because suddenly you need to deal with antennas and RF and whatever. Adding a wire back on top of that doesn't magically make it cost less again.
Yes, IPv6-first is definitely the way to do it. Just be careful not to run into Github's issue (https://www.githubstatus.com/incidents/5y8b8lsqbbyq) or Google's issue (https://i.imgur.com/4gGECJ9.png - in case you're not familiar, 2002:: is the 6to4 prefix, and 2002:a0 is the 6to4 version of 10/8, so I guess somehow I was deleting old users from within Google's own network!)
> The basic idea is that whenever you find yourself memorising an IPv4 address, there's a failure somewhere. Possibly at policy and governance level.
Sorry, but that's a load of manure. It's not just about memorizing.
People break their DNS so often that it's a meme.
Not everything automatically does a reverse lookup on every address it sees, and when it does rDNS could quite easily be broken.
So when you need to figure out if a device is in the same building as you, is it easier to say "1.2.3. - oh, that's my building" or "1234:5678:90ab:cdef:1234:5678:90ab:: - oh, that's my building"?
> Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
Perhaps, but the other realistic option is a self-signed cert. Since browsers refuse to implement any kind of TOFU or otherwise 'trust history', a self-signed cert is pretty much exactly equivalent to no TLS at all.
> One day, an intermediary system is hijacked which carries your traffic, and your weather information can be rewritten in transit. Your credibility for providing outstanding data is compromised when you start serving up weather information that predicts sunny skies when a tornado watch is in effect.
Why would they want to do that? Is your weatherman always right?
> Additionally, you have now leaked information related to the traffic of your users. Even if the request is just vanilla HTTP-only, an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic.
Ah, yes, people are interested in the weather. Wow!
Of course, they could get the same info from observing that users are connecting to the IP address of a weather API provider.
> They also inject a javascript payload into your traffic that starts computing bitcoin hashes and you are blamed for spreading malware.
I disagree. So does Wikipedia ("where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties ... for example, an attacker within range of an Wi-Fi access point hosting a network without encryption could insert themselves as a man in the middle") and so I believe do most people.
"Active MITM" would be how you describe someone who does modify traffic.
And an attacker in each of the scenarios GP mentioned can modify traffic. (For ISP/attacker-controlled networks it's trivial; for other networks you just need to ARP spoof)
It's also clearly from Google Meet so... yeah. If he was worried about retribution (from Google, anyway) then they probably wouldn't have been using a Google service.
> You aren't logged in, not logged in isn't a state of "unauthenticated"
What? Yes it is.
> you haven't given any credentials meaning currently you don't have any authority, so unauthorized makes sense
Ok? Yes, if you are unauthenticated (and authentication is required), then you are also unauthorized. However, the error code is not communicating that you are unauthorized; it is communicating that you need to authenticate, thus unauthenticated is more appropriate.
> You can have several sets of credentials and switch between them
Ok?
> not giving them any isn't being in an unauthenticated state its a different thing
That is exactly what being in an unauthenticated state means. What would you define to be an unauthenticated state otherwise?
Sometimes they might have been able to allocate it more compactly - but how do you predict exactly what your needs will be in 20 years?
Other times they might not have been able to allocate it more compactly - are you really going to go make routes for a /25 and a /26 and a /27 when you need 200 IPs, just to save a single /27 over giving it the whole /24?
There can also be reasons to structure it more sparsely than required for UX, namely to give a more hierarchical structure - maybe by region and store, or similar.
tl;dr it's not necessarily a mistake that your allocations mean you use more space than strictly necessary
