This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
- Previous message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
- Next message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jürgen Jaritsch ([email protected])
juergen.jaritsch at jmpts.ch
Sun Apr 26 13:07:32 CEST 2020
Dear Elad, do you know what a ASIC is? Do you know how non-software defined registers work? Let's make it very easy for everyone: Do you ever thought about thinks like firewalls/loadbalancers and their GUIs? About software, that verifies IP-addresses by regex? Your idea is not compatible with existing software. Please share some detailed examples how to bypass such issues. EVEN if the hardware of the (e.g.) firewalls is able to handle the "new" IP addresses of IPv4+: the GUI have to be fixed/updated - on EVERY firewall around the world. Otherwise you'll never have any end-to-end IPv4+ connection. Same counts for software like Webservers (e.g. Apache virtual hosts can refer to IPs in the config), IPTables, databases systems, etc etc. All this software depends on existing network stack but also have configuration verification/testing processes which will not work with (unexpected) IPv4+ addresses in the configuration. What about DHCP, DNS, BGP, Peering fabrics (AMSIX,DECIC, etc) etc? This have to be adapted too. Regarding your "switches are L2 only" statement: did you ever heard about MPLS- and/or L3-switches? They could be EOL/EOS but have full support for IPv4/IPv6 so there is no real statement against using them in existing (closed/company) networks (beside the case of defective hardware). Users of this device will not receive updates from the vendors. What about big vendors? You said it's "easy" and "cheap" to implement: what if hardware line cards like Juniper MPC does not support this? This cards are used in many backbone routers. Should the carriers simple replace them? To be honest: from a theoretical point of view your idea sounds great, but you have to consider way more details / functions / devices / situations /implementations. Your idea is nothing simple to "activate" like an feature. You can't tell a carrier "if your Juniper MPC does not support IPv4+, you have to use NAT" - seriously? With hundreds if Gbps? Best regards Jürgen Von: members-discuss <members-discuss-bounces at ripe.net> Im Auftrag von Elad Cohen Gesendet: Sonntag, 26. April 2020 12:38 An: Thomas Gallo @ Lenfiber S.p.A. <thomas.gallo at lenfiber.it>; members-discuss at 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 ASICs or any device with a similar problem, can be connected to the internet through a NAT router, the NAT router will help the ASIC or the similar device with IPv4+ (The ASIC or the similar device will only be able to initiate connections to IPv4, but any ip addresses in the internet - IPv4 or IPv4+ will be able to initiate a connection to the ASIC or the similar device and then to create a session with it, the NAT router will monitor the session and will set the IPv4+ bits accordingly) In advanced configuration in the NAT router there can be an option that all ip packets that will originate from the specific ASIC will be only to IPv4+ addresses (and not to IPv4) so the NAT router will always set the IPv4+ related bits in any ip packet originated from the ASIC or similar device. Respectfully, Elad ________________________________________ From: members-discuss <mailto:members-discuss-bounces at ripe.net> on behalf of Thomas Gallo @ Lenfiber S.p.A. <mailto:thomas.gallo at lenfiber.it> Sent: Sunday, April 26, 2020 1:03 PM To: mailto:members-discuss at ripe.net <mailto:members-discuss at ripe.net> Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, many years ago it could have been a good idea.. but even if all of this could be implemented on the software side today... but what about ASICs and so forth? (thinking to circuitry that do lookup based on 32bits for example) Best regards, Thomas Il 26/04/2020 11:52, Elad Cohen ha scritto: 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; mailto:members-discuss at ripe.net Subject: Re: [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world Hi, > 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 _______________________________________________ members-discuss mailing list mailto:members-discuss at ripe.net https://mailman.ripe.net/ Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/thomas.gallo%40lenfiber.it -- Thomas Gallo email: mailto:thomas.gallo at lenfiber.it Amministratore unico Lenfiber S.p.A. Centro Direzionale Interporto Padova - Torre B Galleria Spagna, 36 - 35127 Padova (PD) ph: +39 049 85 94 766 fax: +39 049 82 51 032 P.Iva/VAT: IT04669150288 Cap.Soc. 200.000,00 Euro i.v. http://www.lenfiber.it
- Previous message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
- Next message (by thread): [members-discuss] Technical solution to resolve the IPv4 Exhaustion problem and to add more 4, 294, 967, 296 IPv4 addresses that are needed in the world
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]