Hi, anyhow this is not the right list to discuss this. You need to create an RfC – but as IPv6 already exist there is no real chance of implementing this I would say. Michael Von: members-discuss <members-discuss-bounces@ripe.net> Im Auftrag von noc xervers Gesendet: Samstag, 25. April 2020 20:49 An: 'Elad Cohen' <elad@netstyle.io>; members-discuss@ripe.net Betreff: [SPAM] 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <https://www.xervers.pt/> <https://www.facebook.com/xervers/> <https://twitter.com/xervers> <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net 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 Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. 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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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 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. 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. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers <noc@xervers.pt> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net> 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website]<https://www.xervers.pt/> [Image removed by sender. Facebook] <https://www.facebook.com/xervers/> [Image removed by sender. Twitter]<https://twitter.com/xervers> [Image removed by sender. TrustPilot] <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net 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 Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad

Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP's? What about bigger ISP's ad Tier 1's? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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 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). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system 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). 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). Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. 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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 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. 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. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website]<https://www.xervers.pt/> [Image removed by sender. Facebook] <https://www.facebook.com/xervers/> [Image removed by sender. Twitter]<https://twitter.com/xervers> [Image removed by sender. TrustPilot] <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces@ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad

Atif, Regarding what you wrote that deployment will not be straight forward, the deployment of the solution can be very fast, a round table of 50 people (each representing another RIR and operating system vendor and routing equipment manufacturer) - each will receive an amount of IPv4+ addresses, each ISP and ASN will also receive an amount of IPv4+ addresses. Once the operating systems will be updated - there will be pressure from end-users to ISP's why specific IPv4+ site is not loading and then any routing equipment in the routing path that wasn't upgraded will be upgraded (ASN's will receive IPv4+ addresses to upgrade their routing equipment quickly, for example X number of ip addresses if upgrade is up to one month, half of X number of ip addresses if upgrade is up to two months, double the amount of X number of ip addresses if upgrade is in one week, for example. The 'udp handshake' method can be used to know if any router of an ASN was upgraded IPv4+ or not and based on it to measure and to provide to the ASN operator the specific number of IPv4+ addresses). Respectfully, Elad ________________________________ From: Atif Naveed <a.naveed@go.com.sa> Sent: Saturday, April 25, 2020 10:30 PM To: Stuart Willet (primary) <stu@safehosts.co.uk>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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 Dear Stuart, Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path . Regards Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed@go.com.sa www.go.com.sa<http://www.go.com.sa> From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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 Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP’s? What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 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). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system 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). 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). Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. 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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 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. 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. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website]<https://www.xervers.pt/> [Image removed by sender. Facebook] <https://www.facebook.com/xervers/> [Image removed by sender. Twitter]<https://twitter.com/xervers> [Image removed by sender. TrustPilot] <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces@ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad

Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 11:04 PM To: Atif Naveed <a.naveed@go.com.sa>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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 Dear Atif, Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. I’m not sure there is a Tier1 who doesn’t offer IPv6. Most UK ISP’s now provide IPv6 by default to people’s homes. I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. Why would the uptake be faster for IPv4+? Best, Stuart Willet. From: Atif Naveed [mailto:a.naveed@go.com.sa] Sent: 25 April 2020 20:30 To: Stuart Willet (primary) <stu@safehosts.co.uk>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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 Dear Stuart, Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path . Regards Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed@go.com.sa www.go.com.sa<http://www.go.com.sa> From: members-discuss <members-discuss-bounces@ripe.net<mailto:members-discuss-bounces@ripe.net>> On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP’s? What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 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). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system 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). 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). Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. 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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 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. 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. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website]<https://www.xervers.pt/> [Image removed by sender. Facebook] <https://www.facebook.com/xervers/> [Image removed by sender. Twitter]<https://twitter.com/xervers> [Image removed by sender. TrustPilot] <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces@ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad

Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov@interlan.se> Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen <elad@netstyle.io> Cc: Stuart Willet (primary) <stu@safehosts.co.uk>; Atif Naveed <a.naveed@go.com.sa>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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 Elad,

Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4.

No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It’s more complicated and more time consuming than deploying IPv6.

(IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today)

Yes, it’s "new“ but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 11:04 PM To: Atif Naveed <a.naveed@go.com.sa>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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

Dear Atif,

Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. I’m not sure there is a Tier1 who doesn’t offer IPv6. Most UK ISP’s now provide IPv6 by default to people’s homes.

I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. Why would the uptake be faster for IPv4+?

Best,

Stuart Willet.

From: Atif Naveed [mailto:a.naveed@go.com.sa] Sent: 25 April 2020 20:30 To: Stuart Willet (primary) <stu@safehosts.co.uk>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

Dear Stuart,

Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users.

So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so.

And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path .

Regards

Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed@go.com.sa www.go.com.sa<http://www.go.com.sa>

From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software.

What about all the L3 switches and routers not owned by ISP’s? What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21?

Honestly, the update alone is unfeasible, especially when we already have fully working IPv6.

On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware.

Best, Stuart Willet.

From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

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

Regarding the number of devices: • Any routing device with more than two physical routes • Any BGP router • Any operating system 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).

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

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net<members-discuss@ripe.net> 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

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6.

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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.

