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 <ayc...@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
