>> We are 20+ years in.
>> If we (as the collective we) believed in this transition shouldn't the next step be to remove the A records from {mail,datatracker,www}.ietf.org? And add a piece of Javascript blocking any client coming through a translator from v4.
> Our recommended transition strategy was dual-stack. Removing IPv4 support is premature until IPv6 is ubiquitous. Nobody is proposing that github be made IPv6-only.
>> I would expect ridicule from such a proposal.
>> Our tools including our collboration tools are centralized, they don't benefit much from IPv6 and end to end transparency either.
>
> No but it's entirely possible that there are, or soon will be, IETF participants who cannot access github because of the lack of IPv6 support. As IPv6 becomes more available and IPv4 space more and more scarce we should expect that some existing access networks will discontinue IPv4 support. Who wants to maintain equipment and routes that aren't used anymore? When public IPv4 network access disappears, it will happen gradually at first, and then everywhere suddenly.
>
> I don't think the github situation is an emergency yet, but I agree that we need to make sure that all of the tools that we use and expect participants to use are accessible via IPv6. Maybe not this week, but probably this year.
I'm quite aware of the IETF transition strategy.
20+ years in isn't apparent that it is working. The IETF cannot disable IPv4 from it's properties in the forseeable future. It is equally unforseeable when a client can communicate only IPv6 end to end.
The sorry reality is that the centralized network combined with the fact that a single IPv4 address is sufficient for a small country (with a port overloading NAT) there is no urgency to the transition.
I would love to be proven wrong of course...
Cheers,
Ole