Best, Stuart Willet.

From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

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.

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.

switches are working on layer2, they are not related to ip.

Respectfully, Elad

From: noc xervers <noc@xervers.pt> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net> 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

That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6.

Cheers.

<image001.jpg> NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <image002.jpg> <image002.jpg> <image002.jpg> <image003.jpg>

De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net 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

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte...

Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell <campbell@inca.ie> Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen <elad@netstyle.io> Cc: Torbjörn Eklöv <torbjorn.eklov@interlan.se>; members-discuss@ripe.net <members-discuss@ripe.net> 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 IPv6 isn’t slow because of the lack of trying, it is slow because of Microsoft et al’s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a “nice to have” “feature” attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this “new” IPv4 space, that just doesn’t track with the current demand for addressing. You’d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen <elad@netstyle.io> wrote:  Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov@interlan.se> Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen <elad@netstyle.io> Cc: Stuart Willet (primary) <stu@safehosts.co.uk>; Atif Naveed <a.naveed@go.com.sa>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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 Elad,

Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4.

No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It’s more complicated and more time consuming than deploying IPv6.

(IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today)

Yes, it’s "new“ but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 11:04 PM To: Atif Naveed <a.naveed@go.com.sa>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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

Dear Atif,

Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. I’m not sure there is a Tier1 who doesn’t offer IPv6. Most UK ISP’s now provide IPv6 by default to people’s homes.

I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. Why would the uptake be faster for IPv4+?

Best,

Stuart Willet.

From: Atif Naveed [mailto:a.naveed@go.com.sa] Sent: 25 April 2020 20:30 To: Stuart Willet (primary) <stu@safehosts.co.uk>; Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

Dear Stuart,

Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users.

So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so.

And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path .

Regards

Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed@go.com.sa www.go.com.sa<http://www.go.com.sa>

From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software.

What about all the L3 switches and routers not owned by ISP’s? What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21?

Honestly, the update alone is unfeasible, especially when we already have fully working IPv6.

On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware.

Best, Stuart Willet.

From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

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

Regarding the number of devices: • Any routing device with more than two physical routes • Any BGP router • Any operating system 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).

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

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net<members-discuss@ripe.net> 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

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6.

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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.

Best, Stuart Willet.

From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

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.

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.

switches are working on layer2, they are not related to ip.

Respectfully, Elad

From: noc xervers <noc@xervers.pt> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net> 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

That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6.

Cheers.

<image001.jpg> NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <image002.jpg> <image002.jpg> <image002.jpg> <image003.jpg>

De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net 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

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte...

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

Hi, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss <members-discuss-bounces@ripe.net> Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen <elad@netstyle.io>; Ed Campbell <campbell@inca.ie> Cc: members-discuss@ripe.net Betreff: 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 Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> > Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell <campbell@inca.ie <mailto:campbell@inca.ie> > Cc: members-discuss@ripe.net <mailto:members-discuss@ripe.net> Assunto: 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 Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad _____ From: Ed Campbell <campbell@inca.ie <mailto:campbell@inca.ie> > Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> > Cc: Torbjörn Eklöv <torbjorn.eklov@interlan.se <mailto:torbjorn.eklov@interlan.se> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@ripe.net <mailto:members-discuss@ripe.net> > 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 IPv6 isn’t slow because of the lack of trying, it is slow because of Microsoft et al’s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a “nice to have” “feature” attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this “new” IPv4 space, that just doesn’t track with the current demand for addressing. You’d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> > wrote:  Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad _____ From: Torbjörn Eklöv <torbjorn.eklov@interlan.se <mailto:torbjorn.eklov@interlan.se> > Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> > Cc: Stuart Willet (primary) <stu@safehosts.co.uk <mailto:stu@safehosts.co.uk> >; Atif Naveed <a.naveed@go.com.sa <mailto:a.naveed@go.com.sa> >; noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@ripe.net <mailto:members-discuss@ripe.net> > 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 Elad,

Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4.

