Re: Alternative Re: ipv4/25s and above Re: 202211201702.AYC

["Abraham Y. Chen" <aychen () avinta com>]

Dear Mathew:

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.
Regards,


Abe (2022-11-21 09:49 EST)


On 2022-11-20 16:15, Matthew Petach wrote:
> On Fri, Nov 18, 2022 at 7:53 PM Abraham Y. Chen <aychen () avinta com> wrote:
>
>     Dear Owen:
>
>     1) "... Africa ... They don’t really have a lot of alternatives.
>     ...":
>     Actually, there is, simple and in plain sight. Please have a look
>     at the
>     below IETF Draft:
>
>     https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
>
> Hi Abraham,
>
> I know I'm not the sharpest tool in the shed, but I'm having some
> trouble understanding the deployment model for EzIP. Perhaps you
> could help clear it up for me?
>
> A non-EzIP web server is only going to see the global destination
> IP address and TCP port number as the unique session identifiers
> for communication, so the vast amount of additional IP space you
> postulate existing behind the SPR functionally collapses down into
> the 64K TCP port range available today in traditional port-based NAT
> setups.  As long as the top 50 websites aren't EzIP-aware, there appears
> to be no benefit for an ISP to deploy EzIP, because it doesn't actually
> gain them anything beyond what existing CG-NAT devices already provide
> as far as their web-browsing customer base is concerned. Most of their
> communication will still be port-based-NAT, with all the headaches and
> restrictions inherent in that.
>
> And for the top 50 websites, there's a lot of expense and absolutely 
> no upside
> involved in deploying EzIP.  They don't care about how much IP space 
> you have
> behind your NAT device, and whether it's uniquely identifiable within 
> your local
> realm; it's not information they can access for tracking users, as 
> they don't know
> what your internal mapping is, so they'll continue to rely on browser 
> cookies and
> the like for tracking actual user sessions, regardless of the IP 
> addressing format
> being used.
>
> So, you've got a model where there's functionally almost no benefit to 
> the end user
> until the major websites start deploying EzIP-aware infrastructure, 
> and there's
> pretty much no incentive for major websites to spend money upgrading 
> their
> infrastructure to support EzIP, because it provides no additional 
> benefit for them.
>
> This is pretty much exactly the same conundrum that IPv6 faced (and 
> still faces
> today).  I don't see why EzIP is any better than IPv6 or CG-NAT in 
> terms of solving
> the IPv4 address shortage problem, and it seems to involve more 
> expense for web
> providers, because it requires them to deploy additional SPR mapping 
> routers into
> their infrastructure in order to use it, with essentially no 
> additional benefit.
>
> Is there a piece to the picture I'm not understanding correctly?
>
> Thanks!
>
> Matt


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com