0) Thanks for raising a very valid observation. Your line of reasoning and conclusion including the conundrum that IPv6 faces do conform with my understanding of the current Internet conventions and practices. However, this is only following the track that most people have been conditioned into. If one practices "think out of the box" while examining EzIP, as marketers frequently like to say, you may come to a totally different perspective. That is, if you do not mind to flip a few coins along the way, even though individually may seem insignificant by itself, the accumulated effect can change the story. Allow me to go through the analysis that helped us to solidify the EzIP plan.
1) What you identified was a serious hurdle that stumbled us for quite awhile after we initially worked out the scheme of making use of the long-reserved 240/4 netblock to expand the publicly assignable IPv4 pool. It turned out that being a novice to the Internet, we tried too hard by trapping ourselves into literally attempting to achieve the end-to-end connectivity as well, immediately. By approaching the issue via the "Divide and Conquer" principle, the latest EzIP deployment strategy has been broken into two phases. The first is basic (obvious necessity) and straightforward. The second is optional (since it is more than the current Internet capable of) and requiring some efforts. However, both bypass the "top 50 websites" issue that you are concerned with. In a nutshell, they will never see EzIP, if they do not intend to be involved.
2) The above is hard to visualize if you followed the bulk of the EzIP IETF Draft because its initial intent was to present the full EzIP technique and configuration for the long term which may not be universally needed based on our latest analysis. If you start reading the EzIP Draft from Appendix F and on that were added upon our realization of the above trade-off, you will get the sense that the "top 50 websites" are not necessarily part of the considerations. This is because the RAN (Regional Area Network) which is architecturally the same as an existing CG-NAT "module" (pardon me for not knowing the correct terminology of an area served by a 100.64/10 netblock), but much (64 times) larger. Consequently, a RAN can be self-contained for all practical purposes and collectively behave as a Sub-Internet. That is, the port translation at the highest level of a CG-NAT module does not need be disturbed upon the address transition. Similarly, the "Revamp The Internet" whitepaper was written after we realized this two-phase approach. So, it focused only on phase one.
3) The first phase of EzIP deployment will be only replacing the 100.64/4 netblock of RFC6598 with the 240/4 netblock. This process can be achieved by just activating the use of the 240/4 netblock by the existing networking equipment. (This could be as simple as disabling one line of the code in a networking program that has been disabling the use of the 240/4 addresses.) The CG-NAT operations will not be perturbed. Since this transition will be confined within a RAN (replacing a few CG-NAT modules), the operation of distributed caching proxies used by the "top 50 websites" to support the CDN (Content Delivery Network) business configuration remain the same. So, the "top 50 websites" would not sense any changes due to EzIP deployment. One important benefit of this step is that static addresses may now be administrated to streamline daily operations that harden the defense against cyber intrusions.
4) Once the above is done, there is a practical intermediate phase before attempting the worldwide end-to-end connectivity which has been elusive for the existing Internet. That is, since each RAN can be fairly large (Even without making use of private netblocks from RFC1918, each 240/4 can serve an area with the population as big as Tokyo Metro or over 75% of smaller countries around the world.), subscribers within each RAN can begin to enjoy end-to-end connectivity such as direct eMail exchanges. This is equivalent to domestic postal mails and telephony calls which are what ordinary citizens would care about most of the time, anyway. At this phase, no new capability is offered across RAN boundaries. Current eMail facility (which is by store and forward anyway) and similar will continue for such needs.
5) Next, if anyone really cares for exchange messages directly with someone remote (beyond the local RAN), the full EzIP header format will be utilized (Remember the dial-up modem supported direct PC connections via international phone calls over the worldwide PSTN?). Still, the "top 50 websites" can continue their operations unaffected, unless they want to be more directly interacting with individuals in such activities.
6) Since the root of each RAN is connected to the Internet core via a public IPv4 address channel, the former can be regarded as a private network. This does not preclude RANs from establishing direct links (via 240/4 or spare public IPv4 address) among one another. With such, an overlay network covering the entire globe can be formed with its own "top websites" that will function as a cyberspace that is parallel to, but practically independent of, the existing Internet.
7) In summary, the EzIP deployment is consciously planned to be incremental while avoiding disturbing the existing Internet configurations and practices.
8) Since we are still refining the EzIP scheme, the above outline may not be fully self-consistent. Please let me know any parts that are not clear. I will try to improve them.
Abe (2022-11-21 09:49 EST)