There is a great level of IPv6 awareness and enthusiasm in sort of technically elite spaces. Like at Ben's talk at RIPE that we're talking about, the audience was kind of laughing together at the non-IPv6 outgroup.
Meanwhile, I keep helping people use Let's Encrypt over on the Let's Encrypt forum. One of the most common reasons that people are failing to get their certificates is ... misconfigured IPv6 on their servers or in their DNS! And people in that situation often (1) didn't think of that as a possibility, (2) didn't notice (!!), (3) didn't necessarily care about it. Even worse, when people are told something like "your certificate issuance isn't working because your AAAA record is pointing at your old hosting provider rather than your current hosting provider" their usual response is to delete the AAAA record rather than updating it.
Other forum members may also advocate this as a solution. "Oh, just delete your AAAA record, you don't need it."
I'm not making this up, I've seen these things happen about 100 times on the Let's Encrypt forum.
Now, these are primarily sites in the long tail of Internet popularity, the proverbial Joe's Lamp Store rather than Gmail or Facebook or something. But the level of IPv6 awareness and interest among small-scale site operators and people doing small-scale IT stuff is very weak. And I've also seen that a surprisingly high fraction of web sites are IPv4-only rather than dual-stack.
I'm working on 240/4 usability, but I certainly don't want people to delete their AAAA records. I want them to know what an AAAA record is, and want to have their AAAA records be correct.
But there's quite a gap, in a way, between the elite and the non-elite tech spaces on this.
If you do have AAAA records, Let's Encrypt (not unlike other software and services!) will prefer the AAAA records when doing domain validation for your domain. So if you have a correct A record and an incorrect AAAA record, your domain validation process will fail. You can then "fix" this by deleting the AAAA record, but it isn't a fix in the larger scheme of things, but indeed it makes plenty of users happy right away.
In addition, rate limiting with IPv6 is much harder (because IPs aren't scarce), so you risk DoS or other kind of abuse.
Users aren't getting single IPv6 addresses though. Most assign a /48 which is at least a bit better.
And rate limiting is very uncertain. If I limit per /56, users that have an entire /48 can outright bypass the rate limit. If I limit per /48, maybe I'll erroneously limit thousands of users whose ISP has all of them on the same /48.
If you wanted to block me, you'd have to block the whole /48. If you blocked a /48, you could be blocking 64,000 people.
Looks like crote brought the issue up in a sibling thread.
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.
Large companies (and even ISPs) seem to be going for "IPv6-mostly" rollouts. Basically, everything is done primarily using IPv6, with fallbacks to IPv4 only when strictly necessary. This means IPv4 traffic gets converted to IPv6 at the client, forwarded over an IPv6-only network, and turned into "native" IPv4 for the internet at an edge NAT64 gateway. Legacy IPv4-only devices (printers and such) get an isolated vlan with its own gateway, and will of course be replaced with IPv6-capable alternatives as soon as it's appropriate.
I agree that for smaller companies it's relatively little benefit for the amount of work required, but if you're overhauling your network for other reasons anyways it makes little sense not to do it.
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.
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.
Ok, not just memorising. It's also the culture of cargo culted broken network designs, of excel spreadsheets from hell, of thinking everyone can memorise or put few post-its with IP addresses important to them so you don't need to care for DHCP and DNS or actually setting up routing instead of throwing a ton of NATed 10.0.0.0/8 or 192.168.0.0/24 then crying when there's a need to setup 5 layers of translation to connect two services (been there, done that, kept the scars).
As others pointed out, you should have anycast addresses for core network services (DNS at least).
IPv6 arguably even makes it easier because link-local automatic configuration actually works unlike v4 APIPA, well enough to discover and talk to other nodes on given L2. I still remember my happy surprise when HP ILOs used that to let me configure them over network by just connecting to same vlan, something I can't do on v4 without messing with DHCP rules.
The fact that link local actually works, combined with multicast and predefined multicast addresses like ff02::1 or the addresses for mDNS, DNS-SD, LLMNR etc mean that you can actually get somewhere without configuring IP on the link.
Do you need to learn new things, and possibly rearchitect the network? Sure. But it's because v4 was deficient.
Also, more often than not, the "it was DNS" involves "resolver not configured" or "put BS in DNS got BS back now crying".
> 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.
Essentially entire promise of DirectAccess, the transparent VPN system added in Vista, depends on the office network being IPv6-clean (as in, no user-used services that require v4 connectivity). Originally it required IPv6+IPsec connectivity at client side, due to lack of wide availability various fallbacks were added in Windows 7.
It's also why Vista and later had such a push to autoconfigure Teredo and similar V6 transition technologies.
> when it's broken it's broken cuz you broke it
No duh, but that doesn't make it any less broken.
Forcing the change seems to be the only way to fix some networks and some software, in fact.
> No duh, but that doesn't make it any less broken.
Nor does it make ones inability to ship minimal HOSTS file any less bad.
This is a very poor straw man.
In IPv6 world you wouldn’t use all the significant digits randomly and because you have so many you could actually use one of the octets to perfectly encode the building information:
Building 1: 2001:1:: Building 2: 2001:2::
(You can go further with this concept and encode region/country/state/etc into the addressing as required)
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::.
For equivalent of 10./8 space, you'd have ULA, which can be subdivided this way just fine (and arguably since fc00::/8 is left in limbo, you can use that. Or just decide to fit whatever addressing scheme you decide into 80 bits left after typical fd00::<48bit random>/48.
So sorry, your v4 strawman isn't too good either.
I mentally swap the labels[1] when reading their marketing or release notes. If it says things like "No longer crashes when using IPv6", then I flip that and read it as "No longer crashes when using IPv4". That latter statement is absolutely insane and would have you abandoning that vendor as fast as you can tear up the contract. Nobody bats an eye with the first statement! Why not!?
Azure literally had this scenario, where merely enabling IPv6 on one network would crash their managed PostegreSQL service on another peered network with no recourse other than rebuilding everything form scratch without IPv6 to roll the change back!
[1] Or a generic placeholder than encompasses both. E.g.: "Fix: Enabling the internet protocol no longer causes irreversible outages with your database service."
Even Google, one of the champions of IPv6 adoption on the Internet, only started adding IPv6 support to GCP in the 2020s. In all public clouds, there are still numerous services that don't support it at all. And I can 100% guarantee that the next public cloud that anyone creates will start off with IPv4 support; maybe it will have IPv6 as well on day one, maybe not.
On the contrary, essentially all of the IPv4 public ranges have now been allocated. The incumbents have bought up what they can, leaving essentially nothing for new clouds to use. It's one type of moat, and the three biggest providers are happy to keep everyone on the far side of it.
A new cloud starting in 2025 onwards would likely be based on an IPv6 native design with IPv4 as the "add on" for public endpoints only, such as load balancers and proxies.
IPv4 is far too ingrained to start with IPv6 only.
We’re closer than most people assume.
If ipv6 had been designed form the start to allow seemless transparent access to ipv4 from an ipv6 only client that would be fine. But dual stack means twice the work and very little benefit (what services are ipv6 only, even today)
It does. It's called NAT64, and it works/breaks as well as regular NAT44.
A good majority chunk of cell carriers today have gone IPv6-only for phones. They rely on NAT64 gateways (rather than CGNAT) to access IPv4-only resources. A lot of consumer internet is slowly following that lead as a better alternative to CGNAT. At least if your customers are consumers we are really close to "You might only need to serve IPv6."
(It's the "Enterprise-grade internet" that is interestingly lagging and falling behind in IPv6 adoption, and maybe doesn't see enough reason to support IPv6-only well; especially if the cost of IPv4 plateaus again, as some suggest it might. Recent AWS cost increases for IPv4 have been something of a call to action to some Corporations, but in general if you are B2B you probably need IPv4 support for a while longer as the economic incentives games play out on a long, slow horizon.)
I thought it was possible to make a pure v6 network and use NAT64 as needed? I mean, we can argue if that counts, but I argue yes:)
On the client side there are apparently some subtleties about the DNS interaction if you want to literally have IPv6-only on the clients (as opposed to IPv4 CGN). If the clients do anything to not trust their ISP's view of DNS (like DNSSEC enforcement, or using DoH and an outside resolver), the ISP can't fool them into thinking that they should connect to an IPv6 address for a service that, from the point of view of the Internet as a whole, is actually IPv4-only.
Can I do "ssh 1.2.3.4" on a pure ipv6 stack yet? Last time I looked at ipv6 I couldn't even ping an ipv6 host by doing "ping 1234::5678", I had to run a separate tool (ping6)
The nat64 and vice versa should have been the play from the start. Want to host a sevice? Put in ipv6 only network, host it on 1234:5678::1, have your firewall with a public ipv4 address do the port forwarding, taking your public 12.34.56.78:1234 and natting it to 1234:5678::1.
Just the same as hosting your service on 192.168.0.1 and port forwarding.
But 20 years of dual stack and horrible cludges around changing public IPs later and many people still prefer ipv4.
IIRC, it's been over a decade since the "ping" command became able to understand both IPv4 and IPv6 addresses; it was only during the early adoption of IPv6 by userspace that we had separate commands for the new IPv6 stuff. Quoting https://www.man7.org/linux/man-pages/man8/ping.8.html "As of version s20150815, the ping6 binary doesn't exist anymore. It has been merged into ping. Creating a symlink named ping6 pointing to ping will result in the same functionality as before." So it seems it has been a long time since you last looked at IPv6.
I ran IPv6 on xfinity. It works. My devices don’t. I like my devices. Easier to just not use it.
I think Let's Encrypt's behavior is correct, and I don't think anyone inside Let's Encrypt or CA/B Forum would like to inflict "pain [...] on host and network operators" beyond the current practice. Let's Encrypt's current behavior could be described as cooperating with IPv6 adoption rather than compelling IPv6 adoption, which seems like a reasonable place for a certificate authority to be.
There are cases where Let's Encrypt has made choices that potentially slightly reduce compatibility in order to encourage what it considers technically correct behavior. The first one that comes to mind is
https://community.letsencrypt.org/t/adding-random-entries-to...
but I know there are others. On the other hand, all of those decisions can be justified in terms of improving the correctness of PKI software (like not hard-coding things that should not be hard-coded). I can't think of any example that's like "we wish this other technical thing would happen outside of the PKI, so we'll try to force it along", and I don't foresee the broader community getting comfortable with that.
There was a comment below that in the LE forums instead of asking people to fix their AAAA records, they ask them to remove it. That's exactly the behavior you don't want to reward, so you must cause pain.
https://www.verizon.com/support/residential/internet/getting...
there should be an itu mandate to label this kind of service distinctly different (e.g internet lite/basic)
That is one projection, but it is also a very bleak view of the future. One that we should actively fight at any opportunity and at almost any cost. It will centralize the internet further and squash many attempts for alternative communications.
Would it? It seems to me that a future where 1. every home land-line Internet connection is CGNATed; but 2. every cellular Internet connection is a public IPv6 prefix (as is already mostly the case today!); is actually a promising one. Provided, that is, that residential ISPs also get off their collective asses and provide the promised "hosted edge compute" capabilities they've been tinkering with for the last 10 years.
Since the Internet's inception, people on residential connections have been stuck in a broken mindset of "your home PC can act as a monolithic Internet peer — but only an unreliable one, that can't receive messages when it's shut off and is prone to being DDoSed — so you probably shouldn't actually use it as a server/p2p node, for anything other than, say, VoIP, or hosting an ephemeral multiplayer FPS game session. And you can tinker with a development web-server on your home network — but if you want to actually host anything, you should go pay a cloud provider."
Whereas, in a world with no well-Internet-connected home PCs providing the illusion of the possibility of hosting a home server, only instead:
1. home PCs — which can compute well, but can't be a network-ingress, and also might go down (often for laptops, less often for desktops, but both far more often than a real server would);
2. smartphones — which can network-ingress, but can't spend long periods computing (without burning all your battery life), and which will go down / out of wireless range extremely often; and
3. both commercial, and more importantly ISP-residential, edge-compute clusters — which would give tiny compute slices per workload, but ones with full network-ingress, and would never go down;
...then it'd be clear to all the people who had been thinking until that point that they could get away with p2p on home PCs using STUN/TURN-based protocols, that they would have to do something else; that operating systems (esp. mobile ones) and their client-server/p2p applications would have to evolve to become inherently edge-hybrid; that applications would need to evolve frameworks to embed persistent network-ingress "edge components" that could be shipped automatically and implicitly to the active network's associated edge deploy environment as part of the application's runtime; etc.
If you can't picture that: think about a web server backend that automatically deploys/updates an associated Cloudflare Worker whenever it boots up; and which then expects to be talked to through that Cloudflare Worker proxying requests to it; and where that Worker can also buffer requests, store data into its edge key-value store, etc.
But instead of a web server backend, it's the Minecraft app on your phone; and instead of Cloudflare, it's your residential ISP; and instead of the edge worker making a forward connection to your phone, your phone holds open an ngrok-like reverse connection to the edge worker to receive requests.
(Oh, and one other point of necessary evolution: that the "server component" of any p2p app would also be a mobile workload — not shiftable to the edge itself, but rather through the persistent edge workload to any [similarly reverse-connected, not always online] "compute host nodes" owned by the same user/organization. Such that you could buy a little NUC/NAS-like box to shove under your TV at home, whose marketed purpose would be compute+storage offload for the workloads launched on your phone; or such that your office could have some server racks for free auto-offload of "server components" of apps running on any employee machine — reversing the usual "cloud app with local client" relationship into "local app with slaved cloud workload." Where, in either case, the relevant workloads are still canonically on your phone/PC, so if the "compute offload" has to be drained for an update, the workloads just temporarily migrate back to your phone/PC.)
From my perspective, this would actually be a much better Internet in practice than the one we have today. Individuals would be far more able to host persistent, accessible services on a whim, without investment into local infra or being beholden to a commercial provider with a ToU. Individuals would be paying their ISPs for edge hosting, yes (if they don't have a server with a public IP to run an "edge layer" on themselves); but —
* those would be small fixed costs (as apps' network-ingress components would be small fixed workloads);
* and would likely be sold as free value-adds of data plans (just like web hosting, email, and access to locally-mirrored NNTP groups used to be sold as value-adds of residential Internet plans);
* and such workloads would only be smarter versions of the "dumb pipe" the residential ISP was already providing, not backends in-and-of themselves; and so wouldn't be subject to a VPS-host-like "you can't host X/Y/Z on our servers" type ToU, because users are not hosting anything per se;
* and as such edge workloads live on a very high-level abstraction layer, an edge-hosting ISP would be empowered to do all sorts of things to defend such workloads from DDoS attacks (e.g. putting the known-protocol workload behind a layer-7 WAF), that it can't do for individual customers' single-homed single-IP single-port, arbitrary-protocol home PC server processes.
As you say, residential ISPs used to provide additional services to their customers like web hosting, email, NNTP, shell access, time synch, IRC, mirrors of popular archives. They don't anymore - frequently, not even email. ISPs have clearly shown that they're not interested in being much more than the fastest dumb pipe around, because that's what their customers want, and I don't see that trend reversing.
When Netflix and others put CDNs "at the edge", they aren't doing that by building their own DC inside your city; nor by renting space in a random colo facility. Rather, they partner with each of the local regional ISPs, to put their CDN inside the ISP's "edge hosting DC" — a facility that almost all ISPs own (if not necessarily manage) at least one of in every city, precisely for the purpose of enabling such agreements.
So, unlike most Over-The-Top data services (which ISPs have long since lost the competency for), this one is something ISPs are actively doing. They're just not selling it B2C; their edge data-centers are currently a pure B2B play for them. But ISPs do know how to sell things B2C — so this would just be a question of them feeling enabled by product re-packaging to give this product line over to their B2C sales and marketing departments as something to charge their customers for.
"Re-packaging" this B2B colo into something they can sell to customers, would in turn just require the mobile OS vendors to step up and write code to make doing so an ops question rather than an R&D question — just as they did for visual voicemail, wi-fi calling, eSIM deployment, and so on. Essentially, Apple and Google would just need to provide their own server racks to ISPs, which host workload hypervisors for offload of workloads from "their" devices — in such a way that offload wouldn't be something customers would be paying Apple or Google a subscription fee for, but rather, as with Visual Voicemail, something where usage records from this system could feed into the ISP's usage-accounting systems, to be reduced into billing items by arbitrary ISP data-plan business rules.
---
And hopefully — but I'm not holding my breath — this would be done using open protocols and with FOSS-replicable software, such that eventually the ISPs could stop relying on Apple and Google to provide this only for specific devices, and instead could ask for their 3GPP hardware-integration vendor of choice to provide this as part of their 6/7/8G head-end system, in such a way that any device leased an IP by said head-end could make use of it.
What would such a standard look like?
Well, we're talking about a vendor-neutral, architecture-neutral abstract machine runtime, tuned to host persistent, network-mobile, IO-bound, highly-concurrent workloads "cheaply" on a highly-multitenant basis.
And Ericsson, one of the largest 3GPP equipment providers, created a runtime a few decades back that coincidentally fits that set of constraints quite closely — so closely, in fact, that they'd likely just vaguely wave at it and say "here, standardize this." (After giving its architecture a few security tweaks to achieve multitenant safety guarantees, that is.)
Just imagine: every mobile app on your iPhone, embedding its own little BEAM-bytecode relup package; one built by XCode, compiled from a combination of project source files written in a "network dialect" of Swift, plus Erlang library dependencies. And then pushed, on app launch, to a secure-multitentant Erlang VM sandbox, run by your ISP in its edge colo. Wouldn't that be just wild? ;)
On the telco side, as I understand it the CDN hosting isn't seen as a revenue centre - rather, it's there because it makes their pipe faster than the competition's (for the principle use cases of most of their customers, anyway).
Because Apple/Google can only run so many data centers. And these DCs are all too high-latency / "out of the way" of the connection path between the user's device and the devices it wants to talk to, to make "diverting" the connection path to one of these DCs worth it.
Besides that, though — doing such "diversions" would massively increase cost, because it would turn a one-backbone-path (or sometimes even zero-backbone-path) route into a two-backbone-path route.
Instead of,
userA → ispA → userB
userA → ispA → backbonePath → ispB → userB
userA → ispA → backbonePathA → Apple/Google → backbonePathB → ispB → userB
Now put yourself in Netflix's shoes. You don't want to deal with residential ISPs; they're usually large conglomerates that have more bargaining power than a random commercial colo facility in a city would have. But you do anyway. Why? Because, by doing so, you get a connection to the ISP's customers that is:
- extremely low latency
- extremely low bandwidth cost (because there's no need to traverse a backbone for any hop — the CDN's data can stay on the un-congested "residential streets" of the ISP, without ever needing to get on the "highway" where it would have to fan in and wait on an "on-ramp")
- never-degraded QoS — because their traffic on the residential ISP's network is just delivered with a default priority class (like everything else on that network, other than maybe the residential ISP's own OTT VoIP-based POTS service); whereas, when traversing any backbone, other providers who were willing to pay more per byte (because they had far fewer bytes to send and valued them more — which is basically every provider compared to a movie streaming service) get higher priority classes, narrowing the virtual pipe [= re-allocating to fewer circuits on circuit-TDMI backbone routers] and so degrading service for the CDNs whenever other higher-priority-rate traffic wants to flow.
The argument for Apple/Google putting their edge compute offload into residential ISP DCs would be exactly the same. It takes a network path that the customer was already establishing anyway, and adds a place for a "user-programmable virtual router" to live in that network path — without lengthening the path, making QoS worse, or any of that.
---
But let's go at this another way: if the cost/benefit worked out in favor of Apple/Google doing this in their own DCs... then why wouldn't they have already offered this years ago?
Apple might not be a B2B cloud provider that has hypervisor clusters ready for customer use — but Google certainly is. Why isn't "Android Offload Services, powered by Google Cloud Run on ARM" a thing?
What I said above (doing so creating a network "diversion", doubling backbone connections, wrecking QoS, etc) still applies.
But I think there's another obvious reason: if Apple/Google ran the DCs themselves, then this is something that would require that you pay Apple/Google a subscription fee for. Without a subscription fee, it'd just be a money pit — one a short-sighted CFO would either never green-light, or cancel after a single quarter.
And yet, a subscription model can't be the model used to support the very first instance of such a service at its inception, either. "Workload offload" is something with (currently) zero customer education behind it — i.e. it's something that customers would have absolutely no understanding of the value of, and so would never want to pay for, let alone sign up for a subscription they might not already be paying just to receive, until they see the value of it demonstrated in at least some other market, somewhere else.
These two properties create a seeming catch-22: given their corporate structures, Apple/Google can't subsidize it themselves; and given lack of user education, they can't immediately charge for it, either. So what do they do?
Well, if Apple/Google can talk someone else into hosting their compute racks, in such a way that the CapEx of deployment is Apple's/Google's, but the initial few years of OpEx and revenue for the effort winds up on that other party's balance sheets — then things could work. It wouldn't make money, but it also wouldn't (look like it's) costing Apple/Google any ongoing money — so they'd be able to keep the project going for its first few years, until user education played out and people started demanding it.
What properties would this "someone else" doing the hosting need to have?
Well, they'd need to be a near-commodity business, always in desperate need of "differentiators" to swing customers — i.e. new things that are nearly nothing for them to set up and run, but which they can then bundle into some subscription service they're charging customers for, such that having this feature makes their $60/mo plan look just ever-so-slightly more compelling than their competitors' $60/mo plans.
And they need to have a willingness to eat any short-to-medium-term OpEx costs associated with doing so, looking toward the long-term profits of such systems. They need a long demonstrated pattern of doing exactly this, over and over.
Ideally, they'd be paying virtually no "real" OpEx — as they'd already have some under-populated DCs laying around, with bulk-purchased power commitments and bandwidth provided as some kind of internal sweetheart deal.
Even more ideally, they'd have lobbyists who would get them massive government "technology evolution" subsidies for doing anything like this, that would more than pay the OpEx costs.
Know any companies like that? Because I sure do!
---
That being said, I would imagine that the math would work out slightly differently for different residential-ISP customer-base compositions.
It might be impossible to launch "workload offload" as a feature in the Bay Area or other tech-hubs at first, as those would be unprofitable if given away for free, due to the number of novelty-seeking nerds who'd actually make use of (apps that make use of) the service from day 1. The ISPs would likely get quite irritated if Apple/Google were coming into their DC to constantly rack more and more of these servers — even if the literal OpEx works out, they'd have to staff up their DC ops just to handle the increased hardware churn rate!
As such, I'd expect an ISP's workload-offload offering, to be something rolled out first in big cities that aren't tech hubs, and "proven out" there, mostly by users using the feature entirely unaware that they're doing so (because it's the app on your phone that decides to launch a workload, not you-the-user!)
Viral user education about the benefits of such services would filter out from such cities, to the rest of the world, where demand for them would build over the course of maybe... two years? — for ISPs to then start actually billing (and usage-based billing, with flat-rate billing only on premium data plans!) for the service.
It might work for a usecase you have in mind but in general, it can't work. And it assumes that the world is a perfect place where the incentives are aligned and that ISPs cooperates and that you'd actually want to expose your phone. As if the tech we have (mobile networks, phone batteries, coverage) would allow for it, which it don't.
And somehow denial of service attacks is only worth mentioning when you have a dedicated PC with proper 100+mbit internet but not when you have a battery powered phone with wireless connection?
And I truly fail to see how all anyone could even argue that all that complexity would be better than direct access.
You've made the internet safer for all of us.
I believe that IPv6 [1] is without a doubt coming in the future. Even with carrier grade NAT'ing and the likes, there are too many major providers who have already switched to single stack IPv6 natively.
That said, I agree that 240/4 is necessary to assist with the transition. Due to the fact that most network operators aren't even dealing with /24's, it becomes increasingly hard to facilitate bridges between the legacy IP and IPv6 so more IPv4 space is always appreciated (until the day we don't need to bridge at all).
[1] I may have a bias due to affiliation with https://IPv6.rs
The disappointment is there seems to be no difference between "needing a single open port" and "needing and entire IP address" due to overzealous egress firewall rules that everyone thought was good engineering practice 20 years ago.
edit: spelling
Aside: in this vernacular, plural of ox is oxen; plural of box is boxen. “boxens” is never appropriate.
And they're not wrong either, it by definition disables not just a whole class of (admittedly outdated) communication channels for malware (such as IRC), but also other stuff you don't want to happen on your network either: bittorrent, people running online games during work...
The main issue has always been the logistics of defining a brand new allocation policy that won’t run out of IPs in 6 months, because otherwise nobody is going to bother spending a bunch of money to support an address block which will most likely not even work anyways.
The first is, particularly on opening it up for public assignment, all of the compatibility issues mentioned. It's not enough that in 2035 99% of things could be compatible when talking about existing internet infrastructure - it has to be 100% going to work (without hoping everyone just catches up, this isn't a separate internet like IPv6's rollout is) if you want to bet interoperability of the established internet on it. The alternative is let people use it but not on the internet, that way they own their own interoperability with themselves or anyone directly interacting with their internal network. If this were a security issue I'd have different feelings on it but it's about convenience so it isn't enough that it's possibly more convenient to most 10 years from now. Especially since the problem and solutions will have evolved so much 10 years from now anyways.
The second reason is, even if it does work out 100%, it's not much a solution to anything anyways. IPv4 pressure has started causing places with large blocks of old IPv4 space moving to NAT, carries deploying double NAT via CG-NAT, cloud providers looking at public IPv4 address fees, and the entire mobile world being IPv6 first with some going as far as IPv6 only with NAT64. Each one of these solutions already in place has resulted in more usable IP space than this would open up so this solution could neither replace them or stop them from being needed in the future. Each existing alternative (however non-ideal) is either a longer term mitigation or step towards a long term solution to the shortage instead of a small basket of addresses to throw on the fire. In particular the NAT64 and 464xlat solution have proven to be a long term permanent answer for the vast majority of the cases people thought they needed these kinds of addresses for that would have left them less prepared when these too ran out. I particularly don't buy the idea that the world just so happens to need exactly a /4 more of space and everything would be alright - it only looks that way because of the above methods being pressured into happening. Remove that pressure and it (at best) can hope to delay the rollout numbers of those methods by a decade.
All that said I'm still in support of opening it up for private use cases like enabling 0.0.0.0/8 in Linux [2] did (think use cases like another /8 of space you can slap your Docker container NATs behind or your HA networks behind for software that doesn't support v6). Not only do I think that would result in less pain for the internet at large I think it would actually result in a larger decrease in IPv4 pressure long term by giving more spaces to NAT to/from for those not ready/able to NAT64 all of their internal services.
[1] https://news.ycombinator.com/item?id=39804231, https://news.ycombinator.com/item?id=32796355
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I'm not connected with this presentation (other than having talked to Ben about it prior to his giving it, and I guess supplying some of the information on software that accepts 240/4) but I am one of the people working on the project that he describes/criticizes.
Here is our current proposal.
https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...
People have been reacting to this with different forms of "just do IPv6" for many years. I guess we need an official statement about that somewhere. [Edit: other than these quick thoughts below...!]
I personally think IPv6 is great (I was excited about it in the late 1990s when it was standardized, and gave some talks to promote it, and am happy to see it getting deployed and happy to find myself using it sometimes). I hope people will keep working on it and networks and services will keep adopting it.
However, people's need for IPv4 address space depends enormously on other people's behavior. IPv6 addresses are not a good substitute for IPv4 addresses when you're providing a public service, if many of your users don't have IPv6. A high fraction of demand for IPv4 address resources appears to come from organizations and networks that already support IPv6, because they need dual-stack support for compatibility with other people.
Even though IPv6 adoption has been happening, it's easy to imagine that it's "almost done" where that really doesn't seem to be the case. (This is complicated by having very different statistics in different countries: some countries are now almost all IPv6 traffic, while others have almost no IPv6 -- so people in different parts of the world often have rather different intuitions about it.) We still see enormous economic demand for IPv4 address space and projections that IPv6 adoption to a point where IPv4 would somehow no longer be useful or important is likely still decades away. If that's correct¹, we can still get a benefit from making 240/4 usable because that process can be substantially complete during a time when IPv4 is still extremely important.
One thing that Ben (and one of the questioners at the end) argued in his presentation is that even if the adoption of IPv6 is unreliable or erratic, it might be more reliable than useful adoption of 240/4. (This was kind of phrased in the converse direction.) I'll have to think about models of that issue.
Edit: We have been sad when seeing how proposals to make 240/4 usable were made in 2008, but not adopted at IETF. Among things that people said in 2008 was that IPv6 would make this irrelevant quickly. That turned out not to be right, but we lost years of opportunity to make 240/4 more useful in the meantime, where billions of devices shipped in the interim could easily have supported it by default. So, we still have the opportunity not to have the same sense of regret in 2035.
¹ I'm also aware that there are other projections here; I recently interviewed a prominent Internet greybeard figure who theorized that Internet infrastructure growth as a whole has slowed so much that IPv4 demand may be satisfied in the future out of gradual conversion of residential ISPs to using primarily carrier-grade NAT for IPv4, and then selling off their number resources. In this account, IPv4 will remain important on the Internet for a long time, but economic demand for addresses will decline because most users won't have native IPv4 at home or on their mobile devices (the latter already the case in many networks). The economic demand for IPv4 resources is something that has made reclaiming 240/4 appear worthwhile, so in this model it would become less exciting, even without having IPv4 "go away".