No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It’s more complicated and more time consuming than deploying IPv6.

(IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today)

Yes, it’s "new“ but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk <mailto:stu@safehosts.co.uk> > Sent: Saturday, April 25, 2020 11:04 PM To: Atif Naveed <a.naveed@go.com.sa <mailto:a.naveed@go.com.sa> >; Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@ripe.net <mailto:members-discuss@ripe.net> > 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

Dear Atif,

Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. I’m not sure there is a Tier1 who doesn’t offer IPv6. Most UK ISP’s now provide IPv6 by default to people’s homes.

I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. Why would the uptake be faster for IPv4+?

Best,

Stuart Willet.

From: Atif Naveed [mailto:a.naveed@go.com.sa] Sent: 25 April 2020 20:30 To: Stuart Willet (primary) <stu@safehosts.co.uk <mailto:stu@safehosts.co.uk> >; Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> 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

Dear Stuart,

Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users.

So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so.

And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path .

Regards

Atif Naveed Sr. Specialist IGW/ISP Core Network Operations D:+966-11511-1263 E:a.naveed@go.com.sa www.go.com.sa

From: members-discuss <members-discuss-bounces@ripe.net <mailto:members-discuss-bounces@ripe.net> > On Behalf Of Stuart Willet (primary) Sent: Saturday, April 25, 2020 10:21 PM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> 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

Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software.

What about all the L3 switches and routers not owned by ISP’s? What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21?

Honestly, the update alone is unfeasible, especially when we already have fully working IPv6.

On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware.

Best, Stuart Willet.

From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk <mailto:stu@safehosts.co.uk> >; noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> 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

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

Regarding the number of devices: • Any routing device with more than two physical routes • Any BGP router • Any operating system 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).

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

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk <mailto:stu@safehosts.co.uk> > Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net%3cmembers-discuss@ripe.net> <members-discuss@ripe.net> 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

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6.

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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.

Best, Stuart Willet.

From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> 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

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.

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.

switches are working on layer2, they are not related to ip.

Respectfully, Elad

From: noc xervers <noc@xervers.pt <mailto:noc@xervers.pt> > Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io <mailto:elad@netstyle.io> >; members-discuss@ripe.net <mailto:members-discuss@ripe.net> <members-discuss@ripe.net <mailto:members-discuss@ripe.net> > 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

That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6.

Cheers.

<image001.jpg> NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <image002.jpg> <image002.jpg> <image002.jpg> <image003.jpg>

De: members-discuss <members-discuss-bounces@ripe.net <mailto:members-discuss-bounces@ripe.net> > Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net <mailto:members-discuss@ripe.net> 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

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net <mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte...

_______________________________________________ members-discuss mailing list members-discuss@ripe.net <mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

Please see what I wrote, any home-router (without external NAT IPv4+ address) and any home-modem will not need to be updated, IPv4+ will work fine with them and will be transparent to them, non-technical end-users will not need to update anything, IPv4+ is using transparent adjustment to IPv4 packets and that kind of devices (home router without external NAT IPv4+ address, home modem and any routing equipment with no more than two physical routers - will not need to be updated). The update to all the end-users operating systems will be automatic, routers not owned by ISP's are home-routers as companies with routers have IT support (home routers will not need to be updated). NTT or Telia have millions of routers ? (I'm not sure about it) , any ISP that will receive pressure from his end-users (that their operating system was already upgraded through automatic update system) why the end-user cannot access a IPv4+ site will cause the ISP to update (if didn't update yet). And regarding the /21 - bigger ISP's with more routing devices to update will be able to receive more IPv4+ addresses, there will be more than 4 billion new IPv4 addresses. Even after big amount will be shared between the operating system vendors and the many ASN's - the 5 RIR's will have a huge amount of new IPv4 addresses (more than 800,000,000 per RIR). Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 10:20 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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 Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. What about all the L3 switches and routers not owned by ISP’s? What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. Best, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 25 April 2020 20:13 To: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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 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). Regarding the number of devices: * Any routing device with more than two physical routes * Any BGP router * Any operating system 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). 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). Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6. 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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. Best, Stuart Willet. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 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. 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. switches are working on layer2, they are not related to ip. Respectfully, Elad ________________________________ From: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Image removed by sender. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Image removed by sender. Visit our website]<https://www.xervers.pt/> [Image removed by sender. Facebook] <https://www.facebook.com/xervers/> [Image removed by sender. Twitter]<https://twitter.com/xervers> [Image removed by sender. TrustPilot] <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces@ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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 Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad

