<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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="moz-cite-prefix">On 4/25/20 9:20 PM, Elad Cohen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR10MB2154195DC25D0E53D0472FC4D6D10@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);">
<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="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
members-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a>
<a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/listinfo/members-discuss">https://lists.ripe.net/mailman/listinfo/members-discuss</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi">https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi</a>
</pre>
</blockquote>
</body>
</html>