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/members-discuss@ripe.net/
[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] [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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Rob Evans
rhe at nosc.ja.net
Sun Apr 26 13:28:59 CEST 2020
Hi Elad, It’s an interesting idea, but I fear we have gone through similar proposals to sneak an extra bit out of the IPv4 header and double the number of addresses in the past, and they have all come unstuck somewhere. One of the biggest issues I see is that on most routers, at both the low and the high end, much of the forwarding is performed in silicon rather than in software. The design cycle for the silicon is long and expensive, and the replacement cycle even longer — think years rather than weeks or months. Almost all of that silicon can already handle IPv6. How are routing protocols going to transport IPv4+ routes? How will IPv4+ addresses be stored in the DNS? I assume this will require a new record type that will have to be deployed by DNS servers worldwide. I also think you underestimate the length of time to push out updates to software worldwide. Many people use operating systems and applications that are no longer supported, perhaps because the hardware they are using them on is no longer supported. It’s not just the IP stack that needs to change, it is anywhere that displays or accepts an IP address, so that’s everything from web forms to web browsers to system preferences boxes. The path MTU discovery relies on a timeout, so it will add to connection setup times, which will make applications slow down unacceptably. It also only copes with the MTU decreasing during the lifetime of a session (also relying on another timeout), not increasing. The proposal uses UDP to determine an MTU that could be used for TCP, yet it’s possible that the two protocols could take different paths if there’s some application-specific filtering happening. We don’t really need “another IPv4’s worth of IP addresses,” especially if that just perpetuates deployment of IPv4 rather than IPv6. According to internetworldstats.com, they believe that just under 60% of the world’s population has Internet access in one form or other. We need a system that can cope with not just the additional 40%, but increasingly the “Internet of Things,” and we have that — IPv6. The effort would be better expended on deploying IPv6 than repeating the same work for a short-term band-aid. As others have said, the IETF is the place to standardise this, if you wish to attempt to do so. It would certainly be worth reading up on how other recent alternative schemes have faired (e.g. Khaled Omar's "IPv10" proposal to enable IPv4/IPv10 inter-operation). Cheers, Rob
- 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] [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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]