Torbjorn, 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. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov@interlan.se> Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen <elad@netstyle.io> Cc: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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 Stuart, More IPv4 will not make the transition faster. 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. 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. /T

On 25 Apr 2020, at 21:13, Elad Cohen <elad@netstyle.io> wrote:

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

Regarding the number of devices: • Any routing device with more than two physical routes • Any BGP router • Any operating system 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).

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

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net<members-discuss@ripe.net> 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

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6.

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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.

Best, Stuart Willet.

From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

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.

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.

switches are working on layer2, they are not related to ip.

Respectfully, Elad

From: noc xervers <noc@xervers.pt> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net> 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

That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6.

Cheers.

<image001.jpg> NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <image002.jpg> <image002.jpg> <image002.jpg> <image003.jpg>

De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net 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

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte...

Elad - Stuart, We try this way - First - Why didn’t you and anyone make this proposition for +10 years ago? This problem was known +20 years ago. Second - It’s to late. It will take more than three years to achieve this with every OS involved. And then it’s to late to make updates for ISP’s who didn’t upgrade their equipment. /Tobbe - end of my discussion PS. I live in Sweden where we only have +4% IPv6 but I hate our CGNAT!

On 25 Apr 2020, at 21:53, Elad Cohen <elad@netstyle.io> wrote:

Torbjorn,

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

Respectfully, Elad

From: Elad Cohen <elad@netstyle.io> Sent: Saturday, April 25, 2020 10:42 PM To: Torbjörn Eklöv <torbjorn.eklov@interlan.se> Cc: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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

Torbjorn,

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.

Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them.

Hosts will be upgraded using the automatic update mechanism of their operating system.

Respectfully, Elad From: Torbjörn Eklöv <torbjorn.eklov@interlan.se> Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen <elad@netstyle.io> Cc: Stuart Willet (primary) <stu@safehosts.co.uk>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net <members-discuss@ripe.net> 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

Stuart, More IPv4 will not make the transition faster. 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. 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.

/T

...

On 25 Apr 2020, at 21:13, Elad Cohen <elad@netstyle.io> wrote:

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

Regarding the number of devices: • Any routing device with more than two physical routes • Any BGP router • Any operating system 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).

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

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io>; noc xervers <noc@xervers.pt>; members-discuss@ripe.net<members-discuss@ripe.net> 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

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6.

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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.

Best, Stuart Willet.

From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt>; members-discuss@ripe.net 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

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.

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.

switches are working on layer2, they are not related to ip.

Respectfully, Elad

From: noc xervers <noc@xervers.pt> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net> 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

That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6.

Cheers.

<image001.jpg> NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <image002.jpg> <image002.jpg> <image002.jpg> <image003.jpg>

De: members-discuss <members-discuss-bounces@ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net 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

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte...

