Re: RIPE NCC Executive Board election

[Elad Cohen <elad () netstyle io>]

You are right, more IPv4 addresses are not needed.
________________________________
From: Owen DeLong <owen () delong com>
Sent: Thursday, May 14, 2020 12:17 AM
To: Elad Cohen <elad () netstyle io>
Cc: Mikael Abrahamsson <swmike () swm pp se>; NANOG list <nanog () nanog org>
Subject: Re: RIPE NCC Executive Board election



On May 13, 2020, at 12:36 , Elad Cohen <elad () netstyle io<mailto:elad () netstyle io>> wrote:

----
Do you realise that this means you're requiring changing *every*
socket-speaking application in the world?
----
Every internet host that will want to speak IPv4+ , will have an update (for example through the operating systems 
automatic updates mechanisms)

Uh… You left out Every Application on Every Host.

How do all of those applications get updated (some fo which are in-house custom code whose maintainers long since 
retired).

If you’re recoding all the applications, that’s pretty much the last hurdle left at this point for IPv6, so what’s the 
advantage of IPv4+ at this point? None whatsoever.



----
It's taken us decades to get applications to use the new struct to support
IPv6+IPv4, resetting the timer back to 0 and starting over does not help
deployment. It just kicks it another 20 years down the line.
----
I wrote about the usage of a roundtable in order to implement everything fast (the roundtable will include one 
representative from each of the operating system vendors, one representative from each of the routing equipment 
manufacturers and one representative from each of the 5 RIR's), if I will be elected to RIPE board I will do everything 
in my power so this roundtable will be formed fast and that the needed updates will be created fast. Each party in the 
roundtable will receive an amount of free IPv4 addresses from the new IPv4+ pool, and each ASN will also receive for 
example a /21 , home-routers and home-modems will not be needed to be updated and they will support IPv4+.


----
You're just inventing yet another incompatible standard and you have to
touch everything, DHCP, DNS all applications etc.
----
There is an adjustment to IPv4+ that the format of addresses will not be [0-655365].[0-655365]v4 - but it will be 
[256-511].[0-255].[0-255].[0-255]
So IPv4+ addresses will be in the format of IPv4 addresses - it will end-user adoption of IPv4+ easier and also 
integration in the applicative layer easier (as application developers will only need to set that the first number can 
be higher instead to support a new format of [0-655365].[0-655365]v4 )

So you want to retain all the need for NAT, continue to make end-users second-class citizens, avoid most of the gains 
and improvements of IPv6, while reducing the workload involved in adoption by (oh, wait, you’re increasing the workload 
required)…

Where’s the win in this, exactly?

Owen



________________________________
From: Mikael Abrahamsson <swmike () swm pp se<mailto:swmike () swm pp se>>
Sent: Wednesday, May 13, 2020 10:22 PM
To: Elad Cohen <elad () netstyle io<mailto:elad () netstyle io>>
Cc: Brielle <bruns () 2mbit com<mailto:bruns () 2mbit com>>; NANOG list <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: RIPE NCC Executive Board election

On Wed, 13 May 2020, Elad Cohen wrote:

> LOL funny seeing you changing your mind by 180 degrees when someone you
> know in the community writing to you the exact same thing.

"In addition, the sockets API should be extended to support IPxl with a
new socket domain PF_IPXL which is identical to PF_INET in every respect
save that the IP addresses are 8 bytes long instead of 4."

Do you realise that this means you're requiring changing *every*
socket-speaking application in the world?

It's taken us decades to get applications to use the new struct to support
IPv6+IPv4, resetting the timer back to 0 and starting over does not help
deployment. It just kicks it another 20 years down the line.

You're just inventing yet another incompatible standard and you have to
touch everything, DHCP, DNS all applications etc.

--
Mikael Abrahamsson    email: swmike () swm pp se<mailto:swmike () swm pp se>