V6 still not supported

Thu Mar 17 11:40:32 UTC 2022

“It seems all the market needed was IPv4 with bigger address space.
Instead of delivering it, some contraption has been created trying to solve
non-existant (or already fixed) problems.”

your argument against IPv6 is that they should have created a new version
of IPv4, but bigger?

So… IPv6?

On Thu, Mar 17, 2022 at 06:32 <borg at uu3.net> wrote:

> It seems team developing IPv6 had ONE way of doing things,
> with is actually recipe for disaster. Why? Because they were building an IP
> protocol. Something that will be using globally by ALL networks around.
> Not some local IOT (useless) shit used here and there.
> Thats why such IP protocol should be follow KISS concept and flexibility.
> Some people have different vision how to run network. And because
> Inter-net is an AS to AS network they should have right to do so.
>
> In my opinion all that crypto stuff should be put layer upper because
> crypto is hard, very hard and can get obsolete quickly.
>
> Its same about other weird things embedded into IPv6 that probably
> should go layer up. And now people wonder why IPv6 adoption is crap and
> there is high resistance. IPv4 made mistakes too, but hell, it was the
> first.
>
> It seems all the market needed was IPv4 with bigger address space.
> Instead of delivering it, some contraption has been created trying to solve
> non-existant (or already fixed) problems.
>
> Just my 2 cents...
>
>
> ---------- Original message ----------
>
> From: William Allen Simpson <william.allen.simpson at gmail.com>
> To: NANOG <nanog at nanog.org>
> Subject: Re: V6 still not supported
> Date: Wed, 16 Mar 2022 22:24:14 -0400
>
> I'd wanted to clearly distinguish this from the old methods:
>
>    This is intended to replace ARP, ICMP Router Advertisement, ICMP
>    Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6]
>    environment. There are also elements of the OSI ES-IS and IS-IS Hello.
>
> We were forward looking to deployments of thousands of systems per link,
> rather
> than the 30 maximum under then current ethernet standards.  We needed fewer
> announcements, less chatty traffic, and more specific traffic designation.
>
> We also prioritized network security.  Moreover requiring addresses be
> ephemeral,
> such that applications would not be able to tie
> authentication/authorization to
> an
> IPv6 address and would be motivated to use cryptographic security.
>
> Unfortunately, later committees decided that rather than a single simpler
> secured
> address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6.
> Three ways to do the same thing are always a recipe for disaster.
>
> Reminder: I was an operator and one of the original NANOG members.
>
> We spent a lot of time considering human factors.  I'd pioneered the
> "Operational Considerations" section of the original draft RFCs.
>
> IPv6 is a case study of what happens with committee-itis.
>
> The small design team worked well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220317/aaf5e30e/attachment.html>