Michael, Please see my following answers: 1. No additional header bit is needed, the ip packet is exactly as it is now, the 'reserved bit flag' will just be '1' instead of '0' , the reserved bit is available in the ip header and hence the filter will see the whole ip packet. (any router that do any check regarding the source address or the destination - will need to be upgraded). 2. This is not a new protocol, IPv6 is a new protocol, it is an adjustment to a current protocol and not any device which implemented that protocol (IPv4) will need to be upgraded, providing IPv4 address (of IPv4+) to all the parties involved (when IPv4 addresses are so much needed in these days) and using the automatic updating mechanism of operating systems - can and will make this whole process much much faster. 3. It is an adjustment to a current protocol and not a completely new protocol, clean code updates will resolve it. There is no need to know what is the main protocol (IPv4+ or IPv4) because the exact same IPv4 packet is being used, upgraded routers will just know how to route it well (if the four bytes of source address are of IPv4 or IPv4+ and if the four bytes of destination address are of IPv4 or IPv4+). 4. Please see what I wrote, I didn't write that only some of the needed routers will be upgraded, I wrote that all the end-users operating systems will be updated (through the automatic updating mechanism of the operating systems). 5. We can argue on it, I believe that if companies and organizations will have a high pool of IPv4 then they will be able to support both IPv6 and IPv4 and then more and more companies and organizations will support both IPv4 and IPv6 until the whole internet will be able to move to only IPv6. IPv6 is being talked for 20 years and currently the world is in a very big problem because of the lack of IPv4. 6. From the very beginning with the round table and IPv4+ addresses incentives to everyone - IPv4+ will be deployed very very fast, I wrote about very margins cases, from the very beginning through the round table IPv4+ will be deployed (Automatic operating system updates will done only after the ISP's and ASN's will complete to update their routers and will receive their amount of free new IPv4 addresses). And just in case an ISP will assign to its user an IPv4+ addresses to use the internet then that IPv4+ addresses need to access the whole internet (there are many online services that are not yet supporting IPv6+). I'm not against IPv6 - I surely believe it is the future, but more IPv4 addresses are needed for and until IPv6 to be fully adapted. 7. Please write about any unanswered point. I don't believe that I'm late because 20 years ago there wasn't any need to use the 'reserved bit flag' in the ip header, it was intended for future use, and what would be a better use to the 'reserved bit flag' than to use it for the current IPv4 Exhaustion problem. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of info@cowmedia.de <info@cowmedia.de> Sent: Saturday, April 25, 2020 11:00 PM To: members-discuss@ripe.net <members-discuss@ripe.net> Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, i really appreciate your idea, but there are unfortunately some issues to this. 1. It requires an additonal header bit that is not part of the address itself, how would a filter know about this when there is only the ip address given (the bit it not available to them). 2. The time of developing and rollout a new type of protocol (what this is) takes years (maybe 10-15 years) even this is theoretically just a small change) 3. Configuring dual protocol is already with IPv4+6 sometimes a hard issue. There are issues with what protocol is the main one and how applications are using them 4. It is not enough to update only networking equipment because the application layer decides about the target (for example the browser via DNS), even today so many software is not compatible with IPv6, how would you expect them to include IPv4+? 5. IPv4+ would slow down IPv6 rollout 6. Your thinking about users will complain when sites are not reachable is not correct. ISPs and service owner make sure right now that the service is at least reachable by IPv4 and they are in the process of trying to add IPv6 to them. There is no way of having users not access any service just because a provider or any MITM is not yet ready. Hence IPv4+ will NEVER be solely rollout to any service. 7. Plus many more points that were raised. You are really 20 years too late. I am so sorry. Michael Von: members-discuss <members-discuss-bounces@ripe.net> Im Auftrag von Elad Cohen Gesendet: Samstag, 25. April 2020 21:42 An: Torbjörn Eklöv <torbjorn.eklov@interlan.se> Cc: members-discuss@ripe.net Betreff: [SPAM] 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 Torbjorn, 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. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov@interlan.se<mailto:torbjorn.eklov@interlan.se>> Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> Cc: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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 Stuart, More IPv4 will not make the transition faster. 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. 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. /T

On 25 Apr 2020, at 21:13, Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> wrote:

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

Regarding the number of devices: • Any routing device with more than two physical routes • Any BGP router • Any operating system 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).

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

Respectfully, Elad From: Stuart Willet (primary) <stu@safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Saturday, April 25, 2020 10:01 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<members-discuss@ripe.net<mailto:members-discuss@ripe.net%3cmembers-discuss@ripe.net>> 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

Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. There are also many firewalls, both hardware and software which would need updating but can already use IPv6.

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. 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. 2: it would not offer anywhere close to the amount of IPv6 addresses which already work.

Best, Stuart Willet.

From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 25 April 2020 19:56 To: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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

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.

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.

switches are working on layer2, they are not related to ip.

