Thankfully, we have DNS. A lot of ISP issued consumer CPEs now automatically create lan-local DNS entries for clients based on hostname provided by the client at dhcp time, a lot of clients also natively support mDNS, and there are plentiful free DNS providers if none of the above applies to you, and you can't host your own.
Remembering IPs isn't something that people should need to do at this point in our networks maturity.
As an example 2001:0db8:0000:0000:0000:0000:0370:7334 could be written as 2001:db8::370:7334 instead (notice that leading zeros were also culled). This paired with the fact that hexadecimal tends to be easier to memorize and doesn't have the strange subnet masking logic like IPv4, gives it a lot of advantages over IPv4's address notation.
The problem is that it's almost like router firmware and ISPs go out of their way to make their addresses harder to work with by filling out all 8 hex groups in the addresses they grant. Considering the sheer amount of available IPv6 addresses, it's from my understanding, completely unnecessary and I'm really curious if they have any kind of justification or technical reasoning for doing this.
1. easier routing tables if you can add meanings to specific bit ranges of your ipv6 address. In the tightly assigned ipv4 networks we have arrived at this is a bit annoying.
2. If the ipv6 conventions were that you set, say the highest 5 hex groups to 0, and use the lowest 3 hex groups for addresses, it would still be 65536 times as large as the ipv4 space and would suit most needs for the mid term future. You could even write ipv6 addresses nicely using e.g. ::ef13:2.1.7.100. This is a valid ipv6 notation! If this space ever got too tight one could open another one of the available hex groups and use two hex group prefixes. But I think when this happens, a lot of configurations would break because they'd assume that only 48 bits are used of the total 128. To prevent router,switch,firewall, etc. vendors from putting any such assumptions into their devices, using the full 128 bits from the start is a good option.
Giving everyone, worldwide an internet address means they have to be longer than limiting it to the early adopters.
Not really. In fact, pretty much anything would have been easier to memorize than this colon-separated nonsense, which makes URL parsing more difficult, and which is so stupidly complex that it has a special syntax to ignore repeating zeros.
The [IPv6]:port syntax is unfortunate, but I'm not sure what they'd have done instead. Dotted hexadecimal would be ambiguous, because "1.2.3.4.5.6.beef.de" looks like a DNS hostname.
Zero compression exists because it's more convenient than writing all those zeroes, especially with CIDR prefixes like "2000::/3".
As well as decimal:
Both lead to google.com
Except for recent versions of Firefox Mobile: https://github.com/mozilla-mobile/fenix/issues/4343
mDNS might also help, I haven't tried that approach.
But cloud or not, if you setup a private network with v6 you can get a nice /48 prefix, and you give out /64 prefixes to VMs, so you'll have 48 unchanging bits to memorize (or put it into a .txt to have it near). And most of that will probably be zero anyway.
For example 2a00:1450:4001 is a /48, and 2a00:1450:4001:082b /64. Only change is "082b".
I know, it's not the same as just remembering 1.1.1.1, but most of the people working with v4 never had so simple addresses to work with. (And if we're talking about 10.0.0.0/8 and other private addresses, well, folks can continue to use them, if they want to endlessly debug NAT and static routing hacks.)
If we had added 16 bits to v4 we would have 100% adoption by now.
The very slight convenience you mention is far outweighed by 32+ digit IP addresses.
Also please don't bring up DNS. Anyone arguing that DNS is a solution to this problem has never done devops or IT.
You would be surprised how much hardware and software doesn't support IPv6 properly. Sometimes it is the basic things, sometimes the more advanced stuff but that just means it takes a second or multiple days to find out. The problem is, it just is a similar but different protocol so you have to be quite diligent and check everything you need for the device/ service to work.
People do all kinds of stuff on underlay and overlay networks. E.g. some Dell VxRail hyper-converged appliances use IPv6 for the management network https://i.dell.com/sites/csdocuments/Shared-Content_data-She.... This is basically just link-local addresses for L2 reachability if I remember correctly but they could've gone with IPv4 there as well. It certainly would be more common for enterprise appliances to not rely on IPv6 for anything even when it shouldn't make a difference whether you do.