<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi,</p>
    <p><br>
    </p>
    <p>"Where is the space in the header ? there isn't any reliable
      space in the header to increase the source address number or the
      destination address number"<br>
      <br>
    </p>
    <p> There is place in the same places you suggest in your "IPv4+"
      proposal ;)<br>
      Quite frankly, it's been nearly 10 years since i looked into this
      and i do not deal at *that* level often, but i do recall there
      being possibility to add the few bytes required to header, instead
      of data segment.</p>
    <p>Quite frankly, it *does not* matter where in the packet that data
      is -- what matter is *most convenient* position. This is a
      technical detail which can be solved by those far more
      knowleadgable than i am on every single nuance -- I am not
      qualified to decide this nor does it need to be decided now.</p>
    <p><br>
    </p>
    <p>"In order for the router to look at the 2 additional bytes, the
      router will need to have its firmware upgrade, so every LAN router
      in the world will need to have its firmware upgrade."</p>
    <p><br>
    </p>
    <p>Incorrect! Only end points like i said. Instead of going on full
      attack mode instantly, perhaps try to read and comprehend and work
      with others. You complain you are being attacked, but what i see
      you are acting a bit like that yourself. Instead of attacking and
      complaining, people should try to work together by sharing ideas
      to get to the best possible outcome. Not "My Way or No Way!"
      mentality.</p>
    <p><br>
    </p>
    <p>Whatever the chosen location for the 2 or 4 additional bytes
      which does not get "scrubbed" on route only the end points need to
      support those. Route like normal, no changes, traverse like
      normal, until you get to the 11.11.12.1 which needs to understand
      beyond this, same with everything after that.</p>
    <p><br>
    </p>
    <p>"firmware-upgrade all the routers in the world - an impossible
      task"<br>
      But magically possible for your IPv4+ proposal, just not my call
      it "IPv4e" as in IPv4 extended. Not a problem at all to make every
      single device support in the world support when it is your
      proposal?</p>
    <p><br>
    </p>
    <p>Also not required on "IPV4e".<br>
    </p>
    <p><br>
    </p>
    <p>Hell, even not all clients do not need to understand on IPv4e the
      extension. On outgoing packets (from 11.11.12.1.1.1) non-enabled
      device sees a packet from 11.11.12.1 and responds to it normally,
      with NAT like code can handle the extension translation on the
      11.11.12.1 switch :)<br>
      Albeit granted non-enabled end device will need network stack code
      updated to open directly a connection with extended address, but
      vice-versa it's not requirement.</p>
    <p><br>
    </p>
    <p>ZERO BGP changes required. ZERO routing changes. Extensions would
      always be considered L2 on grander scale, and the extension cannot
      be split (avoids more routing table fragmentation and growth).
      Within the extension routing can still be done, no need to have
      all the extension in single subnet, just not on the grander scale.
      Needed upgrades: End point switch/router where extension begins,
      and switches and devices behind that. ie. only accrue cost and
      hassle for the amount you want to extend to -- and only for new
      installs.<br>
      Let's be real here tho, a decade old switch *will* not get an
      update like this, nor might have the power to do the additional
      lookups, but you do not need to update your whole network at once
      -- only where you want to use this.<br>
    </p>
    <p><br>
    </p>
    <p>Essentially you can decide whether or not to extend from /32 at
      all, or full /16 worth of addresses. Hell, if you want you can
      only use it on single device to map every software on their own IP
      instead of just port or something interesting like that :) Or you
      can have /16 worth of devices beyond it. All up to the end point!</p>
    <p><br>
    </p>
    <p>Speaking of which mobile networks now relying on NAT could
      additionally offer extended IP to end devices, in case the device
      supports it and needs direct connectivity. Same for all other NAT
      networks out there.<br>
    </p>
    <p><br>
    </p>
    <p>Clients will need software updates to access these more or less,
      but there will always be potential for partial connectivity even
      on non supported devices, without any work for the client side.<br>
    </p>
    <p>There will always be devices running Windows XP still. There will
      always be super old non-updated legacy devices, no matter what
      route you take.</p>
    <p><br>
    </p>
    <p>As there is no additional cost for client, server, BGP level etc.
      it could start to begin slowly by those who most needs it and
      adoption would grow slowly over time, which increases level of
      connectivity. There is after all connectivity between regular IPv4
      and an extended one.<br>
      Typical office PC, mobile device etc. will get quick updates
      however typically, so getting a huge number of supported devices
      online will happen relatively quick (1 year?) -- all is needed
      Linux kernel update, and microsoft and apple to do the same and
      eventually you will have vast majority of devices supported with
      no additional changes -- no need to change switches, firewalls
      etc.</p>
    <p><br>
    </p>
    <p>So this would end up being more of a software engineering
      exercise than wholesale router upgrades at huge scale. Router
      manufacturers will probably be happy to support as they get to
      sell more hardware then, or even justify significantly higher cost
      for IPv4e devices ;)</p>
    <p><br>
    </p>
    <p>So from my perspective, i see very little friction to do
      something like this -- everyone wins and it's quite minimal effort
      to implement or not to implement in most use cases.<br>
    </p>
    <p><br>
    </p>
    <p>-Aleksi<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 4/26/20 12:57 AM, Elad Cohen wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DB7PR10MB2154E4D7145BAC790C010C8FD6D10@DB7PR10MB2154.EURPRD10.PROD.OUTLOOK.COM">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Aleksei,</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Regarding:</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        "Server (11.11.11.1) sends packet with additional header data
        (there is space for this!)"</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Where is the space in the header ? there isn't any reliable
        space in the header to increase the source address number or the
        destination address number</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Where in the ip header are the two additional bytes for the
        source address and the two additional bytes for the destination
        address ?<br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Regarding:<br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        "Router at 11.11.12.1 gets this packet, looks inside the header
        and notices the 2 additional bytes and forwards this to client
        at LOCAL 11.11.12.1.1.1 (L2 lookup)"<br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        In order for the router to look at the 2 additional bytes, the
        router will need to have its firmware upgrade, so every LAN
        router in the world will need to have its firmware upgrade.<br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        In case you will explain where are the additional two bytes for
        the source address and the destination address (there isn't any
        reliable place, many routers will drop the ip packet due to it
        unless you will firmware-upgrade all the routers in the world -
        an impossible task) - then the additional ip addresses are only
        for current existing LANs (new ASNs will need to have ip
        addresses from the first /32 which do not exist due to the lack
        of IPv4, networks will need to be restructured to free the first
        /32 , but main problem with it is that there is no reliable
        place for additional two bytes for the source address and
        additional two bytes for the destination address, that the ip
        packets will always pass - with the changes that were made to
        them - in each and every router in the world that wasn't
        upgraded)<br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Regarding:</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        "Proposal by Elad would require hardware level changes on all
        routers everywhere before being of any use, so sadly i think it
        will not get any traction."</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        This is not correct - hardware level changes will not be needed
        on any router, only a software update (which is a firmware
        upgrade) and not on every router in the world - only in bgp
        routers and in any non-bgp routers which have more than two
        physical routers (NAT routers that will use an external IPv4+
        address and not an IPv4 will also need to be upgraded, any
        router in the routing path which is using filtering based on the
        source or destination addresses - will also need to have a
        firmware upgrade), any homerouter or home modem will not need to
        be updated (these are the vast majority of networking equipment
        in the world).<br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Respectfully,</div>
      <div style="font-family: Calibri, Arial, Helvetica, sans-serif;
        font-size: 12pt; color: rgb(0, 0, 0);">
        Elad<br>
      </div>
      <hr style="display:inline-block;width:98%" tabindex="-1">
      <div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
          face="Calibri, sans-serif" color="#000000"><b>From:</b>
          members-discuss <a class="moz-txt-link-rfc2396E" href="mailto:members-discuss-bounces@ripe.net"><members-discuss-bounces@ripe.net></a> on
          behalf of Aleksi <a class="moz-txt-link-rfc2396E" href="mailto:aleksi@magnacapax.fi"><aleksi@magnacapax.fi></a><br>
          <b>Sent:</b> Sunday, April 26, 2020 12:25 AM<br>
          <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:members-discuss@ripe.net"><members-discuss@ripe.net></a><br>
          <b>Subject:</b> Re: [members-discuss] Technical solution to
          resolve the IPv4 Exhaustion problem and to add more 4, 294,
          967, 296 IPv4 addresses that are needed in the world</font>
        <div> </div>
      </div>
      <div>
        <p>Hi,</p>
        <p><br>
        </p>
        <p> This is interesting, but it would also possible to add more
          "extensions" -- only end side nodes needs to be upgraded on
          software level only, client which sends the data, and the
          regular IPv4 address receiver. No need for backbone level
          *hardware* upgrades for this.<br>
          <br>
          Extend with 2 additional ie.
          [0-255].[0-255].[0-255].[0-255].[0-255].[0-255]<br>
          Would be the new maximum on base software.<br>
          <br>
          Example:<br>
          Server is 11.11.11.1<br>
          Client is 11.11.12.1.1.1<br>
          Router at 11.11.12.1<br>
          <br>
          Server (11.11.11.1) sends packet with additional header data
          (there is space for this!) with 2 additional bytes for the
          extension address.<br>
          Router at 11.11.12.1 gets this packet, looks inside the header
          and notices the 2 additional bytes and forwards this to client
          at LOCAL 11.11.12.1.1.1 (L2 lookup)<br>
          <br>
          Intermediate switches between router and client do not need to
          understand this, only end to end, and the router (which could
          be software driven so 1st step only a linux kernel module!)<br>
        </p>
        <p><br>
          BGP or routing does not need changes, as no routes of extended
          addresses are being announced nor allowed to be announced.
          Therefore each final /32 can be extended by equivalent of /16
          with very minimal work -- initially only software upgrades on
          each side.</p>
        <p><br>
        </p>
        <p>For years i've been wondering why no one has proposed this,
          so simple and elegant with minimal hardware investment. *none*
          of the bloat on IPv6, just a very simple extension. No
          performance drawbacks on routing level, only "end points" need
          to support it.<br>
        </p>
        <p><br>
        </p>
        <p>Then again, i would wish also maximum packet size to be
          increased by order of magnitude(s).</p>
        <p>Proposal by Elad would require hardware level changes on all
          routers everywhere before being of any use, so sadly i think
          it will not get any traction.</p>
        <p>My proposal is unlikely to get any traction either, as it's
          not to the benefit of big players (who currently holds vast
          quantities of unused IPv4 address space). I just keep
          wondering why no one would come up with such a simple idea.
          This could be done at higher than L3 even -- but atleast
          initially would be essentially "L3.5" somewhere between L3 and
          L4...
          <br>
        </p>
        <br>
        <br>
        <p>-Aleksi<br>
          Magna Capax Finland</p>
        <p><br>
        </p>
        <div class="x_moz-cite-prefix">On 4/25/20 9:20 PM, Elad Cohen
          wrote:<br>
        </div>
        <blockquote type="cite">
          <style type="text/css" style="display:none">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
          <div style="font-family:Calibri,Arial,Helvetica,sans-serif;
            font-size:12pt; color:rgb(0,0,0)">
            <span>Hello Everyone,<br>
            </span>
            <div><br>
            </div>
            <div>I want to share with you my technical solution to the
              "IPv4 Exhaustion" problem (without to upgrade each and
              every router that exist in the internet), using the below
              implementation there will be more 4,294,967,296‬ IPv4
              addresses that the world needs so much:<br>
            </div>
            <div><br>
            </div>
            <div>Currently in an IPv4 packet - the source address and
              the destination address are being represented each by four
              bytes, each of these four bytes are being displayed as:
              [0-255].[0-255].[0-255].[0-255]<br>
            </div>
            <div><br>
            </div>
            <div>But it is up to us to choose how we want to display
              them, for example: four bytes can also be displayed as
              [0-65535].[0-65535] (two numbers and one dot, the two
              numbers are bigger because in total they also being
              represented as four bytes)<br>
            </div>
            <div><br>
            </div>
            <div>So there can be one set of 4,294,967,296‬ IPv4
              addresses (the one that we know in the display format of
              [0-255].[0-255].[0-255].[0-255])<br>
            </div>
            <div><br>
            </div>
            <div>and another set of 4,294,967,296 IPv4 addresses (with a
              new format of [0-65535].[0-65535])<br>
            </div>
            <div><br>
            </div>
            <div>We need to have a mark, a flag, in the ip packet header
              - in order to know if the source address is of the old
              formatting (IPv4) or of the new formatting (lets call it
              IPv4+), for that mark the 'reserved bit' in the ip header
              can be used, so in case the source address is of IPv4+ or
              in case that the destination address is of IPv4+ (or in
              case that both the source and destination addresses are of
              IPv4+) then the reserved bit in the ip header will be set
              to 1 , we then also need to know exactly if the source
              address is of IPv4+ or not (meaning of IPv4) and if the
              destination address is of IPv4+ or not (meaning of IPv4) -
              this can be done by marking the DF flag if the source
              address is of IPv4+ (and not marking the DF flag if the
              source address is of IPv4) and marking the MF flag if the
              destination address is of IPv4+ (and not marking the MF
              flag if the destination address is of IPv4), by using the
              DF and MF bits which are related to fragmentation
              (whenever the reserved bit is set to '1') we are losing
              the ip fragmentation functionality for any traffic with an
              IPv4+ address (for traffic between two IPv4 addresses, the
              reserved bit is not set to '1' and hence optional ip
              fragment functionality is unchanged)<br>
            </div>
            <div><br>
            </div>
            <div>We need to know the MTU before an IPv4+ packet will be
              sent, because no fragmentation will be able to be done
              with IPv4+ , the current "Path MTU Discovery" (RFC 1191)
              is not good for that case because it is using the DF bit
              which we are using as well (and in IPv4+ traffic a DF flag
              set to 1 is marking that the source address is of IPv4+),
              and also ICMP protocol can be blocked by routers in the
              routing path, the solution is to send multiple udp
              requests (with fixed known MTU sizes) to the destination
              address (lets call it IPv4+ handshake) - the destination
              address may or may not receive them (in case a router in
              the routing path have multiple upstreams and wasn't
              upgraded to an upper version that supports IPv4+ then it
              will not recognize the reserved bit and the DF and MF bits
              related to it, it will not recognize the new IPv4+
              addresses and even if the reserved bit is set to '1' and
              MF flag is set to '1' in the ip packet - it will route to
              to the destination address just like it is an IPv4 address
              and not IPv4+ address, meaning to a completely different
              destination address) - in case the destination address
              indeed received the IPv4+ packets - it will send back the
              udp requests to the source address at the exact same sizes
              (with the reserved bit flag set to '1' and with the DF and
              MF flags set accordingly) - when the source address will
              receive them - the source address will know that the
              destination address is supporting IPv4+ , that ip packets
              with new IPv4+ formatting will reach the destination and
              the source address will know what is the biggest size of
              the udp request that was received - and it will be the MTU
              for that specific connection between the source and the
              destination addresses (The IPv4+ handshake will be done
              again if there is no response from the destination after
              the initial udp handshake was already completed
              successfully).<br>
            </div>
            <div><br>
            </div>
            <div>The udp handshake between a source address and a
              destination address (that any of them or them both is an
              IPv4+ address) will use a specific udp port, an availalbe
              unassigned port between 0 to 1023, an operating system
              networking stack (that was updated for IPv4+ with the
              operating system automatic updating system) will know
              exactly what this udp port is for - and will react
              accordingly, the upgraded operating system networking
              stack will also check that the destination address (in the
              IPv4 or in the IPv4+ format) is set locally in the
              operating system, before sending the udp requests back to
              the source address (if not then the ip packet will be
              dropped by the upgraded operating system networking
              stack). Any operating system that wasn't upgraded to
              support IPv4+ - will just drop that kind of udp requests.<br>
            </div>
            <div><br>
            </div>
            <div>IPv4+ is fully backward compatible to IPv4 (and any
              router that was not upgraded yet to IPv4+ will not cause
              IPv4 traffic to break), it is also not adding any new
              fields to ip packets or using new fields, IPv4+ will not
              cause any performance overload for any supported router.<br>
            </div>
            <div><br>
            </div>
            <div>The reason that the MF and DF bits are being use for
              IPv4+ and not the ToS / IP-ID / Options in ip header are
              being used is because we cannot be 100% sure that the ToS
              / IP-ID / Options in the ip header will not be changed or
              dropped by any rouer in the routing path that wasn't
              upgraded to IPv4+ (and we don't want to upgrade any router
              in the world because it is an impossible mission) - in the
              ip header ToS is being cleared by some routers - IP-ID can
              be changed by NAT routers - Options field is dropped by
              many routers, we can trust that the DF and MF flags will
              not be modified in the routing path by routers that
              weren't upgraded to IPv4+.<br>
            </div>
            <div><br>
            </div>
            <div>For the above solution not all the internet devices in
              the world needs to be patched/upgraded to support IPv4+
              which is an impossible mission, end-users operating
              systems need to be upgraded (but it can be done simply
              using their automatic updating system), BGP routers (and
              any router with multiple physical routing paths) will need
              to have its firmware upgraded to support IPv4+, any NAT
              router that will want to use an external IPv4+ address
              will need to have its firmware upgraded (any NAT router
              that will use an external IPv4 address will not need to
              have its firmware upgraded, only the internet devices in
              the LAN of the NAT router will need to have a single
              operating system update in order for them to access IPv4+
              addresses in the internet), any home router (not NAT) or
              home modem will not need to have a firmware upgrade and
              IPv4+ functionality will be transparent to them.
              <br>
            </div>
            <div><br>
            </div>
            <div>The deployment of IPv4+ can be fairly easy and very
              fast, a round table of one person from each one of the 5
              RIRs and from each one of the operating systems vendors
              and from each one of the router manufacture vendors. Even
              if IPv4+ will be deployed over time, it will not cause the
              internet to break (devices that need to be upgraded to
              IPv4+ and didn't yet will work exactly as they are now
              with IPv4, they will just not yet support IPv4+).<br>
            </div>
            <div><br>
            </div>
            <div>The above will resolve the "IPv4 Exhaustion" problem
              and will bring to each one of the 5 RIRs almost
              900,000,000 new IPv4+ addresses that will be able to the
              provided to the LIRs worldwide, if you have any question
              please let me know.<br>
            </div>
            <div><br>
            </div>
            <div>Respectfully,<br>
            </div>
            <span>Elad</span><br>
          </div>
          <br>
          <fieldset class="x_mimeAttachmentHeader"></fieldset>
          <pre class="x_moz-quote-pre">_______________________________________________
members-discuss mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net" moz-do-not-send="true">members-discuss@ripe.net</a>
<a class="x_moz-txt-link-freetext" href="https://mailman.ripe.net/" moz-do-not-send="true">https://mailman.ripe.net/</a>
Unsubscribe: <a class="x_moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi" moz-do-not-send="true">https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi</a>
</pre>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>