Respectfully, Elad

From: noc xervers <noc@xervers.pt<mailto:noc@xervers.pt>> Sent: Saturday, April 25, 2020 9:48 PM To: Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>>; members-discuss@ripe.net<mailto:members-discuss@ripe.net> <members-discuss@ripe.net<mailto:members-discuss@ripe.net>> 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

That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6.

Cheers.

<image001.jpg> NOC xervers | +351 300 404 316 P Please consider the environment before printing this email <image002.jpg> <image002.jpg> <image002.jpg> <image003.jpg>

De: members-discuss <members-discuss-bounces@ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss@ripe.net<mailto:members-discuss@ripe.net> 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

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40inte...

Thank you very much! I'm not against IPv6, but IPv6 transition will not be completed tomorrow and the current demand from companies and organizations worldwide is for IPv4 and not IPv6, I believe that IPv4+ will make the transition to IPv6 faster. Respectfully, Elad ________________________________ From: Bruno Cordioli <br1@br1.com> Sent: Saturday, April 25, 2020 9:53 PM To: Elad Cohen <elad@netstyle.io> Cc: members-discuss@ripe.net <members-discuss@ripe.net> 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 Hi Elad, I love your proposal, I would have liked to have heard it some time ago ... 20 years or someone more. But now we have to think about using ipv6, we have no more excuses. We must use IPv6 !!! br1 -- Bruno 'br1' Cordioli www.br1.com<http://www.br1.com> br1@br1.com<mailto:br1@br1.com> On Sat, Apr 25, 2020 at 8:36 PM Elad Cohen <elad@netstyle.io<mailto:elad@netstyle.io>> wrote: Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/br1%40br1.com

Sure. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Jens Link <lists@quux.de> Sent: Saturday, April 25, 2020 10:06 PM To: members-discuss@ripe.net <members-discuss@ripe.net> 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 Elad Cohen <elad@netstyle.io> writes: Elad, thanks for your input. Would yo be willing to present your ideas at the upcoming RIPE and IETF meeting? I would very much appreciate it. Thanks Jens

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/lists%40quux.de

-- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ---------------------------------------------------------------------------- _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io

Peter, Please read what I wrote, I checked each and every field (so not every device in the internet will need to be upgraded and zero coordination is needed, anyone can upgrade any device at anytime and nothing will break), using the DF and MF bits (without fragmentation but with MTU) is a solution, it will not cause the internet to break, the "MTU udp handshake" is providing a replacement for the DF and MF bits. Any internet device don't have to be upgraded to IPv4+ , it is possible that an IPv4+ packet will not reach from source to destination (and then udp handshake will know it initially and will not send the IPv4+ packet), and all the routing equipment in the routing path don't have to be upgraded as well (only bgp routers and non-bgp routers with more than two physical routes). Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Peter Linder <peter@fiberdirekt.se> Sent: Saturday, April 25, 2020 10:46 PM To: members-discuss@ripe.net <members-discuss@ripe.net> 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 Sorry, that won't work. The idea of borrowing more address space bits from various fields in the ip header is not new. None of these ideas, except NAT, has worked, typically because they required a coordinated upgrade effort which is impossible for more reasons than one. As a workaround, people instead agreed to expand the address fields to 128 bits and use the "version" field in the header to differentiate between the old protocol (version set to 4) and the new (version set to 6). I suggest we just use that. Most of the upgrade effort has been completed already. Den 4/25/2020 kl. 8:20 PM, skrev Elad Cohen: Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/peter%40fiberdirekt.s...

Radu, That will cause a performance overload on routers and then each and every device on the internet will need to be upgraded - an impossible mission. My solution is feasible, can be very quickly deployed, doesn't require the upgrade of all devices in the internet and will bring to each RIR more than 800,000,000 IPv4 addresses (and will also bring to each ISP and ASN a high amount of free IPv4 addresses). Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Radu Anghel via members-discuss <members-discuss@ripe.net> Sent: Saturday, April 25, 2020 10:51 PM To: members-discuss@ripe.net <members-discuss@ripe.net> 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 Hi Elad, Do you think that if we also display them in HEX (0-FFFF.0-FFFF) we could get double the amout of IPv4+??? Thaaanks! Radu On 25.04.2020 20:20, Elad Cohen wrote:

