[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
- Previous message (by thread): [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
- Next message (by thread): [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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Radu Anghel
radu.anghel at xindi.eu
Sat Apr 25 21:51:12 CEST 2020
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 at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/radu.anghel%40xindi.eu >
- Previous message (by thread): [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
- Next message (by thread): [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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]