[ipv6-wg] Disband IPv6 WG

Hi Jens,

Wow, first I had to look at today's date, I thought this was a April Fools
joke mail.

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 <lists at 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!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ipv6-wg/attachments/20191003/859618a2/attachment.html>