V6 still not supported

Thu Mar 17 14:30:18 UTC 2022

I agree that parts of IPv6 design suffer from a bit of overcomplication.
Maybe it didn't seem that way when they did it, but experience has taught
us otherwise. So we should take those learnings and adjust.

On Thu, Mar 17, 2022 at 9:27 AM <borg at uu3.net> wrote:

> Yes, IPv6.. but for example 64bit address space but with a much
> closer ties to IPv4 imo. So network people would be much more
> confortable with it.
>
> I already said how my ideal IPv6 should look like. Many people
> disagree with that ok. Its very hard to please everyone indeed, hence
> KISS concept should be followed.
>
> Also, the whole dual stack thing should be required only on
> content providers, so client should be moved to IPv6, freeing
> more space from IPv4 with could be moved to content/hosting.
> Once there is enough critical mass of clients on IPv6, IPv4 could be
> dropped gradually. This avoids chicken and egg problem.
>
> Lets stop that E2E myth, we do NOT have e2e connectivity on client side
> from loong time (users NATs, CGNATs). And you know what? Its not that
> needed these days due to how internet is centralized today.
> Its good moment for change imo, but we blowed it.
>
>
> ---------- Original message ----------
>
> From: Tom Beecher <beecher at beecher.cc>
> To: borg at uu3.net
> Cc: nanog at nanog.org
> Subject: Re: V6 still not supported
> Date: Thu, 17 Mar 2022 07:40:32 -0400
>
> ˙˙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/98c1a075/attachment.html>