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

let me be straight: your "solution" makes so many naive assumptions,
technically and economically, while leaving out a hell of requirements and
conditions of real world networks and IP stacks, that I'm totally torn
between either interpreting your mail as a joke or just as a well-meant but
clueless attempt to solve the problem of scaling the most important
communication protocol on this planet to another version of it.

Seriously, do you really believe that by stealing some bits from the IPv4
header here and there and using UDP for *path* MTU discovery you have found
the solution to our addressing problems right now?

The amount of considerations to make in an attempt to change something of
this kind of size is so huge and the way to make it a success so dynamic
and hard to predict that it will take years of hard work until you might
get working code from vendors and real world support by Internet operators
and major host stacks.

You are basically suggesting two technical things to make the current IPv4
address-space larger while being non-disruptive to the current IPv4
standard and claiming it an alternative which could be deployed faster and
easier than IPv6:

a) 33-bit addressing, the new half in a new address-family, lookup on the
IP header Flags field to decide how to interpret SADDR and DADDR fields

1. Not only will that involve a lot of engineering in routing-protocols and
their dependencies, but will just not work for many of them w/o a complete
new standard for them as well
2. IP stacks not supporting this extension will *wrongly* interpret the
packet having normal IPv4 addresses. This creates a HELL OF ISSUES, from
bypassing ACLs to routing-loops and DoS, to forged end-to-end connectivity.
3. Most IPv4 h/w implementations will not be able to use another round of
lookup on Flags field to choose the proper forwarding table. Certainly this
can be done, but it will take years until we would see it being shipped.

b) UDP-based path MTU discovery up front, needs to succeed before any IPv4+
socket should be able to transmit packets

1. If you are only able to communicate with another IPv4+ host by testing
for UDP connectivity then good luck in real world networks. IPv4+ will
never work if this is a requirement to get any socket up.
2. If the path in between converges in some way thus making your packets
crossing a router suddenly not supporting IPv4+ then this will lead to all
kinds of weird and problematic behavior. This is a HUGE security flaw. From
intercepting and eavesdropping to suddenly DoSing some IPv4 host with a
100Gbps IPv4+ stream.

There are dozens of other concerns and problems with your "solution", but
seriously I don't believe we should discuss that here for *you*. It's
really the wrong mailing-list for that and your "draft" has not even
reached omega status for making it discussable with such a wide audience of
Internet operators.

Thanks

On Sat, 25 Apr 2020 at 20:36, Elad Cohen <elad at netstyle.io> wrote:

> 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 at ripe.net
> https://mailman.ripe.net/
> Unsubscribe:
> https://lists.ripe.net/mailman/options/members-discuss/christian.meutes%40pwc.com
>

Christian

-- 
Diese Information ist ausschliesslich fuer den Adressaten bestimmt und kann 
vertrauliche oder gesetzlich
geschuetzte Informationen enthalten. Wenn Sie 
nicht der bestimmungsgemaesse Adressat sind, unterrichten Sie
bitte den 
Absender und vernichten Sie diese Mail. Anderen als dem 
bestimmungsgemaessen Adressaten ist es
untersagt, diese E-Mail zu lesen, zu 
speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu

verwenden. Wir verwenden aktuelle Virenschutzprogramme. Fuer Schaeden, die 
dem Empfaenger gleichwohl
durch von uns zugesandte mit Viren befallene 
E-Mails entstehen, schliessen wir jede Haftung aus. * * * * *
The 
information contained in this email is intended only for its addressee and 
may contain confidential and/or
privileged information. If the reader of 
this email is not the intended recipient, you are hereby notified that 
reading,
saving, distribution or use of the content of this email in any 
way is prohibited. If you have received this email in
error, please notify 
the sender and delete the email. We use updated antivirus protection 
software. We do not
accept any responsibility for damages caused anyhow by 
viruses transmitted via email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/aa39b7de/attachment.html>