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


"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"

  There is place in the same places you suggest in your "IPv4+" proposal ;)
Quite frankly, it's been nearly 10 years since i looked into this and i 
do not deal at *that* level often, but i do recall there being 
possibility to add the few bytes required to header, instead of data 
segment.

Quite frankly, it *does not* matter where in the packet that data is -- 
what matter is *most convenient* position. This is a technical detail 
which can be solved by those far more knowleadgable than i am on every 
single nuance -- I am not qualified to decide this nor does it need to 
be decided now.


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


Incorrect! Only end points like i said. Instead of going on full attack 
mode instantly, perhaps try to read and comprehend and work with others. 
You complain you are being attacked, but what i see you are acting a bit 
like that yourself. Instead of attacking and complaining, people should 
try to work together by sharing ideas to get to the best possible 
outcome. Not "My Way or No Way!" mentality.


Whatever the chosen location for the 2 or 4 additional bytes which does 
not get "scrubbed" on route only the end points need to support those. 
Route like normal, no changes, traverse like normal, until you get to 
the 11.11.12.1 which needs to understand beyond this, same with 
everything after that.


"firmware-upgrade all the routers in the world - an impossible task"
But magically possible for your IPv4+ proposal, just not my call it 
"IPv4e" as in IPv4 extended. Not a problem at all to make every single 
device support in the world support when it is your proposal?


Also not required on "IPV4e".


Hell, even not all clients do not need to understand on IPv4e the 
extension. On outgoing packets (from 11.11.12.1.1.1) non-enabled device 
sees a packet from 11.11.12.1 and responds to it normally, with NAT like 
code can handle the extension translation on the 11.11.12.1 switch :)
Albeit granted non-enabled end device will need network stack code 
updated to open directly a connection with extended address, but 
vice-versa it's not requirement.


ZERO BGP changes required. ZERO routing changes. Extensions would always 
be considered L2 on grander scale, and the extension cannot be split 
(avoids more routing table fragmentation and growth). Within the 
extension routing can still be done, no need to have all the extension 
in single subnet, just not on the grander scale. Needed upgrades: End 
point switch/router where extension begins, and switches and devices 
behind that. ie. only accrue cost and hassle for the amount you want to 
extend to -- and only for new installs.
Let's be real here tho, a decade old switch *will* not get an update 
like this, nor might have the power to do the additional lookups, but 
you do not need to update your whole network at once -- only where you 
want to use this.


Essentially you can decide whether or not to extend from /32 at all, or 
full /16 worth of addresses. Hell, if you want you can only use it on 
single device to map every software on their own IP instead of just port 
or something interesting like that :) Or you can have /16 worth of 
devices beyond it. All up to the end point!


Speaking of which mobile networks now relying on NAT could additionally 
offer extended IP to end devices, in case the device supports it and 
needs direct connectivity. Same for all other NAT networks out there.


Clients will need software updates to access these more or less, but 
there will always be potential for partial connectivity even on non 
supported devices, without any work for the client side.

There will always be devices running Windows XP still. There will always 
be super old non-updated legacy devices, no matter what route you take.


As there is no additional cost for client, server, BGP level etc. it 
could start to begin slowly by those who most needs it and adoption 
would grow slowly over time, which increases level of connectivity. 
There is after all connectivity between regular IPv4 and an extended one.
Typical office PC, mobile device etc. will get quick updates however 
typically, so getting a huge number of supported devices online will 
happen relatively quick (1 year?) -- all is needed Linux kernel update, 
and microsoft and apple to do the same and eventually you will have vast 
majority of devices supported with no additional changes -- no need to 
change switches, firewalls etc.


So this would end up being more of a software engineering exercise than 
wholesale router upgrades at huge scale. Router manufacturers will 
probably be happy to support as they get to sell more hardware then, or 
even justify significantly higher cost for IPv4e devices ;)


So from my perspective, i see very little friction to do something like 
this -- everyone wins and it's quite minimal effort to implement or not 
to implement in most use cases.


-Aleksi



On 4/26/20 12:57 AM, Elad Cohen 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 at ripe.net> on behalf 
> of Aleksi <aleksi at magnacapax.fi>
> *Sent:* Sunday, April 26, 2020 12:25 AM
> *To:* 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,
>
>
>  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 at ripe.net  <mailto:members-discuss at ripe.net>
>> https://mailman.ripe.net/
>> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/00692ba6/attachment.html>