Dear colleagues Although Alexey seems to be against campaigning, I would still like to express my support for his views. We are for positive and constructive action and against any form of punitive action. Deprecating IPv4 would severely harm the work of our cooperative. Friendly regards Philip Donner Kuhmon kyläverkko-osuuskunta Kokkovaarantie 1063 88760 Iivantiira Finland Telephone: +358-3-4489022 (office), +358-40-0404555 (mobile) E-mail: <mailto:pdonner@znak.fi> pdonner@znak.fi, <mailto:toimisto@nettinoste.fi> toimisto@nettinoste.fi From: Alexey Berezhnev <alex@mac3.ru> Sent: Wednesday, May 28, 2025 6:26 PM To: Rudolf E. Steiner <r.steiner@nemox.net> Cc: members-discuss@ripe.net Subject: [members-discuss] Re: Reminder that Charging Scheme Task Force comments are open until the end of the month Hi Brett, all, While I appreciate the intention to promote IPv6, I have to strongly object to the proposal of removing IPv4 access to RIPE services. Deprecating IPv4 — even symbolically — is not a “signal”, it’s a disruption. Key points: 1. IPv4 is not deprecated — it’s the backbone of global traffic. Most production systems, even in dual-stack environments, rely on IPv4. The market for IPv4 addresses — leasing, transfers, brokers — exists precisely because IPv4 is still essential. Deprecating access to critical RIPE services would harm legitimate businesses and LIR operations. 2. RIPE is a registry, not a campaign group. Its duty is to serve all members reliably — not to make symbolic political gestures. Disabling access over IPv4 to APIs or the LIR Portal would disrupt automation for many and create unnecessary operational risk. 3. “All members have IPv6” is incorrect. Yes, many have allocations — but allocations don’t mean real-world deployment. You can’t expect thousands of legacy systems, embedded appliances, and enterprise stacks to suddenly switch without cost, risk, or a clear need. 4. Tech media coverage is irrelevant to network stability. Making operational decisions to get media headlines is a dangerous path. RIPE’s reputation is built on trust, neutrality, and technical soundness — not PR stunts. Conclusion: If you believe in IPv6 adoption, focus on incentives, not punishments. Provide tools, training, and smoother integration — but don’t force outages in the name of symbolism. Sent from my iPhone On 28 May 2025, at 18:07, Rudolf E. Steiner via members-discuss <members-discuss@ripe.net <mailto:members-discuss@ripe.net> > wrote: Brett Sheffield wrote: If RIPE is serious about encouraging IPv6 adoption (and I think we are), we need to deprecate and remove support for IPv4. The idea of deprecating and removing IPv4 support in order to "encourage" IPv6 adoption is both unrealistic and counterproductive. While IPv6 is a technically superior protocol and its widespread adoption is desirable, the fact remains that IPv4 continues to underpin a vast portion of the global Internet infrastructure. Forcing its removal would not accelerate IPv6 adoption - it would introduce massive disruption and incompatibility. Dual-stack deployments and transition technologies (such as NAT64, DNS64, and 464XLAT) are well-established and allow for a practical coexistence of both protocols. The Internet is a heterogeneous space, and many networks, especially in developing regions or small-scale operations, still rely heavily on IPv4. Moreover, critical systems, embedded devices, legacy applications, and even large-scale services continue to depend on IPv4-only implementations. Mandating IPv6-only operation would sever access to these resources and services. Adoption of IPv6 should be driven by technical and economic incentives, not by the threat of forced obsolescence. Removing support for IPv4 would not solve the adoption problem - it would merely punish those who, for valid reasons, cannot yet migrate. As a coordinating body, RIPE should focus on fostering compatibility, providing incentives, and supporting gradual transition rather than advocating for the removal of functional infrastructure. Deprecating IPv4 is not a path to progress - it is a recipe for fragmentation and exclusion. -- nemox.net Rudolf E. Steiner r.steiner@nemox.net <mailto:r.steiner@nemox.net> http://nemox.net/pdat/res/ <r_steiner.vcf> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/members-discuss.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/