<div dir="ltr">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. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 17, 2022 at 9:27 AM <<a href="mailto:borg@uu3.net">borg@uu3.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, IPv6.. but for example 64bit address space but with a much<br>
closer ties to IPv4 imo. So network people would be much more<br>
confortable with it.<br>
<br>
I already said how my ideal IPv6 should look like. Many people<br>
disagree with that ok. Its very hard to please everyone indeed, hence<br>
KISS concept should be followed.<br>
<br>
Also, the whole dual stack thing should be required only on<br>
content providers, so client should be moved to IPv6, freeing<br>
more space from IPv4 with could be moved to content/hosting.<br>
Once there is enough critical mass of clients on IPv6, IPv4 could be<br>
dropped gradually. This avoids chicken and egg problem.<br>
<br>
Lets stop that E2E myth, we do NOT have e2e connectivity on client side<br>
from loong time (users NATs, CGNATs). And you know what? Its not that<br>
needed these days due to how internet is centralized today.<br>
Its good moment for change imo, but we blowed it.<br>
<br>
<br>
---------- Original message ----------<br>
<br>
From: Tom Beecher <<a href="mailto:beecher@beecher.cc" target="_blank">beecher@beecher.cc</a>><br>
To: <a href="mailto:borg@uu3.net" target="_blank">borg@uu3.net</a><br>
Cc: <a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a><br>
Subject: Re: V6 still not supported<br>
Date: Thu, 17 Mar 2022 07:40:32 -0400<br>
<br>
˙˙It seems all the market needed was IPv4 with bigger address space.<br>
Instead of delivering it, some contraption has been created trying to solve<br>
non-existant (or already fixed) problems.˙˙<br>
<br>
your argument against IPv6 is that they should have created a new version<br>
of IPv4, but bigger?<br>
<br>
So˙˙ IPv6?<br>
<br>
On Thu, Mar 17, 2022 at 06:32 <<a href="mailto:borg@uu3.net" target="_blank">borg@uu3.net</a>> wrote:<br>
<br>
> It seems team developing IPv6 had ONE way of doing things,<br>
> with is actually recipe for disaster. Why? Because they were building an IP<br>
> protocol. Something that will be using globally by ALL networks around.<br>
> Not some local IOT (useless) shit used here and there.<br>
> Thats why such IP protocol should be follow KISS concept and flexibility.<br>
> Some people have different vision how to run network. And because<br>
> Inter-net is an AS to AS network they should have right to do so.<br>
><br>
> In my opinion all that crypto stuff should be put layer upper because<br>
> crypto is hard, very hard and can get obsolete quickly.<br>
><br>
> Its same about other weird things embedded into IPv6 that probably<br>
> should go layer up. And now people wonder why IPv6 adoption is crap and<br>
> there is high resistance. IPv4 made mistakes too, but hell, it was the<br>
> first.<br>
><br>
> It seems all the market needed was IPv4 with bigger address space.<br>
> Instead of delivering it, some contraption has been created trying to solve<br>
> non-existant (or already fixed) problems.<br>
><br>
> Just my 2 cents...<br>
><br>
><br>
> ---------- Original message ----------<br>
><br>
> From: William Allen Simpson <<a href="mailto:william.allen.simpson@gmail.com" target="_blank">william.allen.simpson@gmail.com</a>><br>
> To: NANOG <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br>
> Subject: Re: V6 still not supported<br>
> Date: Wed, 16 Mar 2022 22:24:14 -0400<br>
><br>
> I'd wanted to clearly distinguish this from the old methods:<br>
><br>
>    This is intended to replace ARP, ICMP Router Advertisement, ICMP<br>
>    Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the [IPv6]<br>
>    environment. There are also elements of the OSI ES-IS and IS-IS Hello.<br>
><br>
> We were forward looking to deployments of thousands of systems per link,<br>
> rather<br>
> than the 30 maximum under then current ethernet standards.  We needed fewer<br>
> announcements, less chatty traffic, and more specific traffic designation.<br>
><br>
> We also prioritized network security.  Moreover requiring addresses be<br>
> ephemeral,<br>
> such that applications would not be able to tie<br>
> authentication/authorization to<br>
> an<br>
> IPv6 address and would be motivated to use cryptographic security.<br>
><br>
> Unfortunately, later committees decided that rather than a single simpler<br>
> secured<br>
> address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6.<br>
> Three ways to do the same thing are always a recipe for disaster.<br>
><br>
> Reminder: I was an operator and one of the original NANOG members.<br>
><br>
> We spent a lot of time considering human factors.  I'd pioneered the<br>
> "Operational Considerations" section of the original draft RFCs.<br>
><br>
> IPv6 is a case study of what happens with committee-itis.<br>
><br>
> The small design team worked well.<br>
><br>
</blockquote></div>