One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

Sat Jan 13 11:06:00 UTC 2024

My position is a bit more subtle than I stated.  I tend to forget I can and
should be more nuanced on this particular list.

First,  there is very little cost to any large tech company to state a date
that they expect to turn off IPv4 for certain services.   "To get our free
xyz service after January 1, 2028, you'll need to be on a provider that
supports IPv6".   The tech companies can then push out that deadline if
they don't see enough adoption as the deadline approaches.  There are, of
course, risks related to consumers switching to other alternatives prior to
the date and also various other reputation and legal risks.    But I
suspect that can be managed in a way that minimizes the risks.  But the
point here is that the setting of a possible IPv4 shutoff date is likely to
accelerate IPv6 adoption even if they never actually shut off IPv4.

I guess if one was to abstract the above out at a very high level it would
be to say that about the easiest way that I can see to further accelerate
IPv6 adoption is to either start to provide certain desirable services only
over IPv6 or at least threaten to do so.  The Googles of the world just
happen to be in the best position to do just that and may have a financial
motivation to do so (if they can do so without negatively impacting their
bottom line).

On Sat, Jan 13, 2024, 12:42 AM Giorgio Bonfiglio <me at grg.pw> wrote:

>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> […] I really expect something like this to be the next part of the end game
> for IPv4.
>
>>
> It’s never gonna happen … why would Google, or any other internet
> property, launch something which artificially cuts the potential revenue
> pool to IPv6-ready customers?
>
> I’m with you it would be amazing and a strong driver, but it’s just not in
> the realm of possibility…
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240113/92eeda95/attachment.html>