<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 26, 2022, at 06:35 , Abraham Y. Chen <<a href="mailto:aychen@avinta.com" class="">aychen@avinta.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class="">
    <div class="moz-cite-prefix"><font size="4" class="">Hi, Owen:</font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">0)    Re: Ur. Pt. 2):   
        This topic is such a tongue-twister. Let's put it aside for now,
        until I can properly convey the EzIP concept and scheme to you.</font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">00)    Re: Ur. Pt.
        4):    Okay, I was concerned about how to decipher this
        cryptic exchange. So let's put it aside as well.<br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">1)    Re: Ur. Pt. 1):   
        Yes, you are correct that the EzIP network architecture looks
        like that of CG-NAT. In fact, it is exactly the same. This is
        actually the beauty of the EzIP solution. That is, without
        touching the hardware, by implementing the EzIP technique (<b class=""><i class="">disabling</i></b>
        the program code that has been <b class=""><i class="">disabling</i></b> the use
        of the 240/4 netblock), an existing CG-NAT module becomes a RAN!
        As to universal peer-to-peer, where is any of such today? On the
        other hand, upon fully implemented the EzIP proposal (the second
        phase: making use of the Option Word in RFC791), an IoT in one
        RAN can directly reach a second IoT in another RAN world-wide.
        So that the original promise of the Internet will be finally
        fulfilled and for the long haul.<br class=""></font></div></div></div></blockquote><div><br class=""></div><span style="font-size: 16px;" class="">The fact that we gave up universal peer to peer in the name of survival until we could deploy a protocol with enough addresses doesn’t mean that giving it up is a good long term solution.</span></div><div><span style="font-size: 16px;" class=""><br class=""></span></div><div><font size="3" class="">To me, the goal is to get away from address scarcity as quickly as possible. IPv6 does that. EzIP doesn’t. I have no desire to support prolonging the misery that has existed since NAT became popular. I view it as a disability to the internet and IPv6 eliminates that disability. EzIP arguably makes it even worse. So, what you call beauty is, IMHO, damage.</font></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><div class="moz-cite-prefix"><font size="4" class="">
      </font></div>
    
    <div class="moz-cite-prefix"><font size="4" class="">2)    Re: Ur. Pt. 3):   
        Similarly, you probably only recognized the part that EzIP
        proposes to classify the 240/4 netblock as the fourth private
        address in RFC1918, but overlooked that such capacity will
        enable a RAN to cover a geographic area as big as Tokyo Metro,
        or 75% of smaller countries around the world, even before
        utilizing the conventional three private netblocks. This puts
        240/4 into a different league from the other three conventional
        private netblocks, although all four have basically the same
        technical characteristics. Now, visualizing each RAN is tethered
        from the existing Internet core by one umbilical cord (one IPv4
        address), it appears like a private network. So that each RAN
        can provide Internet services by utilizing existing
        technologies, while avoiding those undesired. Combining these
        RANs around the world, an <b class=""><i class="">overlay</i></b> layer of
        routers (SPRs) can operate in parallel to the current Internet.
        Under such a configuration, the latter no long is involved with
        daily local activities, but only carries inter-RAN traffic, very
        much like the division between national and international
        telephone networks. This creates quite a different operation
        landscape. Please have a look at slide # 11 of the below
        whitepaper for a rough breakdown of the available addresses
        under the EzIP scheme. Furthermore,
        if used diligently, (treating IP address as "<b class=""><i class="">natural
            resources</i></b>" instead of "<b class=""><i class="">personal properties</i></b>"),
        the assignable "EzIP addresses" can last quite awhile.<br class=""></font></div></div></div></blockquote><div><br class=""></div><span style="font-size: 15px;" class="">I didn’t overlook it, I routed around it as damage in the truest of internet traditions. Geographical-based addressing hierarchies have been proposed before. They have a long history of failing in the face of actual topology and actual operational concerns. This doesn’t look significantly different to me. It’s yet another entirely bad idea which serves only to prolong the IPv4 misery while diverting resources from useful work to enable the deprecation of IPv4 as the lingua franca of the internet backbone.</span></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="moz-cite-prefix"><font size="4" class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">    <a class="moz-txt-link-freetext" href="https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf">https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf</a> 
        <br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">3)    Re: Ur. Pts. 5)
        & 6):    I believe that there is a philosophic / logic
        baseline that we need to sort out, first. That is, we must keep
        in mind that the Internet community strongly promotes "<b class=""><i class="">personal
            freedom</i></b>". Assuming that by stopping others from
        working on IPv4 will shift their energy to IPv6 is totally
        contradicting such a principle. A project attracts contributors
        by its own merits, not by relying on artificial barriers to the
        competitions. Based on my best understanding, IPv6 failed right
        after the decision of "not emphasizing the backward
        compatibility with IPv4". It broke one of the golden rules in
        the system engineering discipline. After nearly three decades,
        still evading such fact, but defusing IPv6 issues by various
        tactics is the real impedance to progress, not only to IPv4 but
        also to IPv6.</font></div></div></div></blockquote><div><br class=""></div><span style="font-size: 17px;" class="">I’m not stopping anyone from anything. I’m stating that I believe resources would be better spent deploying IPv6 than being wasted on this project. Anyone who disagrees with me is, of course, free to waste their resources however they see fit.</span></div><div><span style="font-size: 17px;" class=""><br class=""></span></div><div><span style="font-size: 17px;" class="">In terms of backwards compatibility, there’s absolutely no way to do it. It’s mathematically impossible to squeeze a 128 bit address into a 32 bit field. Every system needed to be upgraded to handle 128 bit addresses at the OS, application, and all other layers of software. Routers needed upgrades to hardware for fast switching as well. That was inevitable in any increase in the address space. Claiming that IPv6 failed because of this “decision” is pretending that there was a decision to be made which presumes an alternative existed. The only way this could be achieved would be to abandon the end-to-end principle and permanently consign the internet to a fate involving widespread NAT. I’m very glad that decision was deemed unacceptable and I still believe it to be the right one.</span></div><div><span style="font-size: 17px;" class=""><br class=""></span></div><div><span style="font-size: 17px;" class="">Owen</span></div><div><span style="font-size: 17px;" class=""><br class=""></span></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">Regards,</font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class=""><br class="">
      </font></div>
    <div class="moz-cite-prefix"><font size="4" class="">Abe (2022-03-26 09:35
        EDT)     <br class="">
      </font></div>
    <div class="moz-cite-prefix"><br class="">
    </div>
    <div class="moz-cite-prefix"><br class="">
    </div>
    <div class="moz-cite-prefix"><br class="">
    </div>
    <div class="moz-cite-prefix">On 2022-03-25 22:17, Owen DeLong wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:53375421-2B10-49A1-885C-E7021C3E40DA@delong.com" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
      <br class="">
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">On Mar 25, 2022, at 18:47 , Abraham Y. Chen <<a href="mailto:aychen@avinta.com" class="moz-txt-link-freetext" moz-do-not-send="true">aychen@avinta.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8" class="">
            <div class="">
              <div class="moz-cite-prefix">******  Resend to go through
                NANOG ******<br class="">
              </div>
              <div class="moz-cite-prefix"><br class="">
              </div>
              <div class="moz-cite-prefix"><br class="">
              </div>
              <div class="moz-cite-prefix">On 2022-03-25 12:24, Abraham
                Y. Chen wrote:<br class="">
              </div>
              <blockquote type="cite" cite="mid:876ec3d8-83d6-7efd-ea05-127f167d8f55@avinta.com" class="">
                <meta http-equiv="Content-Type" content="text/html;
                  charset=UTF-8" class="">
                <div class="moz-cite-prefix"><font class="" size="4">Dear
                    Owen:</font></div>
                <div class="moz-cite-prefix"><font class="" size="4"><br class="">
                  </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">0)   
                    You rapid fired a few posts in succession yesterday.
                    Some are interesting and crucial views that I would
                    like to follow-up on. I will start from quoting the
                    earlier ones. I hope that I am picking up the
                    correct leads.<br class="">
                  </font></div>
                <div class="moz-cite-prefix"><font class="" size="4"><br class="">
                  </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">1)   
                    " ... 240/4 is way more effort than its proponents
                    want to believe and even if it were reclassified
                    effectively as GUA, it doesn’t buy all that much
                    life for IPv4. ...   ":     Perhaps you have not
                    bothered to scan through a two page whitepaper (URL
                    below, again) that I submitted a week or so ago? It
                    promises simple implementation and significant
                    increase of assignable IPv4 addresses, even
                    extendable to the similar size of IPv6 if we could
                    forgo our mentality about the IP addresses as
                    "Personal Properties", by switching to treat them as
                    "Natural Resources".<br class="">
                  </font></div>
                <div class="moz-cite-prefix"><font class="" size="4"><br class="">
                  </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">  
                       <a class="moz-txt-link-freetext" href="https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf" moz-do-not-send="true">https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf</a><br class="">
                  </font></div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        It still looks like NAT to me.</div>
      <div class=""><br class="">
      </div>
      <div class="">NAT is a disgusting hack and destroys the universal peer to
        peer nature of the internet in favor of a consumer/provider
        model.</div>
      <div class=""><br class="">
      </div>
      <div class="">Your proposal perpetuates that problem.</div>
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">
            <div class="">
              <blockquote type="cite" cite="mid:876ec3d8-83d6-7efd-ea05-127f167d8f55@avinta.com" class="">
                <div class="moz-cite-prefix"><font class="" size="4"> </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">2)   
                    " ...  so that content providers can start turning
                    off v4 where it’s costing them money to support it.
                    ....   " & "... Content providers turning off v4
                    face competition from content providers that don’t.
                    ...  ":    These two statements appeared to come
                    from two separate posting of yours. They seemed to
                    be contradicting each other. Did I misread somehow?<br class="">
                  </font></div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        No, it is not contradictory at all…</div>
      <div class=""><br class="">
      </div>
      <div class="">Content providers that have deployed IPv6 are eager to turn
        off IPv4 as soon as it won’t lose them customers. They are
        worried about losing customers because competition exists that
        might not turn off IPv4 at the same time they do. Thus, there is
        a need for customers to be IPv6 deployed before content
        providers can start turning off IPv4. Thus, the persistence of
        IPv4 in clients, especially enterprises, is costing content
        providers money.</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <blockquote type="cite" class="">
          <div class="">
            <div class="">
              <blockquote type="cite" cite="mid:876ec3d8-83d6-7efd-ea05-127f167d8f55@avinta.com" class="">
                <div class="moz-cite-prefix"><font class="" size="4"> </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">Now
                    from the last post below:</font></div>
                <div class="moz-cite-prefix"><font class="" size="4"><br class="">
                  </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">3)   
                    "  ... 240/4 is way more effort than its proponents
                    want to believe and even if it were reclassified
                    effectively as GUA, it doesn’t buy all that much
                    life for IPv4....   ": Please see information
                    provided by Pt. 1) above.</font></div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        OK, so you want to extend RFC-1918 instead… Arguably even more
        worthless than reclassifying it as GUA. While it’s true that
        some very large deployments are short of RFC-1918 space, the
        reality is that the real shortage is in the GUA realm.</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <blockquote type="cite" class="">
          <div class="">
            <div class="">
              <blockquote type="cite" cite="mid:876ec3d8-83d6-7efd-ea05-127f167d8f55@avinta.com" class="">
                <div class="moz-cite-prefix"><font class="" size="4">4)   
                    " ... I think it should be reclassified from never
                    going to be used into some part of the internet
                    might actually do something with it. Its important
                    that happens now, better late then never ... Please
                    feel free to use it for router IDs in BGP and/or
                    OSPF area numbers. :p ...    ":    I am in full
                    agreement with you. Our proposal is the solution in
                    Pt. 1) above.</font></div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        That’s not me. That’s Joe Maimon IIRC. My part was “Pleas feel
        free to use it for router IDs in BGP and/or OSPF area numbers.
        :p.</div>
      <div class=""><br class="">
      </div>
      <div class="">It was mostly a snarky comment since neither BGP Router IDs
        nor OSPF Area numbers are actually IP addresses.</div>
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">
            <div class="">
              <blockquote type="cite" cite="mid:876ec3d8-83d6-7efd-ea05-127f167d8f55@avinta.com" class="">
                <div class="moz-cite-prefix"><font class="" size="4">5)   
                    "  ...  if we continue to waste effort that is
                    better spent deploying IPv6 on bandaids and hacks to
                    make v4 last just a little longer, .... ":    This
                    is not a productive opinion. Please do not forget
                    that the Internet heavily promotes personal freedom.
                    One can not force others to do something that they
                    do not believe in. Stopping them from doing one
                    thing does not automatically make them to do what
                    you like. A project must have its own merits that
                    attract contribution. The failure of the IPv6
                    actually started from when a decision was made to
                    the effect of "not to emphasize backward
                    compatibility with IPv4" which broke one of the
                    golden rules in system engineering. Not recognizing
                    such and focusing to find a way for remedying it,
                    but continuing to force others to migrate to IPv6
                    camp with various tactics does not foster progress.<br class="">
                  </font></div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        We can agree to disagree about that… I think trying to continue
        to support IPv4 is not a productive opinion.</div>
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">
            <div class="">
              <blockquote type="cite" cite="mid:876ec3d8-83d6-7efd-ea05-127f167d8f55@avinta.com" class="">
                <div class="moz-cite-prefix"><font class="" size="4"> </font></div>
                <div class="moz-cite-prefix"><font class="" size="4">6)   
                    "  ... The problem is that we’re not talking about
                    parallel experiments. ... ":    EzIP is a parallel
                    experiment to the current Internet (not only IPv4,
                    but also IPv6) operations, because its overlay
                    architecture on the latter demarcates everything
                    happening on it from the Internet. As long as
                    packets exchanged between the two conform to the
                    established Internet protocols, an EzIP deployment
                    (called RAN - Regional Area Network) will appear as
                    innocent as an ordinary private network.<br class="">
                  </font></div>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        Again, I disagree… You left out the relevant part of my quote
        where I stated that resources spent developing this mechanism
        are better used deploying IPv6.</div>
      <div class=""><br class="">
      </div>
      <div class="">Owen</div>
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class=""> </div>
        </blockquote>
      </div>
      <br class="">
    </blockquote><p class=""><br class="">
    </p>
  <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" class=""><br class="">
<table style="border-top: 1px solid #D3D4DE;" class="">
        <tbody class=""><tr class="">
        <td style="width: 55px; padding-top: 13px;" class=""><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" class=""><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;" class=""></a></td>
                <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;" class="">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;" class="">www.avast.com</a>
                </td>
        </tr>
</tbody></table><a href="x-msg://39/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1" class=""> </a></div></div>

</div></blockquote></div><br class=""></body></html>