<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><font size="4" face="monospace">Dear
Pascal:</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">0)
Thanks for your clarification. It enabled me to study your draft
a little closer and came up with the following observations to
share.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">1) "</font><font
size="4" face="monospace">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.": <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"> 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. <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"> <a
class="moz-txt-link-freetext"
href="https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space">https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space</a></font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">2) </font><font
size="4" face="monospace">" <a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#section-1"
class="section-number selfRef">1. </a><a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-introduction-and-motivation"
class="section-name selfRef">Introduction and Motivation</a>
The proposed benefit is a thousandfold increase of the
IPv4-addressable domain by building parallel realms each
potentially the size of the current Internet.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"> </font><font
size="4" face="monospace">"</font><font size="4"
face="monospace"><a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#section-2.2"
class="section-number selfRef">2.2. </a><a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-new-terms"
class="section-name selfRef">New Terms</a> <br>
This document often uses the following new terms:<br>
<span class="break"></span></font>
<blockquote>
<dl class="dlCompact dlParallel" id="section-2.2-2">
<li><font size="4" face="monospace">IPv4 realm:</font></li>
</dl>
<dl>
<li><font size="4" face="monospace">A full IPv4 network like
the current Internet. YADA does not affect the traditional
IPv4 operations within a realm.": <br>
</font></li>
</dl>
</blockquote>
<font size="4" face="monospace"> </font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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? <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">3) "
<a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#section-1"
class="section-number selfRef">1. </a><a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-introduction-and-motivation"
class="section-name selfRef">Introduction and Motivation</a>
.... </font><font size="4" face="monospace">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, .... ": <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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.</font></div>
<font size="4"> <font face="monospace"> </font> <font
face="monospace"> <br>
4) "<a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#figure-2"
class="selfRef">Figure 2</a>: <a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-yada-format-in-the-source-r"
class="selfRef">YADA format in the source realm</a> YADA also
requires a change for the routers that serve the shaft.": <br>
<br>
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? <br>
</font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">5) "<a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#figure-4"
class="selfRef">Figure 4</a>: <a
href="https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html#name-yada-format-inside-the-shaf"
class="selfRef">YADA format inside the shaft</a> ": <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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) </font><font size="4" face="monospace"> 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.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">6)
Below is my quick digest and comparison of our two projects by
partially paraphrasing YADA terminology: <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
C. The EzIP scheme is less capable than YADA, but much more
concise and well-defined: <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
a. Instead of multiple realms, each capable of full IPv4
addresses, EzIP works within only one set of IPv4 address pool.
<br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
b. EzIP starts from only realm 1 which occupies a subset of
IPv4 addresses (the full IPv4 pool minus 240/4 netblock).</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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.<br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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. <br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">
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.</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">Please
comment.</font></div>
<font size="4"> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">Regards,</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<font size="4"> <font face="monospace"> </font> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace">Abe
(2022-04-21 17:37 EDT)<br>
</font></div>
<font size="4"> </font>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4" face="monospace"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4" face="monospace">On
2022-04-20 03:20, Pascal Thubert (pthubert) wrote:</font><br>
</div>
<blockquote type="cite"
cite="mid:CO1PR11MB4881B431CF74E8A85A178AB3D8F59@CO1PR11MB4881.namprd11.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">Dear Abe:
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. Which is where the inner/outer terminology comes from. All very classical. We could do an over-UDP variation if people want it.
I used a condensed format to focus the reader on the addresses that get swapped; also the visualization clarifies that there cannot be options between the outer header and the inner headers.
The only routers that need to understand the fact that this is more than a plain tunnel are the routers that connect the realm to the shaft, because they have to check that the realm address is correct and do the address swap between inner and outer.
The first version of the draft impacted routers for BCP 38 procedures, this is now changed. The routers inside a realm can keep operating unmodified, and there's no need to deploy new policies for ingress filtering.
Keep safe;
Pascal
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-----Original Message-----
From: Abraham Y. Chen <a class="moz-txt-link-rfc2396E" href="mailto:aychen@avinta.com"><aychen@avinta.com></a>
Sent: vendredi 15 avril 2022 0:47
To: Pascal Thubert (pthubert) <a class="moz-txt-link-rfc2396E" href="mailto:pthubert@cisco.com"><pthubert@cisco.com></a>
Cc: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:nanog@nanog.org">nanog@nanog.org</a>
Subject: Re: Ready to compromise? was RE: V6 still not supported
Dear Pascal:
1) I had a quick look at the below updated draft. I presume Figure 2 is
intended to address my request. Since each IPv4 address has 4 bytes, what
are the 12 bytes allocated for IPv4 header fields (outer) and (inner),
each? Aren't they the standard first 12 bytes of packet identifier in an
IPv4 header? If so, why not show it straightforward as defined by RFC791?
2) If my above assumption is correct, you are essentially prefixing the
packet identifying portion (inner) of an IPv4 header with another one (the
"outer"), without making use of the existing Options words like my EzIP
proposal. How could any existing routers handle a packet with this new
header format, without any design related upgrade? If you do expect
upgrade, it would appear to me as too much to ask. Am I missing something?
Regards,
Abe (2022-04-14 18:46)
On 2022-04-08 10:34, Pascal Thubert (pthubert) wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Dear all
Following advice from thus list, I updated the YADA I-Draft (latest
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">ishttps://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html,
more to come soon if feedback is heard) and proposed it to the v6ops WG at
the IETF.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">For memory, the main goal here is to find a compromise as opposed to yet
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">another transition solution, though it can be used as a side effect to
move along the ladder. The compromise does not change IPv4 or IPv6, tries
not to take side for one or the other, and add features to both sides
which, if implemented, reduce the chasm that leads to dual stack and CG-
NATs.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">There's value for the movers, lots more public address space for the
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">IPv4-only stack/networks and free prefixes per node and new deployment
opportunities for the IPv6-only ones.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">One major update from the original text accounts for Dave's comment in
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">this list on BCP 38 enforcement, I believe it's solved now. I also added
format layouts to Abe Chen's question, and text on the naïve version vs.
all the elasticity that exists there and in IP in general to allow real
world deployments.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Comments welcome, here and/or at v6ops for those who participate there.
Many thanks in advance;
Pascal
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">--
This email has been checked for viruses by Avast antivirus software.
<a class="moz-txt-link-freetext" href="https://www.avast.com/antivirus">https://www.avast.com/antivirus</a>
</pre>
</blockquote>
</blockquote>
<p><br>
</p>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>