- members-discuss - mailman.ripe.net

Mailing List Purpose and Request for Consideration
by Piotr Strzyżewski 01 May '20

01 May '20

Dear all, I would like to remind you of the purpose of this list. It is to allow members to discuss matters of importance relating to their membership of the RIPE NCC. All other topics should be considered not relevant for this list. The Board is always pleased to see good discussion on the list, and we realise this can become heated at times. However, thousands of members are subscribed to the list and receive these emails. Therefore, I ask you to be considerate of your fellow members in terms of both content and frequency of mails. For those who wish to unsubscribe, please read the information available at: https://www.ripe.net/participate/member-support/membership-mailing-lists/su… Kind regards, Piotr Strzyżewski RIPE NCC Executive Board Secretary

2 1

Good to know
by ivaylo 01 May '20

01 May '20

Hello, Even all of us to seeing this discussion as spam. I think it is useful and all candidates for election must write their ideas and point of views too. Now I can clearly make my judgment if to give my vote for mr Elad Khoen or not. PS: The spamming come from all who try to respond to these technical ideas. So please stop ! Just read make your mind and lets hear the others candidates.

8 14

Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Melchior Aelmans 01 May '20

01 May '20

LOL On Fri, May 1, 2020 at 1:08 AM Thilo <inbox(a)tmo.sh> wrote: > IAB is also having open chair positions if this is something out of > interest. > > Am Fr., 1. Mai 2020 um 00:53 Uhr schrieb Melchior Aelmans < > melchior(a)aelmans.eu>: > >> As this idea is talking about BGP implementations I think this would >> belong in the IDR WG in IETF? >> >> On Thu, Apr 30, 2020 at 10:32 PM Elad Cohen <elad(a)netstyle.io> wrote: >> >>> Hello Ripe Members! >>> >>> I will share the following solution in the near General Meeting and I'm >>> interested to share the following technical solution with you as well, it >>> will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS >>> attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet >>> infections and Botnet C&Cs. >>> >>> By a single update to any BGP router, not any router needs to be >>> updated, only active BGP routers. If I will have the honor of being elected >>> to the Ripe Board I will harness all the power of Ripe and all of the 5 >>> RIR's and all of the LIR's in the 5 RIR's so routing manufacturing >>> companies will implement the below processes and methods with a single >>> firmware update to their BGP routers. >>> >>> I'm asking for your support in electing me so I will be able to enter >>> the Ripe Board and then I will be able to make everything which is written >>> in this post to come true. >>> >>> >>> Regarding the bgp-anycasted infrastructure written below, ICANN is >>> written but the global bgp-anycasted infrastructure can be managed by the 5 >>> RIR's and/or by the ccTLDs registries (my main point is that who will >>> operate the bgp-anycasted infrastructure is not important for now, as long >>> as it will be an agreed authoritative non-governmental non-commercial >>> global entity/ies) >>> >>> With new tracking protocol over ip, routers will be able to confirm that >>> source ip came from the network of the announcing ASN, and hence spoofed >>> amplification DDoS attacks will be completely annihilated. >>> >>> >>> The Process: >>> >>> At the source BGP router, for any ip packet with a source address that >>> is from the network of the source BGP router (lets call it original ip >>> packet) - the source BGP router will create a new ip packet (lets call it >>> tracking ip packet) with a new transport layer protocol and with the same >>> source address and with the same destination address and with the same >>> IP-ID such as the original ip packet. >>> >>> In the new tracking ip packet there will be a new transport layer >>> protocol (tracking protocol) with the following fields: >>> AS number of source BGP router in clear text >>> AS number of source BGP router encrypted with the private key of the >>> source BGP router >>> >>> The destination BGP router (a BGP router that the destination address is >>> in its network) whenever it receive a 'tracking ip packet' will check if >>> its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': >>> If 'off' then the destination BGP router will drop that 'tracking ip >>> packet' >>> >>> If 'on' then the destination BGP router will decrypt the 'encrypted AS >>> number' with the public key of the specific AS number >>> and after decryption the AS number need to be the result: >>> if not then to drop the tracking ip packet and the original ip packet >>> related to it >>> if yes then to drop the tracking ip packet and to forward the related >>> original ip packet to destination but only if the source address is >>> originated from the specific ASN (according to the local ASNs+ranges table >>> in the BGP router, such table will be received from ICANN) >>> >>> >>> If the 'Check tracking flag' is set to 'on' then any original ip packet >>> that arrive to the destination BGP router will wait for the related >>> tracking ip packet (in case the related tracking ip packet didn't already >>> arrived to the destination BGP router). The destination BGP router will >>> manage such waiting for X number of seconds. >>> >>> The destination BGP router will match between a tracking ip packet and >>> an original ip packet - based on their source address and their destination >>> address and their IP-ID which will all be identical. >>> >>> >>> >>> More Aspects: >>> >>> - The end-devices will not need to be updated, any router will not need >>> to be updated, only all the BGP routers will need to be updated. >>> - Any BGP router in the routing path, which the original ip packet and >>> the tracking ip packet are not destined to an ip address in its own network >>> - will not check the content of the tracking ip packet and will forward >>> both the tracking ip packet and the original ip packet as they are. >>> - Each BGP router will have all the public keys (of all the ASN's) >>> locally. >>> - Each BGP router will have a full list of all the ASN's and all the >>> route objects ranges which are related to them locally. >>> >>> >>> >>> How BGP routers will receive all the ranges in all the route objects of >>> all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for >>> decrypting the encrypted strings in 'tracking ip packets'): >>> >>> - Each BGP router will create a tcp session with ICANN backend >>> infrastructure (the backend infrastructure of ICANN will use BGP anycast >>> and will be available from many locations worldwide with automatic syncing) >>> - At this stage there will be a handshake process between the BGP router >>> and the ICANN backend infrastructure in order for ICANN to know the correct >>> ASN which is operating the BGP router - the BGP router will send its ASN in >>> cleartext and also its ASN encrypted with its >>> ICANN-communication-private-key , ICANN will know the related public key >>> for the specific ASN from the specific ASN object in the RIR (the public >>> key for communication with ICANN will be displayed there) - after >>> decryption ICANN will compare the decrypted string to the AS Number for >>> successful authentication. >>> - After successful authentication, all the communication will be >>> encrypted, ICANN will notify the BGP router about its public key and ICANN >>> will use the public key of the ASN for the communication with ICANN - from >>> the ASN object in the RIR. >>> - The BGP router will send over the session its public key to be used by >>> other BGP routers in order to decrypt the encrypted string in the tracking >>> ip packets that it will originate (that private key and public key will be >>> managed in the BGP router GUI or CLI). >>> - ICANN will notify all the other BGP routers through the sessions with >>> them about a newly updated such public key of any other BGP router. >>> - ICANN will also receive in real-time any route object >>> creation/modification/deletion notification from any of the 5 RIRs and will >>> then update all the BGP routers through all of their sessions. >>> >>> - In case a BGP router doesn't have an active session to ICANN backend >>> infrastructure (for any reason, might be due to networking issue) - then >>> temporarily the internal 'Check tracking flag' of it will be set to 'off'. >>> After the session with ICANN backend infrastructure will be re-established >>> and the BGP router will receive all the meantime updates - the boolean >>> value of 'Check internal flag' will return to initial state. >>> - Any update from ICANN backend infrastructure to a BGP router (such as >>> a public key of another BGP router, or a routing object update) - will be >>> confirmed that the update was received well by the BGP router side. >>> >>> >>> >>> 'Check tracking flag' in BGP Routers: >>> >>> - BGP routers, in their GUI and CLI interfaces - will not allow the >>> end-user to set the boolean value of 'Check tracking flag', in order to >>> avoid misconfiguration. >>> - The ICANN backend infrastructure through the session with the BGP >>> router - will be able to set the boolean value of the 'Check tracking flag'. >>> - The reason for it, is that if 'Check tracking flag' will be set on >>> some destination BGP routers while some other source BGP routers weren't >>> upgraded yet (and will not send the 'tracking ip packet' due to it) - then >>> 'tracking ip packet' will never reach the destination BGP router and the >>> internet will break. >>> - Central setting of 'Check tracking flag' through ICANN backend >>> infrastructure - will allow ICANN to inform all the BGP routers at once to >>> switch 'on' the 'Check tracking flag' >>> - ICANN, in the session to any BGP router, will also receive the >>> percentage of ip packets that were destained to that BGP router network - >>> that also had ip tracking packets, in this way ICANN will know when all the >>> BGP routers were properly globally updated and when it is time to enable >>> the 'Check tracking flag' in all the BGP routers. >>> - ICANN will know if all the BGP routers in the world were upgraded >>> based on keeping the full BGP table and comparing it to all the BGP routers >>> that did and that did not open a session to ICANN backend infrastructure. >>> >>> >>> >>> Automatic preventation of IoT botnet infections: >>> >>> - IoT botnets are based on default credentials, if we can block default >>> credentials of IoT devices then these kind of botnets (such as >>> Mirai-variants and similar) will stop to have an impact in the internet. >>> - The data field in an ip packet - will always be the same for an access >>> attempt to a IoT device with default credentials - hence these kind of "IP >>> protocol data fingerprints" which are related to specific "IP protocol >>> numbers" will be provided by ICANN backend infrastructure to each BGP >>> router through the opened session with it. >>> - There are two issues with matching incoming ip packets to the "locally >>> stored IP protocol data fingerprints" - the first one is that ip packets >>> can be sent by fragments (so not all the data field will be sent at once in >>> order to be able to be compared with the locally stored data fingerprints) >>> and the second is that usernames (or url's) or any other textual data in >>> the incoming ip packet data field can be in uppercase or in lowercase. In >>> order to overcome the possibility of the existence of a single data >>> fingerprint in multiple incoming ip packet fragments - then in case the BGP >>> router is recognizing the incoming fragmented ip packet data value as part >>> of an existing fingerprint data in its local database then it will keep >>> track of the arrival ip packet fragments based on their specific IP-ID >>> identifier and the BGP router will not forward the last ip packet fragment >>> if the last ip packet fragment will cause all the related ip packet >>> fragments to match a specific ip fingerprint data (last ip packet doesn't >>> have to be the last fragmented part but it is the last ip packet that >>> arrived with that IP-ID identifier, so the BGP router will keep track of >>> the specific fragmented IP packets that arrived and their indexes in order >>> to know when the last one of them arrived). Regarding the second issue - >>> the stored data fingerprints in the local BGP router will be stored in a >>> way that some bytes of them (in specific indexes) will not be compared and >>> in case all the other bytes will match - then the bytes in these indexes - >>> will first be lowered case - and only then comparison will be made to the >>> specific indexed bytes in the specific ip packet data fingerprint. >>> - In case a IoT device behind a BGP router will be infected somehow (for >>> example when a specific fingerprint data with default credentials for a >>> specific device wasn't updated yet through ICANN backend infrastructure), >>> it will be able to infect all the other IoT devices in the local network >>> when the connectivity to them is not through the BGP router, that kind of >>> impact will be much much lower than infected IoT device which can infect >>> any other IoT device in the internet and then massive botnets in the >>> internet are created which are being used for DDoS. >>> >>> >>> >>> Automatic prevention of botnet C&C ip addresses: >>> >>> - Botnets C&C are also a problem in the internet. >>> - This problem can be overcome using the following technical addition: >>> the 5 RIR's will operate end-users honeypots machines all over the world >>> (it will be implemented by a single physical machine in each location, for >>> example in each datacenter and in each major ISP, each single physical >>> machine will emulate a virtual router and virtual VM's, the virtual VM's >>> will emulate many different kinds of 'real world machines', any kind of >>> automatic updating (in the operating system configurations) will be >>> disabled, these honeypots machines are not intended to make any outgoing >>> connection, the virtual routers will monitor if any outgoing connection is >>> made and if yes then it is to a botnet C&C, the virtual router will update >>> the ICANN backend infrastructure regarding it and the ICANN backend >>> infrastructure will update all the BGP routers (in their open sessions) >>> regarding it to completely block any communication to that botnet C&C ip >>> address. There will be a web-based system and only the related Law >>> Enforcement Agency of that C&C ip address region - will be able to remove >>> that C&C ip address from being blocked after their manual check. >>> - Honeypot machines will be deployed using 'templates' - these templates >>> must be signed and not anyone can create them, they should be created and >>> signed by an agreed Law Enforcement Agency such as Interpol in order to >>> make sure that these templates are by-design not making any outgoing >>> connection. The templates will be deployed in an automatic way (major ISP's >>> and datacenters will be able to easily add a 'physical honeypot' server in >>> their network, that will be shipped to them), the re-initiation of a >>> compromised 'virtual machine' that made an outgoing connection - will also >>> be automatic through the system in the physical server. >>> >>> >>> Respectfully, >>> Elad >>> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss(a)ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe: >>> https://lists.ripe.net/mailman/options/members-discuss/ripe-members-discuss… >>> >> _______________________________________________ >> members-discuss mailing list >> members-discuss(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/ripe%40tmo.sh >> >

3 2

Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

Hello Ripe Members! I will share the following solution in the near General Meeting and I'm interested to share the following technical solution with you as well, it will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet infections and Botnet C&Cs. By a single update to any BGP router, not any router needs to be updated, only active BGP routers. If I will have the honor of being elected to the Ripe Board I will harness all the power of Ripe and all of the 5 RIR's and all of the LIR's in the 5 RIR's so routing manufacturing companies will implement the below processes and methods with a single firmware update to their BGP routers. I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. Regarding the bgp-anycasted infrastructure written below, ICANN is written but the global bgp-anycasted infrastructure can be managed by the 5 RIR's and/or by the ccTLDs registries (my main point is that who will operate the bgp-anycasted infrastructure is not important for now, as long as it will be an agreed authoritative non-governmental non-commercial global entity/ies) With new tracking protocol over ip, routers will be able to confirm that source ip came from the network of the announcing ASN, and hence spoofed amplification DDoS attacks will be completely annihilated. The Process: At the source BGP router, for any ip packet with a source address that is from the network of the source BGP router (lets call it original ip packet) - the source BGP router will create a new ip packet (lets call it tracking ip packet) with a new transport layer protocol and with the same source address and with the same destination address and with the same IP-ID such as the original ip packet. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router The destination BGP router (a BGP router that the destination address is in its network) whenever it receive a 'tracking ip packet' will check if its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it if yes then to drop the tracking ip packet and to forward the related original ip packet to destination but only if the source address is originated from the specific ASN (according to the local ASNs+ranges table in the BGP router, such table will be received from ICANN) If the 'Check tracking flag' is set to 'on' then any original ip packet that arrive to the destination BGP router will wait for the related tracking ip packet (in case the related tracking ip packet didn't already arrived to the destination BGP router). The destination BGP router will manage such waiting for X number of seconds. The destination BGP router will match between a tracking ip packet and an original ip packet - based on their source address and their destination address and their IP-ID which will all be identical. More Aspects: - The end-devices will not need to be updated, any router will not need to be updated, only all the BGP routers will need to be updated. - Any BGP router in the routing path, which the original ip packet and the tracking ip packet are not destined to an ip address in its own network - will not check the content of the tracking ip packet and will forward both the tracking ip packet and the original ip packet as they are. - Each BGP router will have all the public keys (of all the ASN's) locally. - Each BGP router will have a full list of all the ASN's and all the route objects ranges which are related to them locally. How BGP routers will receive all the ranges in all the route objects of all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for decrypting the encrypted strings in 'tracking ip packets'): - Each BGP router will create a tcp session with ICANN backend infrastructure (the backend infrastructure of ICANN will use BGP anycast and will be available from many locations worldwide with automatic syncing) - At this stage there will be a handshake process between the BGP router and the ICANN backend infrastructure in order for ICANN to know the correct ASN which is operating the BGP router - the BGP router will send its ASN in cleartext and also its ASN encrypted with its ICANN-communication-private-key , ICANN will know the related public key for the specific ASN from the specific ASN object in the RIR (the public key for communication with ICANN will be displayed there) - after decryption ICANN will compare the decrypted string to the AS Number for successful authentication. - After successful authentication, all the communication will be encrypted, ICANN will notify the BGP router about its public key and ICANN will use the public key of the ASN for the communication with ICANN - from the ASN object in the RIR. - The BGP router will send over the session its public key to be used by other BGP routers in order to decrypt the encrypted string in the tracking ip packets that it will originate (that private key and public key will be managed in the BGP router GUI or CLI). - ICANN will notify all the other BGP routers through the sessions with them about a newly updated such public key of any other BGP router. - ICANN will also receive in real-time any route object creation/modification/deletion notification from any of the 5 RIRs and will then update all the BGP routers through all of their sessions. - In case a BGP router doesn't have an active session to ICANN backend infrastructure (for any reason, might be due to networking issue) - then temporarily the internal 'Check tracking flag' of it will be set to 'off'. After the session with ICANN backend infrastructure will be re-established and the BGP router will receive all the meantime updates - the boolean value of 'Check internal flag' will return to initial state. - Any update from ICANN backend infrastructure to a BGP router (such as a public key of another BGP router, or a routing object update) - will be confirmed that the update was received well by the BGP router side. 'Check tracking flag' in BGP Routers: - BGP routers, in their GUI and CLI interfaces - will not allow the end-user to set the boolean value of 'Check tracking flag', in order to avoid misconfiguration. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - The reason for it, is that if 'Check tracking flag' will be set on some destination BGP routers while some other source BGP routers weren't upgraded yet (and will not send the 'tracking ip packet' due to it) - then 'tracking ip packet' will never reach the destination BGP router and the internet will break. - Central setting of 'Check tracking flag' through ICANN backend infrastructure - will allow ICANN to inform all the BGP routers at once to switch 'on' the 'Check tracking flag' - ICANN, in the session to any BGP router, will also receive the percentage of ip packets that were destained to that BGP router network - that also had ip tracking packets, in this way ICANN will know when all the BGP routers were properly globally updated and when it is time to enable the 'Check tracking flag' in all the BGP routers. - ICANN will know if all the BGP routers in the world were upgraded based on keeping the full BGP table and comparing it to all the BGP routers that did and that did not open a session to ICANN backend infrastructure. Automatic preventation of IoT botnet infections: - IoT botnets are based on default credentials, if we can block default credentials of IoT devices then these kind of botnets (such as Mirai-variants and similar) will stop to have an impact in the internet. - The data field in an ip packet - will always be the same for an access attempt to a IoT device with default credentials - hence these kind of "IP protocol data fingerprints" which are related to specific "IP protocol numbers" will be provided by ICANN backend infrastructure to each BGP router through the opened session with it. - There are two issues with matching incoming ip packets to the "locally stored IP protocol data fingerprints" - the first one is that ip packets can be sent by fragments (so not all the data field will be sent at once in order to be able to be compared with the locally stored data fingerprints) and the second is that usernames (or url's) or any other textual data in the incoming ip packet data field can be in uppercase or in lowercase. In order to overcome the possibility of the existence of a single data fingerprint in multiple incoming ip packet fragments - then in case the BGP router is recognizing the incoming fragmented ip packet data value as part of an existing fingerprint data in its local database then it will keep track of the arrival ip packet fragments based on their specific IP-ID identifier and the BGP router will not forward the last ip packet fragment if the last ip packet fragment will cause all the related ip packet fragments to match a specific ip fingerprint data (last ip packet doesn't have to be the last fragmented part but it is the last ip packet that arrived with that IP-ID identifier, so the BGP router will keep track of the specific fragmented IP packets that arrived and their indexes in order to know when the last one of them arrived). Regarding the second issue - the stored data fingerprints in the local BGP router will be stored in a way that some bytes of them (in specific indexes) will not be compared and in case all the other bytes will match - then the bytes in these indexes - will first be lowered case - and only then comparison will be made to the specific indexed bytes in the specific ip packet data fingerprint. - In case a IoT device behind a BGP router will be infected somehow (for example when a specific fingerprint data with default credentials for a specific device wasn't updated yet through ICANN backend infrastructure), it will be able to infect all the other IoT devices in the local network when the connectivity to them is not through the BGP router, that kind of impact will be much much lower than infected IoT device which can infect any other IoT device in the internet and then massive botnets in the internet are created which are being used for DDoS. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - This problem can be overcome using the following technical addition: the 5 RIR's will operate end-users honeypots machines all over the world (it will be implemented by a single physical machine in each location, for example in each datacenter and in each major ISP, each single physical machine will emulate a virtual router and virtual VM's, the virtual VM's will emulate many different kinds of 'real world machines', any kind of automatic updating (in the operating system configurations) will be disabled, these honeypots machines are not intended to make any outgoing connection, the virtual routers will monitor if any outgoing connection is made and if yes then it is to a botnet C&C, the virtual router will update the ICANN backend infrastructure regarding it and the ICANN backend infrastructure will update all the BGP routers (in their open sessions) regarding it to completely block any communication to that botnet C&C ip address. There will be a web-based system and only the related Law Enforcement Agency of that C&C ip address region - will be able to remove that C&C ip address from being blocked after their manual check. - Honeypot machines will be deployed using 'templates' - these templates must be signed and not anyone can create them, they should be created and signed by an agreed Law Enforcement Agency such as Interpol in order to make sure that these templates are by-design not making any outgoing connection. The templates will be deployed in an automatic way (major ISP's and datacenters will be able to easily add a 'physical honeypot' server in their network, that will be shipped to them), the re-initiation of a compromised 'virtual machine' that made an outgoing connection - will also be automatic through the system in the physical server. Respectfully, Elad

28 51

Re: [members-discuss] [SPAM] Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

I agree with you, let us all keep with the ddos attacks and not resolve them. Respectfully, Elad ________________________________ From: info(a)cowmedia.de Sent: Friday, May 01, 2020 12:27 AM To: Elad Cohen; 'Stuart Willet (primary)'; members-discuss(a)ripe.net Subject: AW: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, 1st: Again a „technical“ idea from your side that is not thought trough to the end. 2nd: If you will be elected (what i don’t think because of you annoying mostly everyone here) you don’t have the power to do what you expect. Still you need to convince other and still you need to create an RfC an so on, you are not able to convince other because you are rude and don’t accept others oppinions 3rd: because you are rude you also do not have any requirements for the election and we should suggest RIPE to remove you from the list because of missing soft skills 4th: You wrote „bgp routers need to wait for X-number of seconds“. Have you ever thought about what that means with 100 gbit/s devices? 5th: In addition again for mostly every packet you will ask a central service (that again communicates wich means packets are doubled, which result in overflooding of the network. 6th: i don’t want to read any word from you here personally because it just annoyes me. Michael Stenz Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von Elad Cohen Gesendet: Donnerstag, 30. April 2020 22:59 An: Stuart Willet (primary) <stu(a)safehosts.co.uk>; members-discuss(a)ripe.net Betreff: [SPAM] Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, You are willing to sacrifice the good of the community for a personal attack against me. Regarding what you wrote: do you know how many compute time is wasted for all the current DDoS attacks that this solution will not resolve ? do you know how many costs involved for organizations and companies which are under DDoS attacks ? when you compare the current to the state of this solution then this solution is by far better than the current state. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In fairness, I couldn’t even be bothered reading further than the worlds BGP routers needing a firmware update to DOUBLE packet count whilst adding compute time at an individual packet level. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn….. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! I will share the following solution in the near General Meeting and I'm interested to share the following technical solution with you as well, it will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet infections and Botnet C&Cs. By a single update to any BGP router, not any router needs to be updated, only active BGP routers. If I will have the honor of being elected to the Ripe Board I will harness all the power of Ripe and all of the 5 RIR's and all of the LIR's in the 5 RIR's so routing manufacturing companies will implement the below processes and methods with a single firmware update to their BGP routers. I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. Regarding the bgp-anycasted infrastructure written below, ICANN is written but the global bgp-anycasted infrastructure can be managed by the 5 RIR's and/or by the ccTLDs registries (my main point is that who will operate the bgp-anycasted infrastructure is not important for now, as long as it will be an agreed authoritative non-governmental non-commercial global entity/ies) With new tracking protocol over ip, routers will be able to confirm that source ip came from the network of the announcing ASN, and hence spoofed amplification DDoS attacks will be completely annihilated. The Process: At the source BGP router, for any ip packet with a source address that is from the network of the source BGP router (lets call it original ip packet) - the source BGP router will create a new ip packet (lets call it tracking ip packet) with a new transport layer protocol and with the same source address and with the same destination address and with the same IP-ID such as the original ip packet. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router The destination BGP router (a BGP router that the destination address is in its network) whenever it receive a 'tracking ip packet' will check if its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it if yes then to drop the tracking ip packet and to forward the related original ip packet to destination but only if the source address is originated from the specific ASN (according to the local ASNs+ranges table in the BGP router, such table will be received from ICANN) If the 'Check tracking flag' is set to 'on' then any original ip packet that arrive to the destination BGP router will wait for the related tracking ip packet (in case the related tracking ip packet didn't already arrived to the destination BGP router). The destination BGP router will manage such waiting for X number of seconds. The destination BGP router will match between a tracking ip packet and an original ip packet - based on their source address and their destination address and their IP-ID which will all be identical. More Aspects: - The end-devices will not need to be updated, any router will not need to be updated, only all the BGP routers will need to be updated. - Any BGP router in the routing path, which the original ip packet and the tracking ip packet are not destined to an ip address in its own network - will not check the content of the tracking ip packet and will forward both the tracking ip packet and the original ip packet as they are. - Each BGP router will have all the public keys (of all the ASN's) locally. - Each BGP router will have a full list of all the ASN's and all the route objects ranges which are related to them locally. How BGP routers will receive all the ranges in all the route objects of all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for decrypting the encrypted strings in 'tracking ip packets'): - Each BGP router will create a tcp session with ICANN backend infrastructure (the backend infrastructure of ICANN will use BGP anycast and will be available from many locations worldwide with automatic syncing) - At this stage there will be a handshake process between the BGP router and the ICANN backend infrastructure in order for ICANN to know the correct ASN which is operating the BGP router - the BGP router will send its ASN in cleartext and also its ASN encrypted with its ICANN-communication-private-key , ICANN will know the related public key for the specific ASN from the specific ASN object in the RIR (the public key for communication with ICANN will be displayed there) - after decryption ICANN will compare the decrypted string to the AS Number for successful authentication. - After successful authentication, all the communication will be encrypted, ICANN will notify the BGP router about its public key and ICANN will use the public key of the ASN for the communication with ICANN - from the ASN object in the RIR. - The BGP router will send over the session its public key to be used by other BGP routers in order to decrypt the encrypted string in the tracking ip packets that it will originate (that private key and public key will be managed in the BGP router GUI or CLI). - ICANN will notify all the other BGP routers through the sessions with them about a newly updated such public key of any other BGP router. - ICANN will also receive in real-time any route object creation/modification/deletion notification from any of the 5 RIRs and will then update all the BGP routers through all of their sessions. - In case a BGP router doesn't have an active session to ICANN backend infrastructure (for any reason, might be due to networking issue) - then temporarily the internal 'Check tracking flag' of it will be set to 'off'. After the session with ICANN backend infrastructure will be re-established and the BGP router will receive all the meantime updates - the boolean value of 'Check internal flag' will return to initial state. - Any update from ICANN backend infrastructure to a BGP router (such as a public key of another BGP router, or a routing object update) - will be confirmed that the update was received well by the BGP router side. 'Check tracking flag' in BGP Routers: - BGP routers, in their GUI and CLI interfaces - will not allow the end-user to set the boolean value of 'Check tracking flag', in order to avoid misconfiguration. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - The reason for it, is that if 'Check tracking flag' will be set on some destination BGP routers while some other source BGP routers weren't upgraded yet (and will not send the 'tracking ip packet' due to it) - then 'tracking ip packet' will never reach the destination BGP router and the internet will break. - Central setting of 'Check tracking flag' through ICANN backend infrastructure - will allow ICANN to inform all the BGP routers at once to switch 'on' the 'Check tracking flag' - ICANN, in the session to any BGP router, will also receive the percentage of ip packets that were destained to that BGP router network - that also had ip tracking packets, in this way ICANN will know when all the BGP routers were properly globally updated and when it is time to enable the 'Check tracking flag' in all the BGP routers. - ICANN will know if all the BGP routers in the world were upgraded based on keeping the full BGP table and comparing it to all the BGP routers that did and that did not open a session to ICANN backend infrastructure. Automatic preventation of IoT botnet infections: - IoT botnets are based on default credentials, if we can block default credentials of IoT devices then these kind of botnets (such as Mirai-variants and similar) will stop to have an impact in the internet. - The data field in an ip packet - will always be the same for an access attempt to a IoT device with default credentials - hence these kind of "IP protocol data fingerprints" which are related to specific "IP protocol numbers" will be provided by ICANN backend infrastructure to each BGP router through the opened session with it. - There are two issues with matching incoming ip packets to the "locally stored IP protocol data fingerprints" - the first one is that ip packets can be sent by fragments (so not all the data field will be sent at once in order to be able to be compared with the locally stored data fingerprints) and the second is that usernames (or url's) or any other textual data in the incoming ip packet data field can be in uppercase or in lowercase. In order to overcome the possibility of the existence of a single data fingerprint in multiple incoming ip packet fragments - then in case the BGP router is recognizing the incoming fragmented ip packet data value as part of an existing fingerprint data in its local database then it will keep track of the arrival ip packet fragments based on their specific IP-ID identifier and the BGP router will not forward the last ip packet fragment if the last ip packet fragment will cause all the related ip packet fragments to match a specific ip fingerprint data (last ip packet doesn't have to be the last fragmented part but it is the last ip packet that arrived with that IP-ID identifier, so the BGP router will keep track of the specific fragmented IP packets that arrived and their indexes in order to know when the last one of them arrived). Regarding the second issue - the stored data fingerprints in the local BGP router will be stored in a way that some bytes of them (in specific indexes) will not be compared and in case all the other bytes will match - then the bytes in these indexes - will first be lowered case - and only then comparison will be made to the specific indexed bytes in the specific ip packet data fingerprint. - In case a IoT device behind a BGP router will be infected somehow (for example when a specific fingerprint data with default credentials for a specific device wasn't updated yet through ICANN backend infrastructure), it will be able to infect all the other IoT devices in the local network when the connectivity to them is not through the BGP router, that kind of impact will be much much lower than infected IoT device which can infect any other IoT device in the internet and then massive botnets in the internet are created which are being used for DDoS. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - This problem can be overcome using the following technical addition: the 5 RIR's will operate end-users honeypots machines all over the world (it will be implemented by a single physical machine in each location, for example in each datacenter and in each major ISP, each single physical machine will emulate a virtual router and virtual VM's, the virtual VM's will emulate many different kinds of 'real world machines', any kind of automatic updating (in the operating system configurations) will be disabled, these honeypots machines are not intended to make any outgoing connection, the virtual routers will monitor if any outgoing connection is made and if yes then it is to a botnet C&C, the virtual router will update the ICANN backend infrastructure regarding it and the ICANN backend infrastructure will update all the BGP routers (in their open sessions) regarding it to completely block any communication to that botnet C&C ip address. There will be a web-based system and only the related Law Enforcement Agency of that C&C ip address region - will be able to remove that C&C ip address from being blocked after their manual check. - Honeypot machines will be deployed using 'templates' - these templates must be signed and not anyone can create them, they should be created and signed by an agreed Law Enforcement Agency such as Interpol in order to make sure that these templates are by-design not making any outgoing connection. The templates will be deployed in an automatic way (major ISP's and datacenters will be able to easily add a 'physical honeypot' server in their network, that will be shipped to them), the re-initiation of a compromised 'virtual machine' that made an outgoing connection - will also be automatic through the system in the physical server. Respectfully, Elad

3 6

Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

Gert, Let me summarize what you just wrote: "I'm so afraid and I'm a big big coward that IPv4+ will be implemented and then I will have less work with my IPv6 and the deployment of IPv6 will be slower and then the community will earn more 4,294,967,296 IPv4+ addresses but who cares because I like this state that companies must switch to IPv6 and we can overcharge them" Did I got it right ? Respectfully, Elad ________________________________ From: Gert Doering Sent: Friday, May 01, 2020 12:21 AM To: Elad Cohen Cc: members-discuss(a)ripe.net Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hi, On Thu, Apr 30, 2020 at 08:30:48PM +0000, Elad Cohen wrote: > I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. "Vote for me, and you shall have bread and circuses - and if not, you will have to stay miserable forever!" Am I summarizing this correctly? (This approach worked brilliantly in the past, but in the long run, the roman empire fell...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

2 1

Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
by Elad Cohen 01 May '20

01 May '20

Both of you supporting another candidate and that is perfectly fine, you can just say it clearly. We can keep being with DDoS attacks if you wish. Respectfully, Elad ________________________________ From: Tulp Solutions (O. Verheijen) <o.verheijen(a)tulpsolutions.com> Sent: Friday, May 1, 2020 12:27 AM To: Elad Cohen <elad(a)netstyle.io> Cc: Stuart Willet (primary) <stu(a)safehosts.co.uk>; members-discuss(a)ripe.net <members-discuss(a)ripe.net> Subject: Re: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please stop! There were no personal attacks, just different opinions. We clearly have a different opinion on what qualities one should have to get elected board member, but that's just fine, I don't feel attacked or offended by you. 'much much lower' is not a number, it does not work for me, especially when the only real requirement is that we should elect you first... @Stuart, is that sweet or salty popcorn you have there? Regards, Olof Op do 30 apr. 2020 om 22:59 schreef Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>: Stuart, The costs will be much much lower than the impacts of the following: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs If you prefer to stay with all the above ok lets stay with it all. If I will be elected you can be sure that I will do everything in my power to implement my solution that will resolve for all of it for all internet users. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:54 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, Please show me the costing for your solution. In short, how much will it cost to update every piece of hardware and software used in BGP sessions. How will you update all the END OF LIFE hardware and software? Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io<mailto:elad@netstyle.io>] Sent: 30 April 2020 21:50 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, Not anyone can afford DDoS mitigation service and many in the Internet don't have such service including in the Ripe region, and even for the ones that are paying for expensive DDoS mitigation service - DDoS attacks are using internet traffic, are using electrical power, interfering to access services, generating crime. If I will have the honor of being elected then I will implement it all for the best of everyone including negative members like you. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:44 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Elad, I have not attacked you, just pointing out the incredibly impossible task you wish to be undertaken. As for costs, we currently use a DDoS mitigation service. Your solution is not feasible, full stop. Respectfully, Stuart Willet. From: Elad Cohen [mailto:elad@netstyle.io] Sent: 30 April 2020 21:42 To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: Re: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Stuart, You are willing to sacrifice the good of the community for a personal attack against me. Regarding what you wrote: do you know how many compute time is wasted for all the current DDoS attacks that this solution will not resolve ? do you know how many costs involved for organizations and companies which are under DDoS attacks ? when you compare the current to the state of this solution then this solution is by far better than the current state. Respectfully, Elad ________________________________ From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> Sent: Thursday, April 30, 2020 11:39 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: RE: Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs In fairness, I couldn’t even be bothered reading further than the worlds BGP routers needing a firmware update to DOUBLE packet count whilst adding compute time at an individual packet level. Another idea, slightly marred by the unfathomable costs involved, along with its logistic impossibility. /me sits back and grabs the popcorn….. From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen Sent: 30 April 2020 21:31 To: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs Hello Ripe Members! I will share the following solution in the near General Meeting and I'm interested to share the following technical solution with you as well, it will completely resolve: Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking. And will dramatically lower: IoT botnet infections and Botnet C&Cs. By a single update to any BGP router, not any router needs to be updated, only active BGP routers. If I will have the honor of being elected to the Ripe Board I will harness all the power of Ripe and all of the 5 RIR's and all of the LIR's in the 5 RIR's so routing manufacturing companies will implement the below processes and methods with a single firmware update to their BGP routers. I'm asking for your support in electing me so I will be able to enter the Ripe Board and then I will be able to make everything which is written in this post to come true. Regarding the bgp-anycasted infrastructure written below, ICANN is written but the global bgp-anycasted infrastructure can be managed by the 5 RIR's and/or by the ccTLDs registries (my main point is that who will operate the bgp-anycasted infrastructure is not important for now, as long as it will be an agreed authoritative non-governmental non-commercial global entity/ies) With new tracking protocol over ip, routers will be able to confirm that source ip came from the network of the announcing ASN, and hence spoofed amplification DDoS attacks will be completely annihilated. The Process: At the source BGP router, for any ip packet with a source address that is from the network of the source BGP router (lets call it original ip packet) - the source BGP router will create a new ip packet (lets call it tracking ip packet) with a new transport layer protocol and with the same source address and with the same destination address and with the same IP-ID such as the original ip packet. In the new tracking ip packet there will be a new transport layer protocol (tracking protocol) with the following fields: AS number of source BGP router in clear text AS number of source BGP router encrypted with the private key of the source BGP router The destination BGP router (a BGP router that the destination address is in its network) whenever it receive a 'tracking ip packet' will check if its have the internal boolean 'Check tracking flag' in it - 'on' or 'off': If 'off' then the destination BGP router will drop that 'tracking ip packet' If 'on' then the destination BGP router will decrypt the 'encrypted AS number' with the public key of the specific AS number and after decryption the AS number need to be the result: if not then to drop the tracking ip packet and the original ip packet related to it if yes then to drop the tracking ip packet and to forward the related original ip packet to destination but only if the source address is originated from the specific ASN (according to the local ASNs+ranges table in the BGP router, such table will be received from ICANN) If the 'Check tracking flag' is set to 'on' then any original ip packet that arrive to the destination BGP router will wait for the related tracking ip packet (in case the related tracking ip packet didn't already arrived to the destination BGP router). The destination BGP router will manage such waiting for X number of seconds. The destination BGP router will match between a tracking ip packet and an original ip packet - based on their source address and their destination address and their IP-ID which will all be identical. More Aspects: - The end-devices will not need to be updated, any router will not need to be updated, only all the BGP routers will need to be updated. - Any BGP router in the routing path, which the original ip packet and the tracking ip packet are not destined to an ip address in its own network - will not check the content of the tracking ip packet and will forward both the tracking ip packet and the original ip packet as they are. - Each BGP router will have all the public keys (of all the ASN's) locally. - Each BGP router will have a full list of all the ASN's and all the route objects ranges which are related to them locally. How BGP routers will receive all the ranges in all the route objects of all the ASNs (in the 5 RIRs) and all the public keys of all the ASNs (for decrypting the encrypted strings in 'tracking ip packets'): - Each BGP router will create a tcp session with ICANN backend infrastructure (the backend infrastructure of ICANN will use BGP anycast and will be available from many locations worldwide with automatic syncing) - At this stage there will be a handshake process between the BGP router and the ICANN backend infrastructure in order for ICANN to know the correct ASN which is operating the BGP router - the BGP router will send its ASN in cleartext and also its ASN encrypted with its ICANN-communication-private-key , ICANN will know the related public key for the specific ASN from the specific ASN object in the RIR (the public key for communication with ICANN will be displayed there) - after decryption ICANN will compare the decrypted string to the AS Number for successful authentication. - After successful authentication, all the communication will be encrypted, ICANN will notify the BGP router about its public key and ICANN will use the public key of the ASN for the communication with ICANN - from the ASN object in the RIR. - The BGP router will send over the session its public key to be used by other BGP routers in order to decrypt the encrypted string in the tracking ip packets that it will originate (that private key and public key will be managed in the BGP router GUI or CLI). - ICANN will notify all the other BGP routers through the sessions with them about a newly updated such public key of any other BGP router. - ICANN will also receive in real-time any route object creation/modification/deletion notification from any of the 5 RIRs and will then update all the BGP routers through all of their sessions. - In case a BGP router doesn't have an active session to ICANN backend infrastructure (for any reason, might be due to networking issue) - then temporarily the internal 'Check tracking flag' of it will be set to 'off'. After the session with ICANN backend infrastructure will be re-established and the BGP router will receive all the meantime updates - the boolean value of 'Check internal flag' will return to initial state. - Any update from ICANN backend infrastructure to a BGP router (such as a public key of another BGP router, or a routing object update) - will be confirmed that the update was received well by the BGP router side. 'Check tracking flag' in BGP Routers: - BGP routers, in their GUI and CLI interfaces - will not allow the end-user to set the boolean value of 'Check tracking flag', in order to avoid misconfiguration. - The ICANN backend infrastructure through the session with the BGP router - will be able to set the boolean value of the 'Check tracking flag'. - The reason for it, is that if 'Check tracking flag' will be set on some destination BGP routers while some other source BGP routers weren't upgraded yet (and will not send the 'tracking ip packet' due to it) - then 'tracking ip packet' will never reach the destination BGP router and the internet will break. - Central setting of 'Check tracking flag' through ICANN backend infrastructure - will allow ICANN to inform all the BGP routers at once to switch 'on' the 'Check tracking flag' - ICANN, in the session to any BGP router, will also receive the percentage of ip packets that were destained to that BGP router network - that also had ip tracking packets, in this way ICANN will know when all the BGP routers were properly globally updated and when it is time to enable the 'Check tracking flag' in all the BGP routers. - ICANN will know if all the BGP routers in the world were upgraded based on keeping the full BGP table and comparing it to all the BGP routers that did and that did not open a session to ICANN backend infrastructure. Automatic preventation of IoT botnet infections: - IoT botnets are based on default credentials, if we can block default credentials of IoT devices then these kind of botnets (such as Mirai-variants and similar) will stop to have an impact in the internet. - The data field in an ip packet - will always be the same for an access attempt to a IoT device with default credentials - hence these kind of "IP protocol data fingerprints" which are related to specific "IP protocol numbers" will be provided by ICANN backend infrastructure to each BGP router through the opened session with it. - There are two issues with matching incoming ip packets to the "locally stored IP protocol data fingerprints" - the first one is that ip packets can be sent by fragments (so not all the data field will be sent at once in order to be able to be compared with the locally stored data fingerprints) and the second is that usernames (or url's) or any other textual data in the incoming ip packet data field can be in uppercase or in lowercase. In order to overcome the possibility of the existence of a single data fingerprint in multiple incoming ip packet fragments - then in case the BGP router is recognizing the incoming fragmented ip packet data value as part of an existing fingerprint data in its local database then it will keep track of the arrival ip packet fragments based on their specific IP-ID identifier and the BGP router will not forward the last ip packet fragment if the last ip packet fragment will cause all the related ip packet fragments to match a specific ip fingerprint data (last ip packet doesn't have to be the last fragmented part but it is the last ip packet that arrived with that IP-ID identifier, so the BGP router will keep track of the specific fragmented IP packets that arrived and their indexes in order to know when the last one of them arrived). Regarding the second issue - the stored data fingerprints in the local BGP router will be stored in a way that some bytes of them (in specific indexes) will not be compared and in case all the other bytes will match - then the bytes in these indexes - will first be lowered case - and only then comparison will be made to the specific indexed bytes in the specific ip packet data fingerprint. - In case a IoT device behind a BGP router will be infected somehow (for example when a specific fingerprint data with default credentials for a specific device wasn't updated yet through ICANN backend infrastructure), it will be able to infect all the other IoT devices in the local network when the connectivity to them is not through the BGP router, that kind of impact will be much much lower than infected IoT device which can infect any other IoT device in the internet and then massive botnets in the internet are created which are being used for DDoS. Automatic prevention of botnet C&C ip addresses: - Botnets C&C are also a problem in the internet. - This problem can be overcome using the following technical addition: the 5 RIR's will operate end-users honeypots machines all over the world (it will be implemented by a single physical machine in each location, for example in each datacenter and in each major ISP, each single physical machine will emulate a virtual router and virtual VM's, the virtual VM's will emulate many different kinds of 'real world machines', any kind of automatic updating (in the operating system configurations) will be disabled, these honeypots machines are not intended to make any outgoing connection, the virtual routers will monitor if any outgoing connection is made and if yes then it is to a botnet C&C, the virtual router will update the ICANN backend infrastructure regarding it and the ICANN backend infrastructure will update all the BGP routers (in their open sessions) regarding it to completely block any communication to that botnet C&C ip address. There will be a web-based system and only the related Law Enforcement Agency of that C&C ip address region - will be able to remove that C&C ip address from being blocked after their manual check. - Honeypot machines will be deployed using 'templates' - these templates must be signed and not anyone can create them, they should be created and signed by an agreed Law Enforcement Agency such as Interpol in order to make sure that these templates are by-design not making any outgoing connection. The templates will be deployed in an automatic way (major ISP's and datacenters will be able to easily add a 'physical honeypot' server in their network, that will be shipped to them), the re-initiation of a compromised 'virtual machine' that made an outgoing connection - will also be automatic through the system in the physical server. Respectfully, Elad _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/olof%40tulpsolutions…

3 4

Fw: You have my vote!
by Elad Cohen 30 Apr '20

30 Apr '20

Thank you Gabriel. Respectfully, Elad ________________________________________ From: Gabriel VOITIS <voitis(a)infinitytelecom.ro> Sent: Thursday, April 30, 2020 11:42 PM To: Elad Cohen Subject: You have my vote! -- Sent from mobile Mulțumesc, Gabriel VOITIS

1 0

UNSUBSCRIBE
by David Simmons 27 Apr '20

27 Apr '20

UNSUBSCRIBE

13 12

ban4flood
by Christian Rodler 27 Apr '20

27 Apr '20

Before most of us unsubscribe from this list: Would be nice if the "responsible" of this mailing list could find a way to ban a member for lets say one week if >x% of subscibers complain about (off-topics- coconuts or whatever). I never thought membes-discuss mailing list == Kindergarden Best regards, Christian Rodler -- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

2 1

Re: [members-discuss] Regarding Elad Cohen's nomination and emails
by Elad Cohen 27 Apr '20

27 Apr '20

Ed is lying, I'm not harassing him or anyone else off the list, Ed is the one keep emailing me directly when I asked him to stop doing it. Respectfully, Elad ________________________________ From: Ed Campbell Sent: Monday, April 27, 2020 4:47 PM To: Elad Cohen Cc: Chris Lawrence; Cynthia Revström; members-discuss(a)ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails All, This guy doesn’t know how to shut up. I would not normally do this but he is harassing me directly “off-list” and “off-topic”. The unprofessional approach he has taken to his responses should be enough to turn anyone away from him but he is now harassing me when asked not to. I have made an official complaint against him and will let the NCC deal with him. Kind regards, Ed On 27 Apr 2020, at 14:43, Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Chris, This wasn't my conversation, this was my response to an attack on me. Take your fake messages off the list. Respectfully, Elad ________________________________ From: Chris Lawrence <chris.lawrence(a)nomical.com<mailto:chris.lawrence@nomical.com>> Sent: Monday, April 27, 2020 3:44 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad Enough now this is beyond a joke.. Please take your conversations off the list. Regards Chris Chris Lawrence Senior Solutions Architect +44 344 384 3000<tel:+44%20344%20384%203000> +44 7775 871094<tel:+44%207775%20871094> nomical.com<http://nomical.com/> Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring. Nomical Ltd - Registered in England No: 06035958, VAT Reg No: 900363074, Registered Office: Mezzanine Floor, No.1 Spinningfields, Quay Street, Manchester M3 3JE From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> on behalf of Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Date: Monday, 27 April 2020 at 13:43 To: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>>, "members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>" <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails This is amazing how the illegal anonymous "The Spamhaus Project" members keep twisting the facts. Cynthia, Zero evidence was provided, not even a single proof, but still you claim "lots of evidence" I didn't say that anyone is part of "The Spamhaus Project" because disagree with me, I said that anyone is part of the illegal anonymous organization "The Spamhaus Project" because he is part of the illegal anonymous organization "The Spamhaus Project" - see how much you are personally targeting me - see how much you are protecting your sick friend RFG. Please don't interpret me - coconut means coconut - RFG is a coconut by anyone that knows him personally. Here is what your sick friend wrote: https://imgur.com/AcmgwEX (his opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (his opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (his opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantely ethical behavior, Chicago") https://imgur.com/AQCmZlk (RFG being identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (RFG being identified as antisemitic in Nanog) RFG called me in two names that one of them you wrote, you can keep with your lies and to defend a racist and an antisemitic person - but there is something which is called context, you can see in the first link above that RFG quoted Shakespeare regarding the Netherlands, when he called me in the name that you mentioned he did it after not providing not even a single proof against me and he specially used that name - which also in Shakespeare being referred to jews - you are defending a person which is a racist and an antisemitic according to all the above links. Respectfully, Elad ________________________________ From: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 2:50 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301… These are all complete lies only because I found out who are the real people behind "The Spamhaus Project" You can see how he is calling me there Everything there are lies and fake, the "source" for the fake media report is a member of "The Spamhaus Project" and also an employee of a direct competitor (that enjoyed from that fake media report) of a company which used the netblock, and the "source" is also the owner of that criminal twitter account:https://twitter.com/UnderTheBreach , he is a master of cyber influence operations according to his own words in his criminal twitter account and also a member of your cyber-security community. Respectfully, Elad ________________________________ From: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 2:14 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, please send me an archive link to the specific email on a RIPE/RIPE NCC mailing list where RFG called you a rude name. - Cynthia On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: He called me with antisemitic names many times and on many working groups and you said nothing, you claim not to see his messages, but you clearly saw all of my messages and you are monitoring me pretty well. I'm sorry but I don't believe you, specially when you are attacking me personally so heavily with distorting the facts. You clearly so the word coconut - so you also saw what I shared on the same post that he wrote on other groups of people and that he was called a racist and an antisemitic - but you decided to ignore this as well, so you didn't read my whole post - you read only the word 'coconut' and you decided to jump in ? Cynthia, please spread your lies somewhere else. Respectfully, Elad ________________________________ From: Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 2:05 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Elad, first of all, I am not an employee or in any way related to Spamhaus, and I doubt many of the people you have suggested are part of it have anything to do with it either. And because I have things to do that are not spending my entire days on RIPE mailing lists I guess I missed RFG calling you names, but I will assure you that if I was on those discussions I would call him out if he called you a "coconut" or similar. Also just because someone has called you names on mailing lists doesn't mean you get to call them names on mailing lists. - Cynthia On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> on behalf of Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] <ripe-md(a)c4inet.net<mailto:ripe-md@c4inet.net>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] <ripe-md(a)c4inet.net<mailto:ripe-md@c4inet.net>> wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

2 1

Re: [members-discuss] Regarding Elad Cohen's nomination and emails
by Cynthia Revström 27 Apr '20

27 Apr '20

Hi Elad, There are 3 major differences I see here, 1. rfg presents lots of evidence that you would have been involved in shady things (I am not sure if they are true and frankly I don't have time currently to look at all of the documents) Meanwhile you are saying that people are part of "The illegal anonymous Spamhaus Project" just because they disagree with you, and as you have said that I am involved in Spamhaus, I would like for you to give me any proof that I am involved with spamhaus in any way (which I am not). 2. rfg called you a "crook", which means dishonest or illegal, which would be true if the things rfg stated are in fact true. Meanwhile you called rfg a "coconut" which can't be anything other than an insult referring to you thinking he is dumb. 3. rfg called you a "crook" once in a long email after describing why he thinks you are a "crook", meanwhile you sent an email that I have posted in its entirety below. > START Michael, Ronald didn't insult me because he is mentally-illed, and he is doing it only because I found out who are the real people behind the illegal anonymous organization "The Spamhaus Project" which Coconut Guilmette and Cheerleader Nussbacher are part of. Respectfully, Elad > END Please just stop it Elad. Now I still think it was wrong of rfg to use that word, but it is not at all the same thing in my eyes. - Cynthia On Mon, Apr 27, 2020 at 1:36 PM Elad Cohen <elad(a)netstyle.io> wrote: > > https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2019-September/005301… > > These are all complete lies only because I found out who are the real > people behind "The Spamhaus Project" > > You can see how he is calling me there > > Everything there are lies and fake, the "source" for the fake media report > is a member of "The Spamhaus Project" and also an employee of a direct > competitor (that enjoyed from that fake media report) of a company which > used the netblock, and the "source" is also the owner of that criminal > twitter account: https://twitter.com/UnderTheBreach , he is a master of > cyber influence operations according to his own words in his criminal > twitter account and also a member of your cyber-security community. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revström <me(a)cynthia.re> > *Sent:* Monday, April 27, 2020 2:14 PM > *To:* Elad Cohen <elad(a)netstyle.io> > *Cc:* members-discuss(a)ripe.net <members-discuss(a)ripe.net> > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, please send me an archive link to the specific email on a RIPE/RIPE > NCC mailing list where RFG called you a rude name. > > - Cynthia > > On Mon, Apr 27, 2020 at 1:12 PM Elad Cohen <elad(a)netstyle.io> wrote: > > He called me with antisemitic names many times and on many working groups > and you said nothing, you claim not to see his messages, but you clearly > saw all of my messages and you are monitoring me pretty well. I'm sorry but > I don't believe you, specially when you are attacking me personally so > heavily with distorting the facts. You clearly so the word coconut - so you > also saw what I shared on the same post that he wrote on other groups of > people and that he was called a racist and an antisemitic - but you decided > to ignore this as well, so you didn't read my whole post - you read only > the word 'coconut' and you decided to jump in ? > > Cynthia, please spread your lies somewhere else. > > Respectfully, > Elad > ------------------------------ > *From:* Cynthia Revström <me(a)cynthia.re> > *Sent:* Monday, April 27, 2020 2:05 PM > *To:* Elad Cohen <elad(a)netstyle.io> > *Cc:* members-discuss(a)ripe.net <members-discuss(a)ripe.net> > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > Elad, first of all, I am not an employee or in any way related to > Spamhaus, and I doubt many of the people you have suggested are part of it > have anything to do with it either. > > And because I have things to do that are not spending my entire days on > RIPE mailing lists I guess I missed RFG calling you names, but I will > assure you that if I was on those discussions I would call him out if he > called you a "coconut" or similar. > Also just because someone has called you names on mailing lists doesn't > mean you get to call them names on mailing lists. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:58 PM Elad Cohen <elad(a)netstyle.io> wrote: > > Cynthia, > > The sick person which you are referring to and is your colleague from "The > Spamhaus Project", defamed me for many many months, here in Ripe and in > Nanog, he called me by many names without a single proof. He was called an > antisemitic and a racist not by me - but by people which are not related > to me in Nanog. After many months I provided an official response in Ripe. > I didn't hear your voice when he defamed me for many many months with him > calling me by many names. So obviously your interests are hidden. > > In the other working groups - I only replied to him, and I didn't hear > your voice regarding your sick colleague initial message with name callings > towards me when I only replied to his attack on me. And his personal attack > on me is exactly like your personal attack on me now - you are afraid that > an alternative solution to "The Spamhaus Project" will be implemented if I > will be elected. > > Respectfully, > Elad > ------------------------------ > *From:* members-discuss <members-discuss-bounces(a)ripe.net> on behalf of > Cynthia Revström <me(a)cynthia.re> > *Sent:* Monday, April 27, 2020 1:50 PM > *To:* Sascha Luck [ml] <ripe-md(a)c4inet.net> > *Cc:* members-discuss(a)ripe.net <members-discuss(a)ripe.net> > *Subject:* Re: [members-discuss] Regarding Elad Cohen's nomination and > emails > > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. > > AFAIK there are no WG chairs of members-discuss and members-discuss is a > mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE > NCC membership related topics, so I think they certainly have business > enforcing people to be professional on this mailing list. > > I would also like to add that Elad has multiple times on different mailing > lists ignored the WG chairs. > Also this is happening across a variety of RIPE/RIPE NCC mailing lists > that are all hosted by the RIPE NCC and as such I think it is their > business to keep them to a professional standard. > > > If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > > There should not be a long list of people, but when someone is behaving > unprofessionally, calling people "coconut", being defamatory towards the > RIPE NCC, ignoring WG chairs, I do think that they have gone too far and > everything has a limit. > Like we wouldn't allow someone to send sales emails to the mailing list as > an example, aka limits on what is allowed. > > - Cynthia > > On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] <ripe-md(a)c4inet.net> > wrote: > > On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: > >I would like to propose that the RIPE NCC ban Elad Cohen from interacting > >with the RIPE Community (via Meetings or mailing lists) due to his blatant > >disregard for the Code of Conduct and for being hostile towards others in > >the community. As the RIPE NCC hosts and manages these lists I think the > >RIPE NCC has a responsibility to keep the lists professional and to remove > >those who repeatedly ignore what the WG chairs are saying. > > The RIPE *NCC* has no business either enforcing "professionality" > on the *community* mailing lists - this is the WG chairs' > responsibility. Nor do I think the NCC should determine who can > be a member of the RIPE community or not. If I'm wrong, where do > I submit the list of people I'd like to see excluded from the > community? > I think this proposal is the most out-of-order thing I've yet > seen in this thread. > > rgds, > Sascha Luck > > > > >- Cynthia > > >_______________________________________________ > >members-discuss mailing list > >members-discuss(a)ripe.net > >https://lists.ripe.net/mailman/listinfo/members-discuss > >Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > > _______________________________________________ > members-discuss mailing list > members-discuss(a)ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re > >

8 8

Re: [members-discuss] Unsubscribing
by Hans Govenius 27 Apr '20

27 Apr '20

Hello I promised, nothing more on the topic. And there aint. Many are trying to unsubscribe and many are accusing someone trying to unsubscribe them without permission/to do harm etc. I think this is simply a simple misunderstanding. When there people who say they hit time and time again the unsubscribe button and nothing helps I think you are pressing these links on the emails for example: >_______________________________________________ >members-discuss mailing list >members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re This is now the last rows on this matter. If I would just press this and hope to be unsubscribed, it would maybe not happen. I would try to unsubscribe Cyntia I guess? I would be left wondering that I didn’t get out of the list and Cynthia would be sending Spy´s and police after my IP 😊 Atleast im quite sure those both cant work. Either both are not working for *ME* or only one of them is working… Or then I can only unsubscribe after I have actually sent a message and I might then get this unsub link which would work for me? br. Hans Lähettäjä: members-discuss <members-discuss-bounces(a)ripe.net> Puolesta Elad Cohen Lähetetty: maanantai 27. huhtikuuta 2020 13.59 Vastaanottaja: Cynthia Revström <me(a)cynthia.re>; Sascha Luck [ml] <ripe-md(a)c4inet.net> Kopio: members-discuss(a)ripe.net Aihe: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Cynthia, The sick person which you are referring to and is your colleague from "The Spamhaus Project", defamed me for many many months, here in Ripe and in Nanog, he called me by many names without a single proof. He was called an antisemitic and a racist not by me - but by people which are not related to me in Nanog. After many months I provided an official response in Ripe. I didn't hear your voice when he defamed me for many many months with him calling me by many names. So obviously your interests are hidden. In the other working groups - I only replied to him, and I didn't hear your voice regarding your sick colleague initial message with name callings towards me when I only replied to his attack on me. And his personal attack on me is exactly like your personal attack on me now - you are afraid that an alternative solution to "The Spamhaus Project" will be implemented if I will be elected. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> on behalf of Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> Sent: Monday, April 27, 2020 1:50 PM To: Sascha Luck [ml] <ripe-md(a)c4inet.net<mailto:ripe-md@c4inet.net>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@ripe.net>> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails > The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. AFAIK there are no WG chairs of members-discuss and members-discuss is a mailing list that the RIPE NCC hosts to let RIPE NCC members discuss RIPE NCC membership related topics, so I think they certainly have business enforcing people to be professional on this mailing list. I would also like to add that Elad has multiple times on different mailing lists ignored the WG chairs. Also this is happening across a variety of RIPE/RIPE NCC mailing lists that are all hosted by the RIPE NCC and as such I think it is their business to keep them to a professional standard. > If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? There should not be a long list of people, but when someone is behaving unprofessionally, calling people "coconut", being defamatory towards the RIPE NCC, ignoring WG chairs, I do think that they have gone too far and everything has a limit. Like we wouldn't allow someone to send sales emails to the mailing list as an example, aka limits on what is allowed. - Cynthia On Mon, Apr 27, 2020 at 12:43 PM Sascha Luck [ml] <ripe-md(a)c4inet.net<mailto:ripe-md@c4inet.net>> wrote: On Mon, Apr 27, 2020 at 12:02:59AM +0200, Cynthia Revstrm wrote: >I would like to propose that the RIPE NCC ban Elad Cohen from interacting >with the RIPE Community (via Meetings or mailing lists) due to his blatant >disregard for the Code of Conduct and for being hostile towards others in >the community. As the RIPE NCC hosts and manages these lists I think the >RIPE NCC has a responsibility to keep the lists professional and to remove >those who repeatedly ignore what the WG chairs are saying. The RIPE *NCC* has no business either enforcing "professionality" on the *community* mailing lists - this is the WG chairs' responsibility. Nor do I think the NCC should determine who can be a member of the RIPE community or not. If I'm wrong, where do I submit the list of people I'd like to see excluded from the community? I think this proposal is the most out-of-order thing I've yet seen in this thread. rgds, Sascha Luck > >- Cynthia >_______________________________________________ >members-discuss mailing list >members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> >https://lists.ripe.net/mailman/listinfo/members-discuss >Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re

3 4

Regarding Elad Cohen's nomination and emails
by Cynthia Revström 27 Apr '20

27 Apr '20

Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-func… . I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia

20 36

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
by Elad Cohen 27 Apr '20

27 Apr '20

Gert, It is completely repulsive what you are doing here, me sharing an idea and the implementation of it and you wrote what you wrote. To the community: Anyone that knows me know that everything I write can be implemented, Gert didn't say that it cannot be implemented - just that modifying the networking stacks is hard - if it it is hard then better developers are needed that it will be easy for them - I'm not going to waste my time on implementing the patches to the networking stacks for Microsoft/Google/Apple/etc - they have their own engineers. I have enough experience in development to know that the reserved bit activation and ipv4 packet modification in the networking stack will not be time consuming such as creating a complete new protocol family, any operating system vendor have enough engineers that can together do it quickly. If after reading everything that I wrote you are calling it a cheap shot then you are not a professional and your background mean nothing (professional people will be able to read algorithems and methods and to know if they works or not, with implementing them in their heads, without to see it in their eyes the electrical signals flowing between machines). Keep on Gert to defame me after I explained this idea and implementation to the community, the difference between us is that I have the decency to know that I know nothing and I always strive to learn, you will not see me pat my ego like you just did, if you don't have something useful to say then go back to your two-threads working group. I didn't promise anything, as long there are hateful people like - nothing good will happen. Respectfully, Elad ________________________________ From: Gert Doering Sent: Sunday, April 26, 2020 12:09 PM To: Bruno Cordioli Cc: Elad Cohen; members-discuss(a)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, Apr 26, 2020 at 10:51:13AM +0200, Bruno Cordioli wrote: > I think it is appropriate to close this discussion here. > Elad will eventually submit his proposed al RIPE meeting or he'll write a > RFC. Basically, this. The Internet (and the address distribution towards IANA and the RIRs) operates based on IETF standards, and as long as there is no IETF standard for IPv4+, it cannot be implemented in an interoperable way, and can not be deployed. Elad, this is your avenue: you need to demonstrate two working and interoperating implementations for two host stacks and two router stacks. Just claming "it is easy" is not sufficient. I'm with Christian here: this can not work without significant changes to the BSD socket API, to applications using this API - basically, everything on Unix/Linux - to the Windows networking API, and to routers in the ISP networks that need to decide "which customer is this packet sent to?" based on the extra bit. And I speak with a certain background on implementing network applications, running an ISP network, and debugging TCP/IP stacks. Overall, as long as no implementations can be provided (source code on github etc) this sounds like a somewhat cheap shot to make people believe you're going to solve their IPv4 problems if they just vote you to the NCC executive board. And I hope the NCC members are smart enough to not vote based on glorious promises, but on track record, provable background, etc. Gert Doering -- RIPE member -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

7 8

Re: [members-discuss] Regarding Elad Cohen's nomination and emails
by Elad Cohen 27 Apr '20

27 Apr '20

Hello, Is it possible for anyone with hidden intentions not to post on this list ? Henrik, you could just write "I don't vote for Elad" - no need to try to spread lies to the community - can you provide a single proof to the lies that you wrote about me ? as I already wrote - the "source" in the fake media report is a person in "The Spamhaus Project" and an employee of a direct business competitor and also the owner of that criminal twitter account: https://twitter.com/underthebreach The "source" of the fake media report as you can see in his "anonymous" twitter account linked above - is a master of cyber influence operations - and this is exactly what being done here - spreading of lies and conspiracies and fake theories about me without a single proof. I didn't share any conspiracies, I only provided a link to a presentation of "The Spamhaus Project" that they wrote on themselves and they presented in a private event - According to their own words they are an illegal anonymous organization. "The Spamhaus Project" is related to the cyber-security community mainly in Western countries - so indeed Henrik is from the cyber-security community, expect more wannabe "security researchers" to write lies about me. "The Spamhaus Project" keeps attacking me because they know that if I will be elected I will make sure that they will not hurt anymore any Ripe LIR member. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces(a)ripe.net> on behalf of hlk via members-discuss <members-discuss(a)ripe.net> Sent: Monday, April 27, 2020 1:25 PM To: Filip Hruska <fhr(a)fhrnet.eu>; members-discuss(a)ripe.net <members-discuss(a)ripe.net> Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello all, and sorry for top posting mobile device. The amount of noise generated by Elad Cohen and unwillingness to listen has degraded the lists. Polite rejections of his proposals have quickly degenerated into name calling and conspiracy theories by him. I am not affiliated with RIPE NCC other than being a LIR, I do not know Elad Cohen before these threads. Quick searches on his name show dubious business practices, as seen with regards to prefix hijacking. I consider his actions on the list very close to overstepping Code of Conduct, and good intentions. I fully support both him being moderated on the list, and not being eligble for a position as RIPE chair or similar for the moment. Best regards Henrik Kramselund Jereminsen, owner of dk.zencurity -------- Original message -------- From: Filip Hruska <fhr(a)fhrnet.eu> Date: 4/27/20 01:05 (GMT+01:00) To: members-discuss(a)ripe.net Subject: Re: [members-discuss] Regarding Elad Cohen's nomination and emails Hello all, I would like to voice my support for this. The amount of unprofessional conduct in the past 2 or 3 email chains is simply ridiculous and completely unacceptable. Thank you, Filip On 4/27/20 12:44 AM, Joseph Marsden wrote: I support Cynthia's request for a formal investigation. Best Joseph On 26/04/2020 23:24, Cynthia Revström wrote: I would also like to formally request that the RIPE NCC investigate if Elad Cohen has breached A.1.2.2.B of RIPE-716. https://www.ripe.net/publications/docs/ripe-716#a122b This is with regards to statements like this: "Ripe have 30 millions euros of expenses each year that are hidden and now shown to where exactly they are paid, instead of that corruption" I believe that he does indeed make unreasonable allegations towards the RIPE NCC to damage it's reputation. - Cynthia On Mon, Apr 27, 2020 at 12:02 AM Cynthia Revström <me(a)cynthia.re<mailto:me@cynthia.re>> wrote: Hello, I would like to request that Elad Cohen be blocked from sending to the members-discuss mailing lists after multiple offtopic threads started by Elad and the personal attacks and ignoring WG chairs telling Elad to stop. I would further like to point out that as he is a confirmed candidate for the Exec Board, one of his key responsibilities would be to have the "Ability to communicate effectively", which he has shown that he is not capable of. I would personally say that elad lacks most of the expectations listed on https://www.ripe.net/about-us/executive-board/ripe-ncc-executive-board-func…. I would like to propose that the RIPE NCC ban Elad Cohen from interacting with the RIPE Community (via Meetings or mailing lists) due to his blatant disregard for the Code of Conduct and for being hostile towards others in the community. As the RIPE NCC hosts and manages these lists I think the RIPE NCC has a responsibility to keep the lists professional and to remove those who repeatedly ignore what the WG chairs are saying. - Cynthia _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/joseph%40arctarus.co… _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/fhr%40fhrnet.eu

1 0

Technical Solution to resolve the global "Email Spam" problem
by Elad Cohen 27 Apr '20

27 Apr '20

Hello Everyone, I want to share with you my technical solution to resolve the global world "Email Spam" problem and in addition it will also resolve the spreading of illegal links (phishing/malware/etc , once the sites are known) through electronic mail and will stop email spoofing (that part using current technologies). Email spam problem was not being able to be defeated since the beginning of electronic mail, as long as email spam will be profitable to email spammers - it will exist, email spam caused the illegal anonymous organization "The Spamhaus Project" to exist, "The Spamhaus Project" is hurting and damaging many businesses worldwide in their way to fight email spam, "The Spamhaus Project" is an illegal anonymous organization according to the following presentation that they wrote on themselves, they are violating laws in their way to fight email spam and still they don't win in the battle against email spam. "The Spamhaus Project" is keeping their anonymity because they are afriad of justified lawsuits due to their criminal actions in their way to fight email spam. The following technical solution will resolve the world email spam problem without to hurt and to damage many businesses worldwide that have nothing to do with email spam like "The Spamhaus Project" does, the following implementation can remove the need for an illegal anonymous organization such as "The Spamhaus Project". The presentation that the illegal anonymous organization "The Spamhaus Project" wrote on themselves: https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Vio… The Implementation: There will be a site (lets call it NoSpam.org) - the site will be owned by the 5 RIRs, the site will use bgp anycast and will be deployed in each of the 5 RIRs (the site will also be able to be deployed by the ccTLD registries in each country), the site in all the locations will be synced automatically. Each domain owner will be able to register at the site (an email message will be sent to the domain owner email address in the domain name WHOIS details in order to verify that the domain owner is the one registering). After being logged in, a domain owner will be able to add his email addresses (of the specific domain name) that will be used to send newsletters / mailing lists / one-to-many email messages, lets call these kind of email addresses as 'mailing list' email addresses. The domain owner will not be able to see the list of 'mailing list' email addresses that he added - because when he added each 'mailing list' email address it will be saved with hash in the NoSpam.org backend infrastructure (due to privacy and security reasons) - hence only if the domain owner will manually type the 'mailing list' email address he will be able to enter it in order to manage it (to see the total number of subscribers email addresses, to see the subscribers email addresses but only with their hashes due to security and privacy reasons, to remove a subscriber from the list, to add a sub-user with permissions to manage that specific 'mailing list' email address). In his site, the domain owner will be able to integrate an iframe from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a subscriber registration form to his specific 'mailing list' email address, the subscriber will receive an email message with a link to confirm his subscription. The domain owner will need to create a callback file in his website, for example in the path: "/nospam-notification-callback" (http://example.com/nospam-notification-callback) - that url will receive encrypted post notifications (encryption key will be provided by the domain owner in his NoSpam.org logged in account) from NoSpam.org regarding any new end-user that will subscribe or that will unsubscribe from a 'mailing address' email address which is related to the domain of the domain owner (unsubscribe functionality by the user later below). The subscriber email address and that 'mailing list' email address (that was subscribed to) will be sent by NoSpam.org to "/nospam-notification-callback" not in the hashed format but in cleartext (so the domain owner will be able to save it in his system for future email messages from the specific 'mailing list' email address to the specific subscriber email address). The domain owner will also have an API to NoSpam.org backend infrastructure in order to remove a specific subscriber email address from a specific 'mailing list' email address (the domains owner will send the values through the API - hashed). The domain owner will also provide a web interface in his site for the end-user to remove himself from the specific 'mailing list' email address. The above is the backend implementation (no upgrade is needed to any email server in the internet), the following is the upgrade that will needed for any email client (that upgrade is not mandatory, without the following upgrade the email client will work exactly as it is now without the added no-spam features, electronic mail will not break if some email users will upgrade their email clients and some will not): - There will not be 'mark as spam' button, that kind of functionality will stop to exist because spam is not a boolean value, 'spam' to one person is valuable to another 'person', specially when the internet is global and different people from different countries will consider spam content differently. One user can consider an email message as spam and another user can consider the same message as not spam, 'Spam' is subjective and any kind of 'mark as spam' functionality is useless in the battle against email spam. - There will be blacklists and whitelists (just like there are now, but they will be more prominent): blacklist email addresses , blacklist domains , whitelist email addresses , whitelist domains. - The end-user should be able to easily enter each email message to whitelist or to blacklist (meaning the 'from' email address of the email message), and will be able to search in the 'Spam' folder easily for an email address (these features can exist today, but they should be given more visibility, so end-users will use them more). - The end-user will be able to import/export his whitelists and blacklists using an xml format to any other upgraded email client, the blacklists and whitelists will be local (end-user will be able to pass the local whitelists and blacklists to another email client of his with the click of a button in the upgraded email client - the upgraded email client will just send them to itself - without to download them from the email server so the end-user will be able to download it with another upgraded email client - or the end-user will be able to send the whitelists and blacklists to another email address of him, the usage will not be like sending regular email message with attachments - the upgraded email clients will take care to sending and receiving of the blacklists and whitelits - in the background, these are custom formatted email messages that the two upgraded email clients will know how to act upon them). - The email client will be able to display with GUI with buttons any 'mailing-list registration confirmation email' in a specific section related to registration to new 'mailing list' email addresses for the end-user to choose with buttons if he accept or refuse to register to a specific 'mailing list' email address. - For any email message that was received: in case a received 'from' email address was found in the whitelist email addresses or in the whitelist domains - then it will be moved to the 'Inbox' folder, in case the 'from' email address of the email message was found in the blacklist email addresses or in the blacklist domains - then the email message will be moved to the 'Trash' folder. - In case the 'from' email address or domain was not found in the whitelists and in the blacklists, then the upgraded email client will send the 'from' email address and the 'from' domain and the current user email address and the external links that exist in the email message (but all of these data will be sent in a hashed way, and not in cleartext) with a query to NoSpam.org backend infrastructure, NoSpam.org will perform the following algorithem after it: - If the hashed 'from' domain (or any other 'hashed' domain from the external links) exist in a list of criminals hashed domains (of phishing/malware/viruses/etc) then NoSpam.org will respond to the email client to delete the email message, otherwise the hashed 'from' email address will be checked against a list of hashed 'mailing list' email addresses - if found then the sender is a 'mailing list' email address and there will be a check by NoSpam.org backend infrastructure if the hashed 'receiver' email address is a subscriber of that specific 'mailing list' email address , if the hashed 'receiver' was found then NoSpam.org will send a response to the email client that the email message can be displayed in the 'Inbox' folder and in the response NoSpam.org will also include an unsubscribe key - the email client will be able to display an unsubscribe button to the email client and if clicked the email client will send an https request to NoSpam.org with the specific unsubscribe key, NoSpam.org backend infrastructure will remove the end-user email address from the 'mailing list' email address and will notify the domain owner at the domain owner callback url "/nospam-notification-callback" that the specific user unsubscribed. In case the hashed 'receiver' wasn't found then NoSpam.org will respond to the email client to delete the email message and NoSpam.org will also notify the callback url of the related domain owner that he shouldn't send email messages from the specific 'mailing list' email address to the specific subscriber email address. - In case when NoSpam.org backend infrastructure searched the hashed 'from' email address and it wasn't found in the list of all hashed 'mailing list' email addresses, it mean that the email address was sent from a 'personal' email address and NoSpam.org backend infrastructure will notify the email client that the email message is from a 'personal' email address - the email client in that stage will need to decide if to move the email message to the 'Inbox' folder or to the 'Spam' folder based on the following - the email client will check if the email message include links/images/plain-url's - and if yes then the email message will be moved to the 'Spam' folder, otherwise it will be moved to the 'Inbox' folder. Whitelist Handshake: - In order to facilitate the adding of new email address to the local whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist Handshake' is a GUI representation in two email clients regarding background email messages between them (that the two end-users don't see), "end-user A" with a click of a button will be able to send 'add me to whitelist' request to "end-user B" which will be able to accept or deny and if accepted then "end-user B" will be able to automatically send the same "add me to whitelist" request to "end-user A" , all of this communication will be done behind the scenes, these special email messages will not be visible to the end-users, end-users will see popups with GUI that email address X is asking to be added to whitelist. In order for spammers not to abuse this option - the email client will keep only one 'whitelist request' from each requester email address (there will be a 'whitelist requests' section in the upgraded email client). A repeated 'whitelist request' that came from a specific email address can never be raised in the list (unless the end-user will specifically search for it) even when the sender will send more and more 'add me to whitelist' requests - no priority will given to them, and once an end-user refused an 'add me to whitelist' request - no new 'add me to whitelist' request will be shown from the specific sender email address in the specific email client. - There can be a case that an upgraded email client will send 'add me to whitelist' request to a not-upgraded email client and then the receiver will see the request as it is - as an email message in the inbox folder - due to it the content of that message will be in the language of the domain TLD of the receiver email address and the content in the email message will explain what is NoSpam.org and how to upgrade the email client and supported upgraded email clients, etc - In the 'whitelist requests section' in the upgraded email client - the whitelist requests will appear in a list - there should be preference so some requests will appear upper and other lower (so requests from spammers will appear lower) - whitelist requests from email addresses of domains which are older (according to their WHOIS details) will appear upper than whitelist requests from email addresses of domains which are newer. Whitelist requests from a list of a more-trusted-domains (domains of known webmails service, universities, governments, etc) will have preference over other domains, specific TLDs that not anyone can purchase will also have preference over other TLDs that anyone can purchase (upgraded email clients will retrieve the list of trusted TLD's and Domains each day from NoSpam.org backend infrastructure). Notification of spam emails: - An additional feature in the upgraded email client is that whenever an email message will reach the 'Spam' folder - the email client will send in the background a known-format email message to the sender and will notify him about it, if the sender is using an upgraded email client then it will be able to automatically send a 'add me to whitelist' request to the receiver in the background (once an email address is whitelisted - all the email messages from it will move from 'Spam' to 'Inbox'). Email Spoofing: - In an upgraded email client, email messages from 'personal' email addresses cannot arrive from email relay server, in case it happen the message will be deleted and the email client will send an automatic email message in the background to the sender with the text (in the language of the sender domain TLD) that email messages from 'email relay servers' cannot be received from him. - In an upgraded email client, email messages from 'mailing list' email addresses can arrive from email relay servers - but they must be encrypted with DKIM. - In an upgraded email client, the email client should check the SPF txt dns record of the sender domain, and will drop the email message if it is a spoofed email message. - DNS servers developers will need to make the SPF txt dns record to be a mandatory field for every domain, in order for email spoofing to be annihilated. Security Aspects: - All stored data in NoSpam.org Backend infrastructure is hashed. - The criminals domains list in NoSpam.org Backend Infrastructure will be managed only by regulated supervised Law Enforcement Agency (for example: Interpol) and not by an internet organization such as the RIRs or ccTLD registries. - Domains owners will have 'forgot password' functionality to their NoSpam.org account, the password reset link will be sent to the email address of the owner of the domain according to the domain WHOIS details. - Communication between email clients to NoSpam.org backend infrastructure will be over https, there will only be an handshake process in the beginning over electronic mail between email client and NoSpam.org backend infrastructure - the email client will send an email message with a chosen key to an email address of @nospam.org (that key will be used in further communication between the email client and the NoSpam.org backend infrastructure over https, it will be used for NoSpam.org backend infrastructure to identify the specific email address over https, so anyone will not be able to query NoSpam.org backend infrastructure to know which hashed email address belongs to which hashed 'mailing list' email address, besides the email client user with the right key to query NoSpam.org Backend infrastructure only on himself). - Any email client will download once per day 'spam-rules' file from NoSpam.org backend infrastructure, 'spam-rules' file will be an xml formatted file that include rules of when to move an email message that was received from 'personal' email address which is not whitelisted to the 'Spam' folder (for example, when email have at least 1/2/3 links, when email format is rich text or html and not plaintext, etc), in case future adjustments will be needed to win the battle against email spam - email clients will not need to be upgraded, the new 'spam-rules' will be updated in this daily file. To make it short: - Any email message from a subscribed mailing list / newsletter / etc - will reach to the inbox (that kind of email messages can contain any kind of content without any restrictions, because the user subscribed to it and the user can unsubscribe from it at anytime). - Any email message from an email address or domain in whitelist - will reach the inbox. - Whitelist Handshake process is easy to use and being implemented with clicks of a button, nothing to type. - In case an email message will the 'Spam' folder - an automatic email message will be sent from the receiver to sender and sender can automatically ask to be added to the receiver's whitelist. - Any email message without links/images/plain-url's (plain email messages, like electronic email was) - will reach the inbox. - Any other email will reach the 'Spam' folder - if needed the user will be able to easily whitelist the email message in the 'Spam' folder. Spammers need links in their email messages for monetization, above solution blocks it and also block criminal domains links in email message and implement email spoofing blocking at client-side. We will all stop to receive more than 100 spam email messages per day with the above solution. Respectfully, Elad

20 52

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
by Elad Cohen 26 Apr '20

26 Apr '20

Sander is taking part in an illegal cyber influence operation against me. Sander, instead of lying and acting like a coward with other interests, go ahead and ask me publicly any question that you would like regarding IPv4+ and you will be answered. Respectfully, Elad ________________________________ From: Sander Steffann Sent: Sunday, April 26, 2020 12:40 PM To: Elad Cohen Cc: Gert Döring; members-discuss(a)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, > What being done here is a cyber influence operation against me, after I'm only trying to do good to the community. > > Sander, you didn't mention any flaws, can you please write them here and I will answer each and every one of them ? This is not the place Elad. Many flaws have been pointed out to you already, but you just dismiss them. Take this to the IETF, you'll feel right at home… * Cheers, Sander * for those who don't follow the IETF, there is an appeal ongoing about IETF chairs and ADs ignoring inconvenient questions and objections

6 18

Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
by Elad Cohen 26 Apr '20

26 Apr '20

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

16 39

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
by Elad Cohen 26 Apr '20

26 Apr '20

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 ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:51 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss(a)ripe.net Subject: AW: [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 You cannot be sure to have MTU of 1500 everywhere… Normally routers should not do anything with df bit, but it is possible to flip the df bit on the router. It is required for some cases. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen <elad(a)netstyle.io> Gesendet: Sonntag, 26. April 2020 09:48 An: Tobias Lehner <tl(a)hartl-edv.de>; 'noc' <noc(a)xervers.pt>; Ed Campbell <campbell(a)inca.ie> Cc: members-discuss(a)ripe.net Betreff: 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 Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: AW: [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, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Betreff: 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 Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Assunto: 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 Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 IPv6 isn’t slow because of the lack of trying, it is slow because of Microsoft et al’s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a “nice to have” “feature” attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this “new” IPv4 space, that just doesn’t track with the current demand for addressing. You’d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>> Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; Atif Naveed <a.naveed(a)go.com.sa<mailto:a.naveed@go.com.sa>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It’s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it’s "new“ but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed <a.naveed(a)go.com.sa<mailto:a.naveed@go.com.sa>>; Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I’m not sure there is a Tier1 who doesn’t offer IPv6. > Most UK ISP’s now provide IPv6 by default to people’s homes. > > I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed@go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed@go.com.sa > www.go.com.sa<http://www.go.com.sa> > > From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP’s? > What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad@netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > • Any routing device with more than two physical routes > • Any BGP router > • Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<members-discuss(a)ripe.net<mailto:members-discuss@ripe.net%3cmembers-discuss@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 > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>> > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > <image001.jpg> > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > <image002.jpg> <image002.jpg> > <image002.jpg> <image003.jpg> > > > De: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen > Enviada: sábado, 25 de abril de 2020 20:21 > Para: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> > Assunto: [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 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(a)ripe.net<mailto:members-discuss@ripe.net> > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40int… _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

11 22

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
by Elad Cohen 26 Apr '20

26 Apr '20

Did you see any implementation of a router that on its own flip the DF bit? According to all of my checks it doesn't happen - the fragmentation bits are reliable - meaning not modified by routers in the routing path. No every router in world will need to be updated, in a case that a router will flip the DF bit (there is no online record of such case to happen that routers change on their own fragmentation bits, in the whole internet) then the IPv4+ packet will not reach the destination in the initial "IPv4+ UDP Handshake" and hence the communication (after a successfull "IPv4+ UDP Handshake") will not happen. Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 11:01 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss(a)ripe.net Subject: AW: [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 Then you need to update software of all routers. Any router in the path must not switch the df bit. Every piece of network hardware must be verified or updated, which would cause a big delay in implementing. If it is not checked some router may flip the df bit and you would not get a connectoin. I guess to setup IPv6 is more straightforward and would not cause this delay. Because we have it already. It is a nice idea of you but it will fail at the implementing or causes several delay. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen <elad(a)netstyle.io> Gesendet: Sonntag, 26. April 2020 09:54 An: Tobias Lehner <tl(a)hartl-edv.de>; 'noc' <noc(a)xervers.pt>; Ed Campbell <campbell(a)inca.ie> Cc: members-discuss(a)ripe.net Betreff: 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 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 ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:51 AM To: Elad Cohen; 'noc'; Ed Campbell Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: AW: [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 You cannot be sure to have MTU of 1500 everywhere… Normally routers should not do anything with df bit, but it is possible to flip the df bit on the router. It is required for some cases. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Gesendet: Sonntag, 26. April 2020 09:48 An: Tobias Lehner <tl(a)hartl-edv.de<mailto:tl@hartl-edv.de>>; 'noc' <noc(a)xervers.pt<mailto:noc@xervers.pt>>; Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Betreff: 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 Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Subject: AW: [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, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Betreff: 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 Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Assunto: 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 Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 IPv6 isn’t slow because of the lack of trying, it is slow because of Microsoft et al’s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a “nice to have” “feature” attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this “new” IPv4 space, that just doesn’t track with the current demand for addressing. You’d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>> Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; Atif Naveed <a.naveed(a)go.com.sa<mailto:a.naveed@go.com.sa>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It’s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it’s "new“ but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed <a.naveed(a)go.com.sa<mailto:a.naveed@go.com.sa>>; Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I’m not sure there is a Tier1 who doesn’t offer IPv6. > Most UK ISP’s now provide IPv6 by default to people’s homes. > > I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed@go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed@go.com.sa > www.go.com.sa<http://www.go.com.sa> > > From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP’s? > What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad@netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > • Any routing device with more than two physical routes > • Any BGP router > • Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<members-discuss(a)ripe.net<mailto:members-discuss@ripe.net%3cmembers-discuss@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 > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>> > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > <image001.jpg> > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > <image002.jpg> <image002.jpg> > <image002.jpg> <image003.jpg> > > > De: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen > Enviada: sábado, 25 de abril de 2020 20:21 > Para: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> > Assunto: [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 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(a)ripe.net<mailto:members-discuss@ripe.net> > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40int… _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

1 0

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
by Elad Cohen 26 Apr '20

26 Apr '20

Tobias, Routers will not do anything with the DF and MF flags as long that MTU is fine (and MTU is initially checked with "IPv4+ UDP Handshake") I wrote in previous reply an adjustment to the idea that is quicker to deploy and will not require the routers, but it will lack the RIRs being able to allocate and to assign IPv4+ addresses to LIRs. Each LIR will automatically receive an additional IPv4 address for each current IPv4 address that it have: -------- Here is an optional adjustment to the idea: Only end-users and servers operating systems will be updated (using the operating systems automatic updating mechanism), using the same way that I wrote with the exact same feasible IPv4 packet modification implementation (reserved bit, no fragmentation, fragmentation flags, udp handshake), no other equipment will need to be updated, no routers will need to be updated at all - but then the routing of IPv4+ addresses will always be to the same destination device that have the same four bytes of destination IPv4 address (meaning routing will be as it is now - based on IPv4 and not on IPv4+). In this way, the number of IPv4 addresses will be doubled and each ASN will double his number of IPv4 addresses, each ASN will have his exact same ip addresses but in two formats - in IPv4 format and in IPv4+ format. (if the community is lazy and don't want to upgrade the needed routers by IT professionals, and it is not the whole routers in the world, far far far less) -------- Respectfully, Elad ________________________________ From: Tobias Lehner Sent: Sunday, April 26, 2020 10:43 AM To: 'noc'; Elad Cohen; Ed Campbell Cc: members-discuss(a)ripe.net Subject: AW: [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, Furthermore, every router in the connection can/may add/remove the df bit, which breaks your idea. We should really go in the direction of IPv6. Mit freundlichen Grüßen / Best Regards Tobias Lehner Hartl-EDV GmbH & Co. KG Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von noc Gesendet: Sonntag, 26. April 2020 09:23 An: Elad Cohen <elad(a)netstyle.io>; Ed Campbell <campbell(a)inca.ie> Cc: members-discuss(a)ripe.net Betreff: 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 Hello Elad. I've been reading all the messages you sent. I see that you try hard to push your vision. But here's some reasons to what you suggest doesn't work and will never work: - the extra 2 bits you suggest to use (fragmentation bits) are there for a reason. And that reason is not to have more ips, but to fragment packets when needed. On a perfect worldwide network, they aren't needed. But we are on a imperfect worldwide network and many systems need packet fragmentation to work (satellite systems by example). - it's not possible to upgrade millions of routers. Many reached end-of-life many years ago. If the ISP switch the router, he will deploy right away ipv6. - IPv4+ will not give more time to deploy IPv6. It will only delay it. Everyone is lazy for different reasons. So, if IPv4 works, why deploy IPv6? No. It's been since 2012 that we (RIPE) announced the exhaustion of IPv4. And very few has been done to push IPv6. - enterprises like Microsoft will earn a lot more of IPv4+ if they implement it... Why will they bother? They already have 2 /8 legacy not being used/routed. And this is the same for a lot other companies. Many already invested a lot on IPv6, will they do new investments for IPv4+ knowing that is a dead end? No. - IPv4+ is easy to implement. Wrong. It's hard. It will need to be implemented on each level till the top (IANA), and I doubt the very top will do anything to change this. Looking at the statistics everywhere, I see that IPv6 implementation his growing a lot since September. And this, yes. It's a good news. Your idea should've be pushed 15 years ago (before the running out announcement), not now. Now there is nothing it can be done. Cheers Enviado a partir do meu smartphone Samsung Galaxy. -------- Mensagem original -------- De : Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Data: 26/04/20 00:54 (GMT+01:00) Para: Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Cc: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> Assunto: 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 Indeed demand is rising, but I don't believe that the world will use more than 4 billion new IPv4 addresses in 5 years, it will not happen, the RIRs already have very strict policies that will continue to be used, IPv4+ will not end fast - it will provide many many years that in them migration to IPv6 will be able to be completed quietly. (without the world to be in any problem) The only reason that IPv4 exhausted recently is because companies from all over the world were told that IPv4 is about to end (and this was the brainwash) so they opened LIR accounts like crazy just to get the last /22's - this is the only reason. And people that are doing money out of it. But if each RIR will have 800+ new million ip addresses and the RIRs will use strict policies to provide them and there will not be a shortage and the public will know that there isn't a shortage of IPv4 - then you will see that companies will not open LIR accounts like crazy just to get the last IPv4 addresses. Respectfully, Elad ________________________________ From: Ed Campbell <campbell(a)inca.ie<mailto:campbell@inca.ie>> Sent: Sunday, April 26, 2020 1:39 AM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 IPv6 isn’t slow because of the lack of trying, it is slow because of Microsoft et al’s unwillingness to adopt it. If it became the default IP stack to use on all operating systems rather than a “nice to have” “feature” attitudes would change. 3-4 times you have said now that it would take another 25 years to exhaust this “new” IPv4 space, that just doesn’t track with the current demand for addressing. You’d only be delaying and thwarting existing efforts to deploy IPv6. Sent from my iPhone On 25 Apr 2020, at 22:34, Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: Torbjorn, IPv6 cannot communicate directly with IPv4, while IPv4+ can communicate directly with IPv4. Technicians don't have to know anything about IPv4+ (and not to know how it internally works) besides to know how to upgrade the firmware of a router and how to update a patch to an operating system, in contrary to IPv6 that Technicians need to know it completely in order to design an IPv6 network and for it also to work with IPv4. I didn't write that I'm against learning or implementing IPv6, I wrote my opinion on why deployment of IPv6 is slow and will be slow. It took us approximately 25 years to use almost 4,294,967,296 IPv4 addresses, the same number of ip addresses IPv4+ will bring us at least more 25 years. CGNAT is not good for datacenters, and datacenter needs and will need more IPv4 addresses. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>> Sent: Sunday, April 26, 2020 12:15 AM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; Atif Naveed <a.naveed(a)go.com.sa<mailto:a.naveed@go.com.sa>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 Elad, > > Because IPv6 is a completely different network than IPv4, IPv4+ is the same network of IPv4. No, IPv4+ is also a complete new network that no OS supports and no technician can understand now. It’s more complicated and more time consuming than deploying IPv6. > (IPv6 require complete new network design, much more to learn for companies/organizations and much more expenses for companies/organizations. IPv4+ will give more time and space that is needed in the world today) Yes, it’s "new“ but you had +20 years to learn IPv6 and you have time now to learn it now while CGNAT is growing. IPv4+ just extends the time a little bit more. /Tobbe > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 11:04 PM > To: Atif Naveed <a.naveed(a)go.com.sa<mailto:a.naveed@go.com.sa>>; Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > Dear Atif, > > Respectfully, we have IPv6 sessions with Tier1 and peering networks and have had for some years now. > I’m not sure there is a Tier1 who doesn’t offer IPv6. > Most UK ISP’s now provide IPv6 by default to people’s homes. > > I agree the uptake has been incredibly slow, which is why I don’t think IPv4+ will be any better. We all updated kit for IPv6 providing trillions more IP addresses to each LIR but the uptake has been slow. > Why would the uptake be faster for IPv4+? > > > Best, > > Stuart Willet. > > From: Atif Naveed [mailto:a.naveed@go.com.sa] > Sent: 25 April 2020 20:30 > To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > Dear Stuart, > > Hold your horses, till day where IPv6 stands not near to 1 to 10% of utilization across internet. So in so many years IPv6 still not able to catch the eyes of Tier1 or any ISP or simple users. > > So what Elad is offering is still very good option to move ahead at this stage before ipv6 takes off its flight in next decade or so. > > And I can understand deployment will be not that’s straight forward but once it starts flying it will make its own path . > > Regards > > > Atif Naveed > Sr. Specialist > IGW/ISP Core Network Operations > D:+966-11511-1263 > E:a.naveed@go.com.sa > www.go.com.sa<http://www.go.com.sa> > > From: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> On Behalf Of Stuart Willet (primary) > Sent: Saturday, April 25, 2020 10:21 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > Respectfully, I do not think you have fully considered the logistics involved in updating so much hardware and software. > > What about all the L3 switches and routers not owned by ISP’s? > What about bigger ISP’s ad Tier 1’s? Do you honestly believe NTT or Telia will update millions of network devices worldwide for a /21? > > Honestly, the update alone is unfeasible, especially when we already have fully working IPv6. > > On that note, everyone has been given an incredible amount of IPv6 space, but this has not picked up anywhere near fast enough. > I appreciate you believe IPv4+ will be more compatible, but it simply will not work unless the entire world updates all IP based switching and routing platforms as well as operating systems and bespoke hardware. > > Best, > Stuart Willet. > > From: Elad Cohen [mailto:elad@netstyle.io] > Sent: 25 April 2020 20:13 > To: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > • Any routing device with more than two physical routes > • Any BGP router > • Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<members-discuss(a)ripe.net<mailto:members-discuss@ripe.net%3cmembers-discuss@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 > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>> > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > <image001.jpg> > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > <image002.jpg> <image002.jpg> > <image002.jpg> <image003.jpg> > > > De: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen > Enviada: sábado, 25 de abril de 2020 20:21 > Para: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> > Assunto: [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 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(a)ripe.net<mailto:members-discuss@ripe.net> > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40int… _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/campbell%40inca.ie

2 1

Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
by Elad Cohen 26 Apr '20

26 Apr '20

I never created an RFC and not familiar with the process, but I wanted to discuss IPv4+ with Ripe members as I'm a Ripe LIR. Respectfully, Elad ________________________________ From: info(a)cowmedia.de Sent: Saturday, April 25, 2020 9:53 PM To: members-discuss(a)ripe.net Cc: 'noc xervers'; Elad Cohen Subject: AW: [SPAM] 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, anyhow this is not the right list to discuss this. You need to create an RfC – but as IPv6 already exist there is no real chance of implementing this I would say. Michael Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von noc xervers Gesendet: Samstag, 25. April 2020 20:49 An: 'Elad Cohen' <elad(a)netstyle.io>; members-discuss(a)ripe.net Betreff: [SPAM] 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 That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. It's a better and cleaner solution to move to IPv6. Cheers. [Das Bild wurde vom Absender entfernt. XERVERS] NOC xervers | +351 300 404 316 P Please consider the environment before printing this email [Das Bild wurde vom Absender entfernt. Visit our website]<https://www.xervers.pt/> [Das Bild wurde vom Absender entfernt. Facebook] <https://www.facebook.com/xervers/> [Das Bild wurde vom Absender entfernt. Twitter]<https://twitter.com/xervers> [Das Bild wurde vom Absender entfernt. TrustPilot] <https://www.trustpilot.com/review/www.xervers.pt> De: members-discuss <members-discuss-bounces(a)ripe.net> Em Nome De Elad Cohen Enviada: sábado, 25 de abril de 2020 20:21 Para: members-discuss(a)ripe.net Assunto: [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 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

2 4

Another solution to the IPv4 shortage
by Jens Link 25 Apr '20

25 Apr '20

Hi, as I'm struggling to find the political correct words for people subscribing a ticket system to a mailing list with "-discuss" in the name i came up with another solution to the IPv4 shortage: Every person / organization adding this mailing list to a ticket system and thereby creation unnecessary (auto reply) messages or other messages of that kind: - are immediately unsubscribed form any mailing list - forfeit all their resources (IPv4, IPv6, ASN) - can never become a RIPE member again As I just got a mail from a large advertising / could / search engine company this might free up significant resources. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- | ----------------------------------------------------------------------------

2 2

Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
by Elad Cohen 25 Apr '20

25 Apr '20

Thilo, The problem is that there is a demand in the world for IPv4 and IPv4 will soon runout in all the RIRs. IPv6, to my opinion, is not deployed because it costs money, manpower, IT department, learning, etc - companies are basing their actions on profitable / not profitable - you will not see companies rushing to IPv6 when they are not have to, when IPv4 works perfectly fine for them, they will not put expenses for something that can only cause them more expenses if there will be any problem with the IPv6 deployment (to my opinion this is what the reasonable company will react) and specially in these times of COVID, reasonable companies will minimize expenses and will try less to change things which are working. NAT is being used for many years, and still the demand for IPv4 is huge (all RIRs soon will not have any available single IPv4), datacenters are not using NAT. The main problem with IPv6 is by-design, creating a completely different ip protocol which is not backward-compatible is very bad, the design of it is very bad and it what brought us to this state (and also the 4 byte limitation in IPv4), but I'm not against the deployment of it, the deployment of IPv6 will be completed and I believe that more IPv4 addresses will help the deployment of IPv6, specially in these times we need more connectivity and IPv4+ brings more connectivity in the very immediate near future (IPv6 will do it in the longer term). I do believe also as you wrote that IPv4 addresses will become more and more expensive (if IPv4+ will not be implemented), regulators intervention in each country for IPv4 rate seems to me a more difficult task than the deployment of IPv6 and IPv4+ together :) Respectfully, Elad ________________________________ From: Thilo Mohri <inbox(a)tmohri.de> Sent: Saturday, April 25, 2020 11:36 PM To: Elad Cohen <elad(a)netstyle.io> Cc: members-discuss(a)ripe.net <members-discuss(a)ripe.net> Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, I like your solution - however, where is the problem you are trying to solve? The problem we have with IPv6 is absolutely non-technical, most devices natively support IPv6, for legacy devices we have 4in6 and to deal with IPv4 exhaustion we have NAT at least on the b2c side. The solution to IPv4 exhaustion is there - it is called IPv6, it is just not deployed! The problem is with organizations who don’t have IPv6 on their priority list - and this will change over time when IPv4 will get more expensive and not possible to run anymore. I agree it’s a slow adoption, but the market will settle this over time. The only risk I see here is that the market will be dominated by big players in the future as small players cannot get any footprint into the IPv4 market anymore and not able to reach all their customers with IPv6 -> this must be solved by the different telco regulators in the respective countries. Just my two cents, Thilo - sent from my mobile. On 25. Apr 2020, at 22:31, Elad Cohen <elad(a)netstyle.io> wrote: Michael, Please see my following answers: 1. No additional header bit is needed, the ip packet is exactly as it is now, the 'reserved bit flag' will just be '1' instead of '0' , the reserved bit is available in the ip header and hence the filter will see the whole ip packet. (any router that do any check regarding the source address or the destination - will need to be upgraded). 2. This is not a new protocol, IPv6 is a new protocol, it is an adjustment to a current protocol and not any device which implemented that protocol (IPv4) will need to be upgraded, providing IPv4 address (of IPv4+) to all the parties involved (when IPv4 addresses are so much needed in these days) and using the automatic updating mechanism of operating systems - can and will make this whole process much much faster. 3. It is an adjustment to a current protocol and not a completely new protocol, clean code updates will resolve it. There is no need to know what is the main protocol (IPv4+ or IPv4) because the exact same IPv4 packet is being used, upgraded routers will just know how to route it well (if the four bytes of source address are of IPv4 or IPv4+ and if the four bytes of destination address are of IPv4 or IPv4+). 4. Please see what I wrote, I didn't write that only some of the needed routers will be upgraded, I wrote that all the end-users operating systems will be updated (through the automatic updating mechanism of the operating systems). 5. We can argue on it, I believe that if companies and organizations will have a high pool of IPv4 then they will be able to support both IPv6 and IPv4 and then more and more companies and organizations will support both IPv4 and IPv6 until the whole internet will be able to move to only IPv6. IPv6 is being talked for 20 years and currently the world is in a very big problem because of the lack of IPv4. 6. From the very beginning with the round table and IPv4+ addresses incentives to everyone - IPv4+ will be deployed very very fast, I wrote about very margins cases, from the very beginning through the round table IPv4+ will be deployed (Automatic operating system updates will done only after the ISP's and ASN's will complete to update their routers and will receive their amount of free new IPv4 addresses). And just in case an ISP will assign to its user an IPv4+ addresses to use the internet then that IPv4+ addresses need to access the whole internet (there are many online services that are not yet supporting IPv6+). I'm not against IPv6 - I surely believe it is the future, but more IPv4 addresses are needed for and until IPv6 to be fully adapted. 7. Please write about any unanswered point. I don't believe that I'm late because 20 years ago there wasn't any need to use the 'reserved bit flag' in the ip header, it was intended for future use, and what would be a better use to the 'reserved bit flag' than to use it for the current IPv4 Exhaustion problem. Respectfully, Elad ________________________________ From: members-discuss <members-discuss-bounces(a)ripe.net> on behalf of info(a)cowmedia.de <info(a)cowmedia.de> Sent: Saturday, April 25, 2020 11:00 PM To: members-discuss(a)ripe.net <members-discuss(a)ripe.net> Subject: Re: [members-discuss] [SPAM] Re: Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Elad, i really appreciate your idea, but there are unfortunately some issues to this. 1. It requires an additonal header bit that is not part of the address itself, how would a filter know about this when there is only the ip address given (the bit it not available to them). 2. The time of developing and rollout a new type of protocol (what this is) takes years (maybe 10-15 years) even this is theoretically just a small change) 3. Configuring dual protocol is already with IPv4+6 sometimes a hard issue. There are issues with what protocol is the main one and how applications are using them 4. It is not enough to update only networking equipment because the application layer decides about the target (for example the browser via DNS), even today so many software is not compatible with IPv6, how would you expect them to include IPv4+? 5. IPv4+ would slow down IPv6 rollout 6. Your thinking about users will complain when sites are not reachable is not correct. ISPs and service owner make sure right now that the service is at least reachable by IPv4 and they are in the process of trying to add IPv6 to them. There is no way of having users not access any service just because a provider or any MITM is not yet ready. Hence IPv4+ will NEVER be solely rollout to any service. 7. Plus many more points that were raised. You are really 20 years too late. I am so sorry. Michael Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von Elad Cohen Gesendet: Samstag, 25. April 2020 21:42 An: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se> Cc: members-discuss(a)ripe.net Betreff: [SPAM] 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 Torbjorn, Equipment which is old enough not to support IPv6+ will probably won't be able to be upgraded to IPv4+ , but it is still using an IPv4 address, and it is the main point, it is using IPv4 address and there is a global need for IPv4 addresses. Regarding homerouters and iot that you wrote - they will not need to be upgraded to IPv4+ , IPv4+ will be transparent to them. Hosts will be upgraded using the automatic update mechanism of their operating system. Respectfully, Elad ________________________________ From: Torbjörn Eklöv <torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se>> Sent: Saturday, April 25, 2020 10:36 PM To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> Cc: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 Stuart, More IPv4 will not make the transition faster. If you and other have equipment that can’t be upgraded and support IPv6 its probably to old for IPv4 upgrade also and with all security issues they can’t be patched for. The OS upgrade for some mix with IPv4+ is a bigger issue than IPv6 deployment. There are billions of hosts/homerouters/IoT that never will get an upgrade to support that. /T > On 25 Apr 2020, at 21:13, Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>> wrote: > > My main issue is that it is not a replacement for IPv6, it is just an additional pool of ip addresses for IPv4, I do understand that IPv4 ip addresses don't come near to the amount of ip addresses in IPv6, but we will always have devices that are too old to be upgraded to IPv6 and the solution I wrote is doubling the amount of IPv4 (comparing to IPv6 it is meaning less but comparing to the number of ip addresses in IPv4 it is doubling the amount of IPv4), and I do believe that more IPv4 addresses will make the transition to IPv6 faster (everyone will be able to support both IPv6 and IPv4 and then transition to only-IPv6 will be smoother). > > Regarding the number of devices: > • Any routing device with more than two physical routes > • Any BGP router > • Any operating system > The operating systems updates can be fast through their automatic update systems, regarding updating the routing equipment - if each ASN will be know the he will receive a free /21 from the IPv4+ you will see that it will be fast as well (and after it each of the 5 RIRs will have more than 800,000,000 new IPv4 addresses). > > When the ip protocol was created with the saved reserved bit, the reserved bit was saved for just such case, for the case that we are in, what better use would be to the reserved bit in the IPv4 packet header if not to double the amount of IPv4 addresses (at the last stage of the transition to IPv6). > > Respectfully, > Elad > From: Stuart Willet (primary) <stu(a)safehosts.co.uk<mailto:stu@safehosts.co.uk>> > Sent: Saturday, April 25, 2020 10:01 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<members-discuss(a)ripe.net<mailto:members-discuss@ripe.net%3cmembers-discuss@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 > > Sorry, there are far too many Layer3 switches and routers which already support IPv6 and would need to be updated to support IPv4+. > There are also many firewalls, both hardware and software which would need updating but can already use IPv6. > > If you had proposed this before the introduction of IPv6 I am sure it would have worked, but it is inferior to IPv6 in two respects. > 1: it would require updating millions of routers, L3 switches, firewalls, operating systems and 3rd party devices. > 2: it would not offer anywhere close to the amount of IPv6 addresses which already work. > > Best, > Stuart Willet. > > From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Elad Cohen > Sent: 25 April 2020 19:56 > To: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>>; members-discuss(a)ripe.net<mailto:members-discuss@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 > > It is not a complete new protocol, the reserved bit (in IPv4 packet header) was intended to be reserved for future use, the future usage of it was planned. > > I'm not against IPv6, but IPv6 is not backward compatible with IPv4 by design and the world currently need more IPv4 addresses, the number of IPv4 addresses can be easily doubled even in one week, through operating system update of the biggest operating system vendors and simple firmware upgrades by the routing equipment manufacturers. > > switches are working on layer2, they are not related to ip. > > Respectfully, > Elad > > From: noc xervers <noc(a)xervers.pt<mailto:noc@xervers.pt>> > Sent: Saturday, April 25, 2020 9:48 PM > To: Elad Cohen <elad(a)netstyle.io<mailto:elad@netstyle.io>>; members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> <members-discuss(a)ripe.net<mailto:members-discuss@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 > > That won't be IPv4 but a complete new protocol, and routers/switches/whatever won't support them. > It's a better and cleaner solution to move to IPv6. > > Cheers. > > <image001.jpg> > NOC xervers | +351 300 404 316 > P Please consider the environment before printing this email > <image002.jpg> <image002.jpg> > <image002.jpg> <image003.jpg> > > > De: members-discuss <members-discuss-bounces(a)ripe.net<mailto:members-discuss-bounces@ripe.net>> Em Nome De Elad Cohen > Enviada: sábado, 25 de abril de 2020 20:21 > Para: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> > Assunto: [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 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(a)ripe.net<mailto:members-discuss@ripe.net> > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/torbjorn.eklov%40int… _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/inbox%40tmo.sh

1 0