<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>