Dear Pascal:
0) Thanks for your clarification. It enabled me to study your draft a little closer and came up with the following observations to share.
1) "Yes, this is plain IP in IP. For a router does not know about YADA, this looks like the most basic form of tunnel you can get.":
Not really\. I believe that any networking stack conforming to the Options mechanism in RC791 can achieve the same, thus more concise and less involved\. Please see Figure 4 of EzIP Draft\.
2) " 1. <Yet Another Double Address and Translation Technique>Introduction and Motivation <Yet Another Double Address and Translation Technique> The proposed benefit is a thousandfold increase of the IPv4-addressable domain by building parallel realms each potentially the size of the current Internet.
"2.2. <Yet Another Double Address and Translation Technique>New Terms <Yet Another Double Address and Translation Technique>
This document often uses the following new terms:
# IPv4 realm:
# A full IPv4 network like the current Internet. YADA does not affect
the traditional IPv4 operations within a realm.":
These are the critical statements that led to one of my two initial questions. That is, are you proposing to have N (>250 as an example cited in your draft) realms that each has the full IPv4 address pool capacity (after deducted for certain special functions)? This will be fine if each realm was occupying one floor of a stand-alone skyscraper. I can not visualize this architecture when it is expanded to cover the whole earth, since each of them can operate with all the IPv4 addresses. Not only physically impossible to build such a skyscraper, but also how can we form 250 independent overlays on top of the entire IPv4 based Internet? Is there any mechanism that can isolate the respective transmission media of the 250 realms from one another?
3) " 1. <Yet Another Double Address and Translation Technique>Introduction and Motivation <Yet Another Double Address and Translation Technique> .... Connectivity between an IPv4-only node and an IPv6-only node, or between an IPv4-only node and a YADA node in different realm, still requires a CG-NATs as of today, .... ":
Since eliminating the CG-NAT practice is one of the general motivations for address expansion efforts, I am puzzled by why are you still keeping it, and for how long? In contrast, upon the initial RAN (Regional Area Network) deployment, the CG-NAT will be retired from EzIP environment.
4) "Figure 2 <Yet Another Double Address and Translation Technique>: YADA format in the source realm <Yet Another Double Address and Translation Technique> YADA also requires a change for the routers that serve the shaft.":
Are you saying that an IoT in a realm wishing to communicate with another in a separate realm does not need to know about this format nor something equivalent to convey such inter\-realm address information?
5) "Figure 4 <Yet Another Double Address and Translation Technique>: YADA format inside the shaft <Yet Another Double Address and Translation Technique> ":
This particular format closely resembles that of EzIP (see EzIP Draft Figure 4 mentioned above), where "outer IPv4 header" part of five words carrying the two realms' address information are conveyed by words 4 & 5 of a standard IPv4 header, while the IoT (inner) addresses are transported by three Options words. The EzIP format enables the EzIP implementation to stay within the RFC791 specifications, no need to go beyond.
6) Below is my quick digest and comparison of our two projects by partially paraphrasing YADA terminology:
A. Since there is no way to build a 250 floor skyscraper covering the entire globe for physical isolation between floors (realms), it is difficult to visualize how could the same IP address be used by 250 separate parties as proposed by YADA without the fundamental address conflict issue. How to provide a medium that has 250 fully isolated layers, each capable of transporting the full set of IPv4 addresses, seems to be the challenge.
B. The function of YADA format probably can be achieved by making use of the Options mechanism under RFC791, so that IP header can stay basic.
C. The EzIP scheme is less capable than YADA, but much more concise and well-defined:
a. Instead of multiple realms, each capable of full IPv4 addresses, EzIP works within only one set of IPv4 address pool.
b. EzIP starts from only realm 1 which occupies a subset of IPv4 addresses (the full IPv4 pool minus 240/4 netblock).
c. Realm 2 thru realm N are called RAN (Regional Area Network), each reusing a full IPv4 subset of the 240/4 netblock. They are physically isolated from one another by restricted use within respective geographical boundaries.
d. Instead of a big elevator shaft threading trough all N floors of the realms, Each RAN is individually tethered as a kite from realm 1 (the current Internet core) via just one (or more if needed) IPv4 address.
e. After enough RANs are deployed, their boundaries begin to touch one another. So that, direct paths between the RANS may be established. Thus, an overlay of new networks is formed covering the entire globe for becoming a parallel cyberspace to the current Internet core (realm 1). The two can operate independently and interact only at arm's length via the umbilical cords, when needed.
D. Unlike YADA & YATT, EzIP has not specifically considered its application to IPv6. Although, the feasibility of expanding a finite sized address pool such as IPv4, demonstrates that EzIP is equally capable of expanding the IPv6 that still has a lot of unassigned addresses.
Please comment.
Regards,
Abe (2022-04-21 17:37 EDT)