Hello Everyone,

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:

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]

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)

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

and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535])

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)

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

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.

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.

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

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.

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+).

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.

Respectfully, Elad

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/radu.anghel%40xindi.e...

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/elad%40netstyle.io

Aleksei, Regarding: "Server (11.11.11.1) sends packet with additional header data (there is space for this!)" 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 Where in the ip header are the two additional bytes for the source address and the two additional bytes for the destination address ? Regarding: "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)" 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. 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) Regarding: "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." 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). Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Aleksi <aleksi@magnacapax.fi> Sent: Sunday, April 26, 2020 12:25 AM To: members-discuss@ripe.net <members-discuss@ripe.net> 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 Hi, 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. Extend with 2 additional ie. [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] Would be the new maximum on base software. Example: Server is 11.11.11.1 Client is 11.11.12.1.1.1 Router at 11.11.12.1 Server (11.11.11.1) sends packet with additional header data (there is space for this!) with 2 additional bytes for the extension address. 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) 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!) 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. 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. Then again, i would wish also maximum packet size to be increased by order of magnitude(s). 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. 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... -Aleksi Magna Capax Finland On 4/25/20 9:20 PM, Elad Cohen wrote: Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f...

The vendor will not need to spend millions for a software upgrade, the implementation is very simple, it is exactly the same protocol (IPv4) just with the reserved bit turned on and then two other bit flags are representing the source address and the destination address differently, from a development point of view it is very easy and fast, each vendor can do it in one week. The economy is that also they can develop it fast (it is not a completely new protocol in terms of code development, just few modifications to existing code) and for it they will receive a high number of IPv4+ addresses. Currently the RIRs are very strict on allocating new IPv4 space (the ones that still have) to LIRs and these policies will continue, they will continue to be very strict, so I don't expect IPv4+ to runout fast, it will take at least more 25 years and it will give the whole world time to transfer to IPv6 smoothly. IPv4+ will not stop IPv6, we as the internet community should not cause damage to any party which is connected to the internet and by enforcing IPv6 because of no IPv4 - I don't believe that we are doing good, the world is in problem and I brought my solution - if the internet community will decide to adopt it or not this is your decision. Respectfully, Elad ________________________________ From: Ed Campbell <campbell@inca.ie> Sent: Sunday, April 26, 2020 1:28 AM To: Elad Cohen <elad@netstyle.io>; members-discuss@ripe.net <members-discuss@ripe.net> 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 And again, you tell me one vendor that will spend the millions required to develop a software upgrade for this. Where is the economy in that? The “new” IP space will have ran out in 5 years due to mismanagement and all that would happen is yet another 5 year delay to the full deployment of IPv6. This is not a solution, even if it were feasible, it is a stop gap. IPv6 is not a new protocol it has been around for years now. It is time to push this more than anything else as it literally solves the problem. Sent from my iPhone On 25 Apr 2020, at 23:14, Elad Cohen <elad@netstyle.io> wrote:  Aleksei, Regarding: "Server (11.11.11.1) sends packet with additional header data (there is space for this!)" 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 Where in the ip header are the two additional bytes for the source address and the two additional bytes for the destination address ? Regarding: "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)" 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. 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) Regarding: "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." 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). Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces@ripe.net> on behalf of Aleksi <aleksi@magnacapax.fi> Sent: Sunday, April 26, 2020 12:25 AM To: members-discuss@ripe.net <members-discuss@ripe.net> 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 Hi, 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. Extend with 2 additional ie. [0-255].[0-255].[0-255].[0-255].[0-255].[0-255] Would be the new maximum on base software. Example: Server is 11.11.11.1 Client is 11.11.12.1.1.1 Router at 11.11.12.1 Server (11.11.11.1) sends packet with additional header data (there is space for this!) with 2 additional bytes for the extension address. 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) 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!) 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. 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. Then again, i would wish also maximum packet size to be increased by order of magnitude(s). 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. 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... -Aleksi Magna Capax Finland On 4/25/20 9:20 PM, Elad Cohen wrote: Hello Everyone, 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: 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] 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) 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]) and another set of 4,294,967,296 IPv4 addresses (with a new format of [0-65535].[0-65535]) 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) 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). 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. 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. 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+. 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. 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+). 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. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss@ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f... _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie