I think he's on to something. Perhaps the IETF can start working on IPv4bis. Something with, say, 128 bit addresses, fixed-size subnets and heavier use of multicast instead of broadcast.
We'll leave NAT4bis4bis as an implementation detail for router vendors. Alex > On Oct 3, 2019, at 12:34 , Jens Link <li...@quux.de> wrote: > > Hi, > > after now almost 12 years using, working and teaching[1] > IPv6 I've come to the conclusion that IPv6 is a mistake and will > not work. > > Therefore the RIPE IPv6 WG should be disbanded and replaced > with a new WG that MUST investigate all possible solutions to > artificially prolong the live of IPv4 till the day a new successor > for IPv4 is created and implemented! > > Some great ideas[2] are already proposed, some of them already > implemented: > > - Use of NAT > - Use of the first Class-A network 0.0.0.0[3] > - Use of parts of localhost Class-A network 127.0.0.0 > - Use of (parts) of Class-D address space (multicast) > - Use of Class-E address space (future use) > - Using part of the UDP / TCP port range as extension for the > address. > > Some of the reserved address spaces could also be used. E.g. nobody > is using 192.0.2.0/24 for documentation anyway. > > It should also be investigated to take back legacy IPv4 resources, > although the "owners" of these resources might already selling > them on the open market. > > It MUST also be considered not filtering on Class-C[4] bounderies > but going for something smaller like /26 or /27 in the global routing > table. Also new Class Designations for these prefixes MUST be created. > > The new successor to IPv4 should not make the same mistakes as IPv6. > > - IT MUST have NAT > - It MUST have Classes > - IT MUST have DHCP > - It MUST have ARP > - It should be possible to drop ICMP the same impact as in IPv4. Many > experts I talked to over the years told me that blocking ICMP has > no negative impacts. > - It MUST only have numbers and dots "." > - There should be absolutly no reasons to use "[ ]" in URLs > > Probably the best way to proceed is to just add one or two octets to the > address. > > One of the reasons for the above is that there are so is so many good > documentation already written about IPv4! And people already know about > IPv4! Why waste this knowledge and experience? There is also plenty of > good software out there that can't work with IPv6[5] Change is bad! > People don't want to learn! > > IPv4! MUST! NOT! DIE! > > Jens > > [1] at least trying to teach, as one can see from the great number of > people actually using IPv6 with little success > > [2] https://netdevconf.info/0x13/session.html?talk-ipv4-unicast-expansions > > [3] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96125bf9985a > > [4] a Class-C network is the equivalent of an /24. I was told by experts > that the definition of some bit set in the first octet of an IPv4 > address is complete and utter nonsense > > [5] like a 20 year old shell script that is so important for $university > that it would be hard for them to implement IPv6! > >