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....@nanog.org> On Behalf Of > Vasilenko Eduard via NANOG > Sent: jeudi 31 mars 2022 14:36 > To: Joe Maimon <jmai...@jmaimon.com>; Tom Beecher <beec...@beecher.cc> > Cc: NANOG <nanog@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....@nanog.org] On > Behalf Of Joe Maimon > Sent: Thursday, March 31, 2022 3:01 AM > To: Tom Beecher <beec...@beecher.cc> > Cc: NANOG <nanog@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 <jmai...@jmaimon.com > > <mailto:jmai...@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
