Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Thu Mar 31 12:52:58 UTC 2022

Hi Eduard

And SDN, and overlays, and... I certainly agree with what you're saying. 

This is why the L3 tech has to keep evolving as a survival trait. It's a delicate balance between evolving too quickly and producing the impression on unstable tech in the one hand, and stalling in the prehistory that you describe on the other, ask a dino when you meet one.

I argue that there are IPv6 RFCs to accommodate the cases I've seen on this list, but that the capabilities are largely ignored and -consequently- did not necessarily pass the PM barrier. Stalled we are indeed, but not for the lack of IETF work.

Keep safe;

Pascal

> -----Original Message-----
> From: NANOG <nanog-bounces+pthubert=cisco.com at nanog.org> On Behalf Of
> Vasilenko Eduard via NANOG
> Sent: jeudi 31 mars 2022 14:36
> To: Joe Maimon <jmaimon at jmaimon.com>; Tom Beecher <beecher at beecher.cc>
> Cc: NANOG <nanog at nanog.org>
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> IMHO: IETF is only partially guilty. Who was capable to predict in 1992-1994
> that:
> 
> - Wireless would become so popular (WiFi is from 1997) and wireless would
> emulate multicast so badly (hi SLAAC)
> - Hardware forwarding (PFE) would be invented (1997) that would have a big
> additional cost to implement Enhanced Headers
> - Encryption would never have a small enough cost to make it mandatory
> - Router would be available in every smallest thing that makes distributed
> address acquisition redundant (hi SLAAC)
> 
> We should be fair - it was not possible to guess.
> 
> Ed/
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com at nanog.org] On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 3:01 AM
> To: Tom Beecher <beecher at beecher.cc>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
> 
> 
> 
> Tom Beecher wrote:
> >
> >     If the IETF has really been unable to achieve consensus on properly
> >     supporting the currently still dominant internet protocol, that is
> >     seriously problematic and a huge process failure.
> >
> >
> > That is not an accurate statement.
> >
> > The IETF has achieved consensus on this topic. It's explained here by
> > Brian Carpenter.
> >
> > https://mailarchive.ietf.org/arch/msg/int-area/qWaHXBKT8BOx208SbwWILDX
> > yAUA/
> 
> As I have explained with my newly introduced consensus standards, there is no
> such consensus.
> 
> To reiterate my consensus standards, consensus is only to be considered as
> amongst stakeholders and IPv6 specific related stakes are not relevant to
> IPv4. If you consider the reverse to be true as well, I think my version of
> consensus would achieve a much wider and diverse consensus than the the
> stated IETF's consensus.
> 
> Once a consensus has been proven invalid its beyond obnoxious to cling to it
> as though it maintains its own reality field.
> 
> >
> > He expressly states with many +1s that if something IPv4 related needs
> > to get worked on , it will be worked on,
> 
> IPv4 still needs address exhaustion solutions.
> 
> > but the consensus solution to V4 address exhaustion was IPng that
> > became IPv6, so that is considered a solved problem.
> 
> IPv6 is not a solution. Its a replacement that does not have the same
> problem. Which could be a solution to the problem, but only if the
> replacement happens on schedule. However, so long as the replacement hasnt
> happened, we still are dealing with the problem.
> 
> The IETF made a stupendously bad bet that IPv6 would happen in time.
> That is the kind of bet that you better be right about. They were a
> decade+ wrong. That they have the audacity and temerity to continue
> doubling down on that would be funny if it wasnt so outrageous, wrong and
> harmful.
> 
> Let us re-examine the premise. When did it become acceptable to quash work on
> one protocol because of the existence of another one that is preferred by the
> quashers?
> 
> Or in other words, the way you are framing things makes it seem as if the
> IETF has with intent and malice chosen to extend or at the very least ignore
> exhaustion issues for actual internet users so as to rig the system for their
> preferred outcome.
> 
> >
> > Some folks don't LIKE the solution, as is their right to do.
> 
> I agree. I like most of IPv6 just fine. Not SLAAC, not multicast l2
> resolution, not addressing policy, not the chaos of choice of inadequate
> interoperability approaches, not the denial of features desired by users, not
> the pmtud, not the fragmentation, and many other warts. I dont even like the
> notation schemes. They require multiple vision passes.
> 
> I do like the extra bits. Just not the way they are being frittered.
> 
> The real crux of the matter is that it did not work. Address exhaustion has
> not been alleviated. For many years now and who knows how much longer.
> 
> > But the problem of V4 address exhaustion is NOT the same thing as "I
> > don't like the solution that they chose."
> 
> The problem of V4 address exhaustion is NOT the same thing as turn on
> IPv6 and wait for the rest of the world to do the same.
> 
> When considered in that manner the IETF's bet looks even worse.
> 
> What I dont like is that they were wrong. What I dislike even more is that
> they refuse to admit it and learn from their mistakes.
> 
> Joe
> 
> > On Wed, Mar 30, 2022 at 12:18 PM Joe Maimon <jmaimon at jmaimon.com
> > <mailto:jmaimon at jmaimon.com>> wrote:
> >
> >
> >
> >     Owen DeLong via NANOG wrote:
> >
> >     >
> >     > Well… It’s a consensus process. If your idea isn’t getting
> >     consensus,
> >     > then perhaps it’s simply that the group you are seeking
> >     consensus from
> >     > doesn’t like your idea.
> >
> 
> Consensus processes are vulnerable to tyranny of a well positioned minority.
> 
> Joe