[ih] Internet without entrenched factions?

[Brian E Carpenter]

On 15-May-26 05:49, John Gilmore wrote:
> Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
>> I think most people have accepted the reality that v4 and v6
>> will coexist for many years to come. But many of us think that
>> if IPv4 ain't broke, we shouldn't fix it.
> 
> Brian, I seriously respect your work on IPv6.  You and the v6 pioneers
> have saved the Internet from its success disaster of address exhaustion.
> But here you are recommending a double standard:
> 
>    https://en.wikipedia.org/wiki/Double_standard
> 
> If IPv6 ain't broke, we shouldn't fix it either.
> 
> You're not suggesting that IPv6 is broken, nor am I.  Yet IPv6 continues
> to be fixed.

Well, there's one area that stills needs to be fixed, and it's one that the
ROAD group flagged in 1992 [RFC1380] and the IRTF Routing Research Group flagged
in 2011 [RFC6115] and the ipv6ops WG is still discussing today. We don't know how to
support site multihoming in a competitive environment for tens of millions of small
and medium enterprises. CIDR and BGP4 scale pretty well, but not for tens of millions
of multihomed sites. And because the speed of light is invariant under Moore's Law,
this does not appear to be a problem that can be solved by attaching more powerful
rockets to a terrestrial pig.

Apart from that, I would have to do a lot of work to classify which of those IPv6
related drafts are fixes to IPv6, which are about IPv4/IPv6 coexistence, and which
are evolution.

What I can tell you is that the rate of IPv6-related RFCs per kiloRFC peaked a
few years ago, in the RFC 6000-6999 series (16 on coexistence, 86 on IPv6 alone,
or about 10% of the IETF's output).

In the current RFC9000-9999 series, which is almost done, we so far have
4 on coexistence, 49 on IPv6 as such. Or, about 5% of the IETF's output.

    Brian

> 
> IPv6 continues to be fixed by IETF -- and IPv4 doesn't.
> 
> Neither one is broken.
> 
> Both should evolve -- are evolving.  But not at IETF.


> 
> 	John
>