Control8894

Of course not. They removed it because it saves them money, thus increasing their profit margins.

Should is not does, and also LOL @ anycast for some SMB's internal networking. Yeah, good luck with that bud.

> when it's broken it's broken cuz you broke it

No duh, but that doesn't make it any less broken.

This is a very poor straw man.

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.

Erm... no.

Don't worry, you're only allowed to see responses to stuff if you're logged in. Hope they don't ban you from having an account for daring to @ musk.

Well, they are really wireless.

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.

Nothing has taken its place, and you didn't even get anything cheaper. The only one who won was Apple.

> These are all big companies out to make a buck.

!= not bad

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.

> for example, an attacker within range of an Wi-Fi access point hosting a network without encryption

The monkey in the middle doesn't get to "relay" anything either, but he can sure see it going over his head.

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.

Got there eventually. Crappy ISPs.

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 a fake background.

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.

Is it? Or is the problem the similarity of the concepts?

> What does "unauthenticated" even mean here?

That you're not logged in.

> 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

I didn't have IPv6 available from the sole (land-based) ISP who offered service at my last house, Altice USA (Suddenlink/Optimum).

I moved away about 13 months ago.

(Worse yet their modem/router did RAs or whatever but there was no connectivity out)

The past 10 years of IPv6 have been largely uneventful for me: it just doesn't work.

I think there's an extra, important, oft-missed part implicit in your scenarios:

1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. ... but don't make anyone learn anything new

2) if we're already replacing everything, make stuff better ... and make everyone learn everything all over again

My employer also disables it (choice made above me). And I get it. It really is duplicating lots of work for absolutely no benefit (to the organizations doing the work).

It's a shame that you're getting downvoted. I'm sure a lot of those people are shouting at their screen "well just learn it" but even if you're familiar enough with all the stuff it changes (RA, NDP, heck the lack of NAT), it's still a ton of work to get it properly set up and worse yet to maintain.