[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

Christian,

I'm sorry to write, but you didn't understand how IPv4+ works. And everything that you wrote regarding IPv4+ is completely incorrect.

"There is no connectivity between IPv4 and IPv4+" - IPv4+ is IPv4, exact same protocol.

"you would need routers to support 33 bit routes which is not going to happen" - This is completely incorrect, route bits are exactly the same.

"To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead.  The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack." - No another address family is needed, the source address and destination are exactly in the four bytes each as they are now - the only difference is the application layer in the operating system - based if the single reserved bit flag is on or off - the ip address will be displayed with one dot (IPv4+) or with three dots (IPv4).

"You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits." - It is the same network, IPv4 (I'm calling it IPv4+ to represent the one-dot addressing to higher application layers, but it is the same IPv4 packets, same IPv4 network)

I'm not against IPv6, IPv6 and IPv4 will always co-exist in some way, IPv4+ brings more ip addresses to IPv4, it doesn't disturb a bit IPv6.

Respectfully,
Elad
________________________________
From: Christian Kratzer <ck at cksoft.de>
Sent: Sunday, April 26, 2020 11:12 AM
To: Elad Cohen <elad at netstyle.io>
Cc: Tobias Lehner <tl at hartl-edv.de>; 'noc' <noc at xervers.pt>; Ed Campbell <campbell at inca.ie>; members-discuss at ripe.net <members-discuss at 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,

On Sun, 26 Apr 2020, Elad Cohen wrote:

> You didn't fully read my initial post, the MTU with IPv4+ will not be a fixed MTU of 1500 or of any other fixed value, it will be set in the beginning of the connection through a process called: "IPv4+ UDP Handshake"
>
> Respectfully,
> Elad
<snipp/>

Respectfully your solution does not solve any problem. It just creates new ones.

There is no connectivity between IPv4 and IPv4+. So clients needing access to both world need to "dual stack" or even "triple stack" if they also need IPv6.

To enable connectivity between IPv4 and IPv4+ you would need routers to support 33 bit routes which is not going to happen.

To enable a client to connect to both the IPv4 and IPv4+ internet it seems to me that you would need at least another address family in the socket protocols which is also a massive overhead.  The formatting of the address as two 16 bit values instead of four 8 bit values does not fix the issue in the clients ipv4 stack.

You cannot route ipv4 and ipv4+ in the same global internet if they are two seprate networks and if the addresses mean different things depending on arbitrary address bits.

So I fail to see how in any way your solution would provide more adresses to the existing internet without creating a new isolated cloud.

IPv6 can coexist with IPv4 because it has been designed appropriately as a fully separate protocol with clean separation in the the ip stack via a separate address family.

Greetings
Christian

--
Christian Kratzer                   CK Software GmbH
Email:   ck at cksoft.de               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/4c237dd6/attachment.html>