> On 3 Oct 2019, at 12:58, Uros Gaber <[email protected]> wrote: > > Hi Jens, > > Wow, first I had to look at today's date, I thought this was a April Fools > joke mail.
Did you also look at the From?, because that’s not the one I expected if I instinctively expanded the name to that of someone I know, like the wg co-chair or so. Cheers Joao > > But to go forward seriously, a couple of questions to maybe clarify your > thinking - from bullet points: > 1. WHY should it have NAT > 2. What do you understand under class, IPv4 "Classes" are just defined subnet > groups (simply put) > 3. AFAIK DHCPv6 is defined in RFC (3319,3646,4704,5007,6221,6355,6939,8415) > 4. Partly agree on this one > 5. Partly agree on this one, but probably with the right set of firewall > rules you could achieve the same effect you are going after > 6. Dots and colon, what's the difference? > 7. Use DNS to resolve - no [] needed then. > > And for the "footprints": > [4] you want classes in "IPvX" but negate the same with this point > [5] what does the script have to do with network layer? > > Just my 2c. > > Uros > > On Thu, Oct 3, 2019 at 12:35 PM Jens Link <[email protected] > <mailto:[email protected]>> 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 <http://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 > <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 > > <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! > >
