So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (And their DNS idea won't work—or won't work differently than IPv6: a lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "AX" address (for ipv4X addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other end… like…
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
IPv6 adoption has been linear for the last two decades. Currently, 48% of Google traffic is IPv6.[1] It was 30% in 2020. That's low, because Google is blocked in China. Google sees China as 6% IPv6, but China is really around 77%.
Sometimes it takes a long time to convert infrastructure. Half the Northeast Corridor track is still on 25Hz. There's still some 40Hz power around Niagara Falls. San Francisco got rid of the last PG&E DC service a few years ago. It took from 1948 to 1994 to convert all US freight rail stock to roller bearings.[2] European freight rail is still using couplers obsolete and illegal in the US since 1900. (There's an effort underway to fix this. Hopefully it will go better than Eurocoupler from the 1980s. Passenger rail uses completely different couplers, and doesn't uncouple much.)[3]
[1] https://www.google.com/intl/en/ipv6/statistics.html
[2] https://www.youtube.com/watch?v=R-1EZ6K7bpQ
[2] https://rail-research.europa.eu/european-dac-delivery-progra...
It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.
That's pretty much identical to 6in4 and similar proposals.
The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular. Yes, it kill fresh ideas in the bud sometimes, but it also helps establish a cultural baseline for what is constructive discussion.
Nobody needs to hear about the same old ideas that were subsumed by IPv6 because they required a flag day, delayed address exhaustion only about six months, or exploded routing tables to impossible sizes.
If you have new ideas, let's hear them, but the discussion around v6 has been on constant repeat since before it was finalized and that's not useful to anyone.
See perhaps:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
Have an IPv4 address? Congratulations! You get entire IPv6 /48 for free.
Yes, but the compatibility is very very easy to support for both hardware vendors, softwares, sysadmins etc. Some things might need a gentle stroke (mostly just enlarge a single bitfield) but after that everything just works, hardware, software, websites, operators.
A protocol is a social problem, and ipv6 fails exactly there.
Even still. The rollout is still progressing, and new systems like Matter are IPv6 only.
So let’s say your internet provider owns x.x.x.x, it receives a packet directed to you at x.x.x.x.y.y… , forwards it to your network, but your local router has old software and treats all packages to x.x.x.x.* as directed to it. You never receive any medssagea directly to you evem though your computer would recognise IPv4x.
It would be a clusterfuck.
Contrast this with ip6, which is a completely new system, and thus has a chicken and egg problem.
Today it seems most ISPs support it but have it behind an off by default toggle.
At some point IPv4 addresses will cost too much.
Software updates scale _very well_ - once author updates, all users get the latest version. The important part is sysadmin time and config files - _those_ don't scale at all, and someone needs to invest effort in every single system out there.
That's where IPv6 really dropped the ball by having dual-stack the default. In IPv4x, there is no dual-stack.
I upgrade my OS, and suddenly I can use IPv4x addresses... but I don't have to - all my configs are still valid, and if my router is not compatible, all devices still fall back to IPv4-compatible short addresses, but are using IPv4x stack.
I upgrade the home router and suddenly some devices get IPv4x address... but it is all transparent to me - my router's NAT takes care of that if my upstream (ISP) or a client device are not IPv4x-capable.
I have my small office network which is on the mix IPv4 and IPv4x addresses. Most Windows/Linux machines are on IPv4x, but that old network printer and security controller still have IPv4 address (with router translating responses). It still all works together. There is only one firewall rule set, there is only one monitoring tool, etc... My ACL list on NAS server has mix of IPv4 and IPv4x in the same list...
So this is a very stark contrast to IPv6 mess, where you have to bring up a whole parallel network, setup a second router config, set up a separate firewall set, make a second parallel set of addresses, basically setup a whole separate network - just to be able to bring up a single IPv6 device.
(Funny enough, I bet one _could_ accelerate IPv6 deployment a lot by have a standard that _requires_ 6to4/4to6/NAT64 technology in each IPv6 network... but instead the IPv6 supporters went into all-or-nothing approach)
ahem
With IPv6 the router needs to send out RAs. That's it. There's no need to do anything else with IPv6. "Automatic configuration of hosts and routers" was a requirement for IPng:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.8
When I was with my last ISP I turned IPv6 on my Asus router, it got a IPv6 WAN connection, and a prefix delegation from my ISP, and my devices (including by Brother printer) started getting IPv6 addresses. The Asus had a default-deny firewall and so all incoming IPv6 connections were blocked. I had do to zero configuration on any of the devices (laptops, phones, IoT, etc).
> I upgrade my OS, and suddenly I can use IPv4x addresses... but I don't have to - all my configs are still valid, and if my router is not compatible, all devices still fall back to IPv4-compatible short addresses, but are using IPv4x stack.
So if you cannot connect via >32b addresses you fall back to 32b addresses?
* https://en.wikipedia.org/wiki/Happy_Eyeballs
> I upgrade the home router and suddenly some devices get IPv4x address... but it is all transparent to me - my router's NAT takes care of that if my upstream (ISP) or a client device are not IPv4x-capable.
* https://en.wikipedia.org/wiki/IPv6_rapid_deployment
A French ISP deployed this across their network of four million subscribers in five months (2007-11 to 2008-03).
> There is only one firewall rule set, there is only one monitoring tool, etc... My ACL list on NAS server has mix of IPv4 and IPv4x in the same list...
If an (e.g.) public web server has public address (say) 2.3.4.5 to support legacy IPv4-only devices, but also has 2.3.4.5.6.7.8.9 to support IPv4x devices, how can you have only one firewall rule set?
> So this is a very stark contrast to IPv6 mess, where you have to bring up a whole parallel network, setup a second router config, set up a separate firewall set, make a second parallel set of addresses, basically setup a whole separate network - just to be able to bring up a single IPv6 device.
Having 10.11.12.13 on your PC as well as 10.11.12.13.14.15.16 as per IPv4x is "a second parallel set of addresses".
It is running a whole separate network because your system has the address 10.11.12.13 and 10.11.12.13.14.15.16. You are running dual-stack because you support connection from 32-bit-only un-updated, legacy devices and >32b updated devices. This is no different than having 10.11.12.13 and 2001:db8:dead:beef::10:11:12:13.
So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space?
What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.
From where?
All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them.
But at some point IPv4 addresses would all be allocated… along with all the extended addresses 'behind' them.
Then what?
The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from?
You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bits… just like with IPv6. Great you managed to purchase/rent a legacy address range… but you still need a translation box for non-updated code… like with CG-NAT and IPv6.
And at the same time the address format and IP header is extended, effectively still splitting one network into two (one of which is a superset of the others)?
A fundamentally breaking change remains a breaking change, whether you have the guts to bump your version number or not.
That's cool and all, but end-user edge routers are absolutely going to have to be updated to handle "IPv4x". Why? Because the entire point of IPvNext is to address address space exhaustion, their ISP will stop giving them IPv4 addresses.
This means that the ISP is also going to have to update significant parts of their systems to handle "IPv4x" packets, because they're going to have to handle customer site address management. The only thing that doesn't have to change is the easiest part of the system to get changed... the core routers and associated infrastructure.
I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility.
IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always “it’s a second network and needs me to touch all my hosts and networking stack”.
Don’t like SLAAC? Don’t use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6.
In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.
The removal of arp and removal of broadcast, the enforcement of multicast
The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router.
All of these were choices made in addition to simply expanding the address scope.
It doesn't work like this. SLAAC is a standard compliant way of distributing addresses, so you MUST support it unless you're running a very specific isolated setup.
Most people using Android will come to your home and ask "do you have WiFi here?"
Simplifying address space assignment is a huge deal. IPv4+ allows the leaves of the network to adopt IPv4+ when it makes sense for them. They don't lose any investment in IPv4 address space, they don't have to upgrade to all IPv6 supporting hardware, there's no parallel configuration. You just support IPv4 on the terminals that want or need it, and on the network hardware when you upgrade. It's basically better NAT that eventually disappears and just becomes "routing".
There was only 1 mistake, but it was huge and all backwards compatibility problems come from it. The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.
IPv6 added very few features, but it mostly removed or simplified the IPv4 features that were useless.
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
?
The entire IPv4 address space is included in the IPv6 address space, in fact it's included multiple times depending on what you want to do with it. There's one copy for representing IPv4 addresses in a dual-stack implementation, another copy for NAT64, a different copy for a different tunneling mechanism, etc.
That's ... exactly how IPv6 works?
Look at the default prefix table at https://en.wikipedia.org/wiki/IPv6_address#Default_address_s... .
Or did you mean something else? You still need a dual stack configuration though, there's nothing getting around that when you change the address space. Hence "happy eyeballs" and all that.
IPv6 added IPSEC which was backported to IPv4.
IPv6 tried to add easy renumbering, which did’t work and had to be discarded.
IPv6 added scoped addresses which are halfbaked and limited. Site-scoped addresses never worked and were discarded; link-scoped addresses are mostly used for autoconfiguration.
IPv6 added new autoconfiguration protocols instead of reusing bootp/DHCP.
I see many ISPs deploying IPv6 but still following the same design principles they used for IPv4. In reality, IPv6 should be treated as a new protocol with different capabilities and assumptions.
For example, dynamic IP addresses are common with IPv4, but with IPv6 every user should ideally receive a stable /64 prefix, with the ability to request additional prefixes through prefix delegation (PD) if needed.
Another example is bring-your-own IP space. This is practically impossible for normal users with IPv4, but IPv6 makes it much more feasible. However, almost no ISPs offer this. It would be great if ISPs allowed technically inclined users to announce their own address space and move it with them when switching providers.
All endpoints need to upgrade to IPv4x before anyone can reasonably use it. If I have servers on IPv4x, clients can reach my network fine, but they then can't reach individual servers. Clients need to know IPv4x to reach IPv4x servers.
Similarly, IPv4x clients talking to IPv4 servers do what? Send an IPv4x packet with the remaining IPv4x address bits zeroed out? Nope a V4 server won't understand it. So they're sending an IPv4 packet and the response gets back to your network but doesn't know how to get the last mile back to the IPv4x client?
I desperately wish there was a way to have "one stack to rule them all", whether that is IPv4x or IPv4 mapped into a portion of IPv6. But there doesn't seem to be an actually workable solution to it.
But when IPv6 was standardized, a pure upgrade to IPv4 was still feasible. IPv4 allows for extensions headers and middleboxes hadn't yet imposed protocol ossification. If instead of the encapsulation the article supposes, the upgrade embraced translation, we could have had an IPv4+ with NAT fallback. A node on a network behind a IPv4+ router would send out a packet with the RFC1918 interior address encoded as the address extension. Either the server (which would have a proper IPV4 address) responds without the extension header, at which point the IPv4+ router at the edge has to do NAT-style connection tracking, or the response packet can be forwarded as-is.
All the pain of upgrading software to a new protocol still applies, with the added headache of variable length addresses (4 bytes, 8 bytes, potentially more). But no ISP has to make the investments or take the risk of the parallel infrastructure. The IPv4 core carries on, with incremental improvements but zero mandatory upgrades.
What you're describing there is just an approach to store NAT state inside every packet instead of on the router. I'm not sure that's even an improvement on v4, but in any case it wouldn't increase the size of the address space so it wouldn't help with the one thing driving the need for IPv6.
Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
Which has been discussed previously: https://hn.algolia.com/?q=The+IPv6+mess
Apparently the practical problems were related to people haplessly firewalling it out (ref. https://labs.ripe.net/author/emileaben/6to4-why-is-it-so-bad...)
Huh:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
And NAT needed zero software changes. That's why it's won. It brought the benefits of whatever extension protocol with existing mechanisms of IPv4.
IPv6 isn't an alternative to IPv4, it's an alternative to all IPv4xes.
"ping 1.1.1.1"
it doesn't work.
If stacks had moved to ipv6 only, and the OS and network library do the translation of existing ipv4, I think things would have moved faster. Every few months I try out my ipv6 only network and inevitably something fails and I'm back to my ipv4 only network (as I don't see the benefit of dual-stack, just the headaches)
Sure you'd need a 64 gateway, but then that can be the same device that does your current 44 natting.
The main limitation is software that only supports IPv4. This would affect your proposed solution of doing the translation in the stack. There is no way to fix an IPv4-only software that has 32-bit address field.
> There are lots of places that have IPv6-only networks and access IPv4 through NAT64
I've just deployed a new mostly internal network, and this was my plan.
The network itself worked, but the applications wouldn't. Most required applications could cope, but not all, meaning I need to deploy ipv4, meaning that there's no point in deploying ipv6 as well as ipv4, just increases the maintenance and security for no business benefits.
Are you sure about that? Until a few years ago my residential ISP was IPv4 only. I definitely couldn't connect to an IPv6-only service back then.
Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?
It is awesome until you understand that most equipement expect a TCP or UDP header; Then, with IPv4x, they find none, and drop the packet;
Protocol ossification is a real thing and the main bane in this topic
Old routers would be a normal UDP packet inside a normal IPv4 and route it normally. New routers would detect UDP port 84 and treat it as an extended IPv4x packet.
I took all that out because I wasn't writing a proposal for something we should actually implement in the real world, but an alternate history "What if people who wanted IPv4 but with extra space got their way" and the story was already too long.
Thanks though. Your comment really cheered me up.
Too sneaky, apparently. I suggest putting something at the top mentioning it ... then even folks with very short attention spans will see it.
The most likely alternative would have been 64-bit. That's big enough that could have worked for a long time.
- NAT gateways are inherently stateful (per connection) and IP networks are stateless (per host, disregarding routing information). So even if you only look at the individual connection level, disregarding the host/connection layering violation, the analogy breaks.
- NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
Until you have stateful firewall, which any modern end network is going to have
> NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
If 192.168.0.1 and 0.2 both hide behind 2.2.2.2 and talk to 1.1.1.1:80 then they'll get private source IPs and source ports hidden behind different public source ports.
Unless your application requires the source port to not be changed, or indeed embeds the IP address in higher layers (active mode ftp, sip, generally things that have terrible security implications), it's not really a problem until you get to 50k concurrent connections per public ipv4 address.
In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls.
There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.
A major website sees over 46 percent of its traffic over ipv6. A major mobile operator has a network that runs entirely over ipv6.
This is not “waiting for adoption” so I stopped reading there.
https://www.google.com/intl/en/ipv6/statistics.html
https://www.internetsociety.org/deploy360/2014/case-study-t-...
To be less glib: IPv6 is well-adopted. It's not universally adopted.
Motivation for retiring IPv4 completely would NOT be to make the world a better more route-able place. It would be to deliberately obsolescence old products to sell new.
It seemed strange that the need for CGNAT wasn't mentioned until after the MIT story. The "Nothing broke" claim in that story seems unlikely; I was on a public IP at University at the end of the 90s and if I'd suddenly been put behind NAT, some things I did would have broken until the workarounds were worked out.
What's the difference between that and dual stack v4/v6, though? Other than not needing v6 address range assignments, of course.
Honestly, this backwards compatibility thing seems even worse than IPv6 because it would be so confusing. At least IPv6 is distinctive on the network.
The first main issue is that most often we waste an entire IPv4 for things that just have a single service, usually HTTPS and also an HTTP redirector that just replies with a redirect to the HTTPS variant. This doesn't require an entire IPv4, just a single port or two.
We could have solved the largest issue with address exhaustion simply by extending DNS to have results that included a port number as well as an IP address, or if browsers had adopted the SRV DNS records, then a typical ISP could share a single IPv4 across hundreds of customers.
The second massive waste of IPv4 space is BGP being limited to /24. In the days of older routers when memory was expensive and space was limited, limiting to /24 makes sense. Now, even the most naive way of routing - having a byte per IP address specifying what the next hop is - would fit in 4GB of RAM. Sure, there is still a lot of legacy hardware out there, but if we'd said 10 years ago that the smallest BGP announcements would reduce from /24 to /32, 1 bit per year, so giving operators time to upgrade their kit, then we'd already be there by now. They've already spent the money on getting IPv6 kit which can handle prefixes larger than this, so it would have been entirely possible.
And following on from the BGP thing is that often this is used to provide anycast, so that a single IPv4 can be routed to the geographically closest server. And usually, this requires an entire /24, even though often it's only a single port on a single IPv4 that's actually being used.
Arguably, we don't even need BGP for anycast anyway. Again, going back to DNS, if the SRV record was extended to include an approximate location (maybe even just continent, region of continent, country, city) where each city is allocated a hierarchical location field split up roughly like ITU did for phone numbers, then the DNS could return multiple results and the browser can simply choose the one(s) that's closest, and gracefully fall back to other regions if they're not available. Alternatively, the client could specify their geo location during the request.
So, basically, all of that can be done with IPv4 as it currently exists, just using DNS more effectively.
We also have massive areas of IPv4 that's currently wasted. Over 8% of the space is in the 240.0.0.0/4 range that's marked as "reserved for future use" and which many software vendors (e.g. Microsoft) have made the OS return errors if it's used. Why? This is crazy. We could, and should, make use of this space, and specifically for usages where ports are better used, so that companies can share a single IPv4 at the ISP level.
Another 8% is reserved for multicast, but nowadays almost nothing on the public IPv4 uses it and multicast is only supported on private networks. But in any case, 225.0.0.0/8-231.0.0.0/8 and 234.0.0.0/8-238.0.0.0/8 (collectively 12 /8s, or 75% of the multicast block) is reserved and should never have been used for any purpose. This too could be re-purposed for alleviating pressure on IPv4 space.
Finally, there are still many IPv4 /24s or larger that are effectively being hoarded by companies knowing they can make good money from renting them out or selling them later. Rather than being considered an asset, we should be charging an annual fee to keep hold of these ranges and turn them into a liability instead, as that would encourage companies with a large allocation that they don't need to release them back.
The other main argument against IPv4 is NAT, but actually I see that as a feature. If services actually had port number discovery via DNS, then forwarding specific ports to the server than deals with them is an obvious thing to do, not something exceptional. The majority of machines don't even want incoming connections from a security point of view, and most firewalls will block incoming IPv6 traffic apart from to designated servers anyway. The "global routing" promised by IPv6 isn't actually desired for the most part, the only benefit is when it is wanted you have the same address for the service everywhere. The logical conclusion from that is that IPv4 needs a sensible way of allocating a range of ports to individual machines rather than stopping just at the IP address.
When you then look at IPv6 space, it initially looks vast and inexhaustible, but then you realise that the smallest routable prefix with BGP is /48, it should be apparent that it suffers from essentially the same constraints as IPv4. All of "the global internet" is in 2002::/16, which effectively gives 32 bits of assignable space. Exactly the same as IPv4. Even more, IPv6 space is usually given out in /44 or /40 chunks, which means it's going to be exhausted at almost the same rate as IPv4 given out in /24 chunks. So much additional complexity, for little extra gain, although I will concede that as 2003::/16 to 3ffe::/16 isn't currently allocated there is room to expand, as long as routers aren't baking in the assumption that all routable prefixes are in 2001::/16 as specified.
TLDR: browsers should use SRV to look up ports as well as addresses, and SRV should return geo information so clients can choose the closest server to them. If we did that, the IPv4 space is perfectly large enough because a single IPv4 address can support hundreds or thousands of customers that use the same ISP. Effectively a /32 IPv4 address is no different to a /40 IPv4 prefix, and the additional bits considered part of the address in IPv6 could be encoded in the port number for IPv4.
The multicast and reserved blocks total 32 /8s. Before IANA runout, we were going through over one /8 per month, so this would represent less than 2.5 years of allocations. We've already spent decades buying more time for people to migrate to v6; we don't need another 2.5 years that people will just immediately squander.
NAT is not in any way a feature. I'll admit it can be a useful tool in your toolbox sometimes, but otherwise it's just a completely unnecessary complication that breaks things and wastes time and effort. It's not something to be building the Internet on. You want each device to get an IP and you don't want two devices to have the same IP, because that's how machines on the Internet send packets to each other -- which is the entire point of having the Internet at all.
> All of "the global internet" is in 2002::/16, which effectively gives 32 bits of assignable space. Exactly the same as IPv4 [...] the assumption that all routable prefixes are in 2001::/16 as specified
Global allocations are actually coming from the entire of 2000::/3, not 2002::/16 or 2001::/16 (and there's another five untouched /3s in case we need them). So far about 0.2% of it been allocated to RIRs, and most of that RIR space has not yet been allocated to anybody. We're clearly not exhausting it at anything like the rate of v4.
v6 is less complex than v4 in practice due to not needing NAT, and gains us far more than you're thinking. A /48 contains 65k subnets of effectively infinite hosts each, which is similar to a /8 but with no limit on hosts per network, and there are something on the order of a trillion of them in total rather than 256 of them.
Rather than looking down on IPv4 , we should admire how incredible it's design was. Its elegance and intuitiveness, resourcefulness have all led to it outlasting every prediction of it's demise.
What is described here is basically just CIDR plus NAT which is...what we actually have.
At the time IPv6 was being defined (I was there) CIDR was just being introduced and NAT hadn't been deployed widely. If someone had raised their hand and said "I think if we force people to use NAT and push down on the route table size with CIDR, I think it'll be ok" (nobody said that iirc), they would have been rejected because sentiment was heavily against creating a two-level network. After all having uniform addressing was pretty much the reason internet protocols took off.
