keiyakins

There's only a very few places where typing IP addresses actually makes sense. Configuring DNS is the main one. Trying to isolate problems is another - if you can ping 8.8.8.8 but not google.com you can reasonably infer that the problem is DNS. I really can't think of any others.

That latter one is admittedly kind of a pain, but a wallet-sized cheat sheet can solve it for you. Might be a good idea to try to convince vendors to include a reliable entry or two in the hosts file for that purpose? You can always add it yourself for now, when you're on your own workstation.

How would changes not have been required in the ISPs? An IPv4 router wouldn't know what to do with a 4.4 packet. At best, it'd route it to the wrong place - 1.2.3.4.5.6.7.8 and 5.6.7.8 are totally different hosts that may well not even be on the same continent.

Additionally, the only reason so much code had to change for ipv6 is that Berkley sockets is a terrible, terrible API that has abstractions so leaky they might as well not exist. Sure, in other APIs (what few exist) low-level code had to be rewritten somewhat, but that's going to be true for any protocol change, because that's kinda what change means.

Yeah, it's not always, but for most home networks it probably is. Ideally they'd give you a /56 or even a /48, but giving those on request and a /60 by default is fine.

It probably was, seeing as Plan 9 was named after a movie.

This article is kinda garbage, it gets simple facts wrong in the first sentence of the abstract (and again in the second sentence of the article): Plan 9 is not Unix. At all. It shares some ideas with it sure, but if that's enough to make something Unix so is Windows NT. It's also rather debatable that it "failed" - a lot of good research happened there and those ideas have gone on to influence production environments the world over.

Not if you want SLAAC to work, no.

How are they blocking? You're just behind a NAT64, which is no worse than NAT44, with the bonus of having actual connectivity on the IPv6 side.

Even? /60 should be the minimum, even home users usually have a couple subnets (guest networks for example, sometimes one for the router's WAN link) and you want the boundary to be on a nybble boundary

IPv6 was designed in the late 80s/early 90s, before home users had internet access. At the time there was serious debate over switching to the OSI stack instead. You're showing your lack of history knowledge more than anything.

Why are you using IP addresses directly? That's what DNS is for. There's even mDNS for in simple home networks.

(The DHCP thing is valid but that's one single android dev being an ass who can't read deciding that it imposes limitations it doesn't and ruining it for the rest of us)

NAT is neither a privacy nor security feature, what are you talking about? Have you actually tested what your CPE does when it gets packets addressed to internal IPs from the WAN port? Almost every time, the answer is just pass it on to the target host. Thinking NAT is a security feature makes your network MUCH less secure.

As for privacy - you can fingerprint individual devices pretty trivially, and with privacy extensions for SLAAC you can only tell what /64 network it's coming from, which is no more information than IPv4 (unless you're behind CGNAT, but frankly being behind a 4-to-4 CGNAT shouldn't count as internet access because you literally can't get incoming connections.)

Because on the wire it's encoded as four bytes. If you can make eight binary digits count up to 999, you can do a lot more than just make IPv4 last longer.

Indeed, your system would require NAT4.44 as a transition mechanism, just like NAT64 is needed now. It gets no benefit over IPv6, and none of the other benefits like SLAAC.

So, what's the point? It's no easier to migrate to, and once we're migrated is worse.

it's ::ffff:1.2.3.4, so that loopback can be ::1. But yeah same idea.

so somehow 0.0.0.0.8.8.8.8 is an extension of the legacy address 8.8.8.8, and ::ffff:8.8.8.8 isn't?