[hot_gril]

Since the main problem was address space, they should've just expanded it. Let everyone keep their old v4 addresses (with 0-padding), focus on the protocol upgrade, and give new users longer addresses for cheaper. You wouldn't even need DNS changes initially. Instead, v6 became a whole new thing with additional goals like removing NAT (which I'm not even convinced is a good idea), so of course there'd be way more friction.

Like, I said this elsewhere, Cloudflare public DNS is 1.1.1.1. If I switch to ipv6, I get to use 2606:4700:4700::1111. You telling me that's an upgrade?

[TheLoafOfBread]

I agree. Instead of just making v4 addresses bigger (and related services around the protocol as well - ICMP, DNS, ...) a committee spawned jack of all trades, master of none IPv6 incompatible with current IPv4 stack.

[bauruine]

IPv6 is compatible with IPv4 there are millions of devices with only an IPv6 address that work just fine.

[hot_gril]

No, I only have a v4 address with my ISP and cannot use a v6-only device at home.

[bauruine]

IPv6 is backwards compatible to IPv4 but not the other way around. If you have a solution how to address a 128bit IPv6 address with the 32bits available on v4 I'm sure many people are eager to talk to you. It's just not possible.

[hot_gril]

With a 6-to-4 gateway then yeah. But at that point you're using v4.

[Dagger2]

How do you expect compatibility with v4 protocols/software/hardware/routers/ISPs to work without using v4?

That's a serious question. Do you have a way for this to work? Because I don't think it's possible (for fundamental reasons: https://en.wikipedia.org/wiki/Pigeonhole_principle), and it would be extremely unfair to criticize the designers of v6 for not fixing an unfixable problem.

[unethical_ban]

Yes.

Also, any change to the protocol was going to be a massive shift regarding network hardware. It wasn't ever possible to slap a few more bytes onto the address.

If you're going to make a monumentap shift, why not do it right?

[JohnFen]

> If you're going to make a monumentap shift, why not do it right?

yes, that was the argument from the very beginning, and it's not without merit. I disagree with it, because it's making a monumental shift into one that is even more monumental and increases resistance to making the change at all.

But who knows? Both sides of this argument are just speculating.

[hot_gril]

It would still be a much smaller shift if they focused on only expanding the address, and I guess removing packet fragmenting while they're already changing the fields. Why not do it right, cause at least it gets done that way.

There have been other huge migrations pulled off in networking. HTTP->HTTPS is the first that comes to mind. Extra layer of security, no other changes. Browsers slowly made users more and more wary of unsecured sites, and it became easier for site admins to obtain SSL certs. Once plain HTTP was finally made uncommon, versions of SSL/TLS still got upgraded slowly. They also avoided making it too flexible and turning into a fragmented mess like email or XMPP, i.e. browsers strongly avoid self-signed certs and started banning old versions.

[bell-cot]

Yep. It's as if they didn't understand that ~nobody would want to leave the great old IPv4 Club (packed with all your friends, and everyone who you'd want to meet) for the shoddy new IPv6 Club (with ~zero people there, probably nobody you know, and good luck trying to get a waiter's attention). And also pay for memberships in both clubs during the vague "eventually" transition period.

[p1mrx]

> Cloudflare public DNS is 1.1.1.1. If I switch to ipv6, I get to use 2606:4700:4700::1111. You telling me that's an upgrade?

The concept of vanity IPv4 addresses was invented in 2009, when Google acquired 8.8.8.0/24 from Level3. This is an emergent feature of a small, densely packed address space. IPv6 had existed for a decade (EDIT: not two decades) by that point, so you can't really blame the designers.

Sprint controls 2600::, probably by accident, but they're not doing anything interesting with it.

[hot_gril]

That's true, but even the less memorable v4 addresses are easier to deal with and nicer on the eyes. And on a LAN with a NAT, you typically get memorable addresses like 192.168.1.2.

Maybe the bigger issue was trying to get rid of NAT. People don't want every local network device to have a public IP and have to trust that the router's v6 firewall will do its job.

[JohnFen]

> People don't want every local network device to have a public IP

I absolutely don't want this. But as I understand it, I can avoid this by assigning my machines the IPv6 nonroutable addresses fe80::/64. They're the equivalent of 192.168.* and 10.*

[hot_gril]

Same as the firewall, it's fine if it's done right. But does every machine get link-local v6 addresses by default? My Mac is set to "automatic," which I assume asks the router. Even if I use link-local, does every router (even crappy ones) respect the no-forward rule? This is along with several other aspects of my network changing to use v6.

Meanwhile, if someone sends a v4 packet with TCP port 22 to my router, it can't tell where to forward it even if it wanted to. It takes effort to do that, namely a port forwarding config.

[JohnFen]

> But does every machine get link-local v6 addresses by default?

If you use DHCP, then I think you can configure that. What I have in mind is to assign static IPs to all of my fixed machines anyway, and use DHCP to assign IPs to transient machines. Not sure if that's reasonable, but it's my current thinking.

> does every router (even crappy ones) respect the no-forward rule?

There may be broken ones, but it doesn't matter so much because your ISP won't route such addresses regardless.

[hot_gril]

> If you use DHCP, then I think you can configure that. What I have in mind is to assign static IPs to all of my fixed machines anyway, and use DHCP to assign IPs to transient machines. Not sure if that's reasonable, but it's my current thinking.

You probably can, but as it's often said, most security breaches are caused by misconfiguration.

>There may be broken ones, but it doesn't matter so much because your ISP won't route such addresses regardless.

Yeah fair enough, I can trust my ISP to do that at least.

[unethical_ban]

NAT is a bandage over a crippling of proper network behavior. You trust your port forwarding isn't illicitly opening itself, no? Then you can trust a default deny inbound policy on IPv6.

[hot_gril]

My port forwarding would have to actively try to allow traffic to my host. It doesn't even know where to forward to. And like it or not, NAT has momentum. Getting rid of NAT would be a big migration in of itself.

[Dagger2]

This is actually wrong, and dangerously so. Your router knows perfectly well where to forward any given packet to: it forwards it to the IP that's in the packet's "destination IP" header.

If a connection comes into your router with the destination IP set to one of your LAN machines, NAT will not stop the connection.

There's no reason to be using NAT to protect yourself from inbound connections, because that's not a thing NAT even does in the first place. It often makes things actively worse even, by making it easier to port scan for your servers and by giving you a false sense of security.

[unethical_ban]

NAT66 exists, it just isn't a necessity in IPv6. There are also private IPv6 networks.

They are called Unique Local Addresses (ULA) and are in the range fd00::/8.

Which itself is so much better than RFC 1918 addresses. If you need private, non-Internet routable addresses, then you generate a random one. In the event two private networks need to communicate over VPN, for example, there is no clash.

[p1mrx]

You can number a LAN with fd00::/64 and use IPv6 NAT to reach the internet, so the addresses are even shorter than 192.168.1.x. It's just not commonly done that way.