<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style> </head> <body dir="ltr"> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <div style="color:black; font-size:12pt; font-family:Calibri,Arial,Helvetica,sans-serif"> Torbjorn,</div> </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);"> I would like to add one more thing, it is not obvious that any equipment that cannot support IPv6 will not support IPv4+ , and I also believe that it is incorrect because adding a completely new protocol (IPv6+) to a low-resources IoT device (that might not planned initially with additional hardware resources to support a new protocol) is completely different than the IoT device just to handle the exact same number of bits of IPv4 packet - just differently - no additional physical hardware is needed like RAM (and even without an upgrade, the IoT device will work in the internet exactly like is working now).<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> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div id="appendonsend"></div> <hr style="display:inline-block;width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Elad Cohen <elad@netstyle.io><br> <b>Sent:</b> Saturday, April 25, 2020 10:42 PM<br> <b>To:</b> Torbj�rn Ekl�v <torbjorn.eklov@interlan.se><br> <b>Cc:</b> Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net><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> <style type="text/css" style="display:none">  </style> <div dir="ltr"> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> Torbjorn,</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)"> Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses.<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 homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them.<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)"> Hosts will be upgraded using the automatic update mechanism of their operating system.<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> <div id="x_appendonsend"></div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Torbj�rn Ekl�v <torbjorn.eklov@interlan.se><br> <b>Sent:</b> Saturday, April 25, 2020 10:36 PM<br> <b>To:</b> Elad Cohen <elad@netstyle.io><br> <b>Cc:</b> Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net><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 class="x_BodyFragment"><font size="2"><span style="font-size:11pt"> <div class="x_PlainText">Stuart, <br> More IPv4 will not make the transition faster.<br> If you and other have equipment that can�t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can�t be patched for.<br> The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that.<br> <br> /T<br> <br> <br> > On 25 Apr 2020, at 21:13, Elad Cohen <elad@netstyle.io> wrote:<br> > <br> > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother).<br> > <br> > Regarding the number of devices:<br> > � Any routing device with more than two physical routes<br> > � Any BGP router<br> > � Any operating system<br> > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses).<br> > <br> > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6).<br> > <br> > Respectfully,<br> > Elad<br> > From: Stuart Willet (primary) <stu@safehosts.co.uk><br> > Sent: Saturday, April 25, 2020 10:01 PM<br> > To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net<members-discuss@ripe.net><br> > Subject: 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<br> > <br> > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+.<br> > There are also many firewalls, both hardware and software which would need updating but can already use IPv6.<br> > <br> > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects.<br> > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices.<br> > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.<br> > <br> > Best,<br> > Stuart Willet.<br> > <br> > From: members-discuss [<a href="mailto:members-discuss-bounces@ripe.net">mailto:members-discuss-bounces@ripe.net</a>] On Behalf Of Elad Cohen<br> > Sent: 25 April 2020 19:56<br> > To: noc xervers <noc@xervers.pt>; members-discuss@ripe.net<br> > Subject: 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<br> > <br> > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned.<br> > <br> > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers.<br> > <br> > switches are working on layer2, they are not related to ip.<br> > <br> > Respectfully,<br> > Elad<br> > <br> > From: noc xervers <noc@xervers.pt><br> > Sent: Saturday, April 25, 2020 9:48 PM<br> > To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net><br> > Subject: 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<br> > <br> > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them.<br> > It's a better and cleaner solution to move to IPv6.<br> > <br> > Cheers.<br> > <br> > <image001.jpg><br> > NOC xervers | +351 300 404 316<br> > P Please consider the environment before printing this email<br> > <image002.jpg> <image002.jpg><br> > <image002.jpg> <image003.jpg><br> > <br> > <br> > De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen<br> > Enviada: s�bado, 25 de abril de 2020 20:21<br> > Para: members-discuss@ripe.net<br> > Assunto: [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<br> > <br> > Hello Everyone,<br> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])<br> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > 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> > <br> > Respectfully,<br> > Elad<br> > _______________________________________________<br> > members-discuss mailing list<br> > members-discuss@ripe.net<br> > <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a><br> > Unsubscribe: <a href="https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se"> https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40interlan.se</a><br> <br> </div> </span></font></div> </div> </body> </html>