[Witarea] Re: [v6ops] Re: How to make an elegant IPv4 outage

Erik,

On 13-Jun-26 02:19, Erik Nygren wrote:
> + v6ops
> 
> On the topic of the original draft (https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6-01 <https://datatracker.ietf.org/doc/html/draft-martin-retry-over-ipv6-01>):
> 
> 1) I wonder if this is pointing towards a desire to either start sunset4 back up again, or to charter work within some existing WG (v6ops, 6man, others?) to pick back up on where sunset4 left off, specifically looking for technology solutions and operational recommendations to provide a path towards phasing out IPv4 in various environments.  

I really hope not. I think we have learnt that attacking currently working solutions is self-defeating, which is ultimately why sunset4 failed.

> (Some of the work Jordi and v6ops are doing on trying to define "IPv6-only" is a good start in this direction.) While this may be a long way off for the general end-user consumer usability, as mentioned by others there are increasing environments (eg, cloud applications, building infrastructure) where IPv6-only is now viable.

Absolutely. But operators won't take any notice until they decide that moving to IPv6-mostly or even IPv6-only will reduce OPEX.

> 
> 2) For your specific proposal, I wonder if DNS signaling might be a less invasive way to do this?  In particular, we might want to define a SVCB SvcParam for "ipv6only" to indicate that an endpoint has no IPv4 support.  

My idea requires no new definitions. Just return an A record pointing to 0.0.0.0, and I suspect that Happy Eyeballs or correct use of getaddrinfo() would make the right thing happen in dual stack clients. Franck's comment about blast radius would still apply (intentionally?).

     Brian
  
> Clients could achive something similar to your proposal by warning if the most preferred SVCB endpoints are IPv6-only and the client is unable to use them for that reason.  For the specific example of the Czechia use-case, they could have HTTPS RRs in the DNS where the top priority one indicates that it is IPv6-only followed by a lower priority one which is dualstacked.  They could later drop the dualstacked endpoint.  I think this could achieve the same results as your retry-over-ipv6 draft with less complexity and with less need for fallback.
> 
> Erik
> 
> 
> 
> 
> 
> On Wed, Jun 3, 2026 at 5:29 PM Franck Martin <[email protected] <mailto:[email protected]>> wrote:
> 
>     Moving to Witarea, but keeping ietf in the loop for the moment.
> 
>     Hi Surya,
> 
>     Many thanks for those great points.
> 
>>     On Jun 3, 2026, at 13:00, S Moonesamy <[email protected] <mailto:sm%[email protected]>> wrote:
>>
>>     Hi Franck,
>>
>>     [Cc to witarea@]
>>
>>     At 11:32 AM 03-06-2026, Franck Martin wrote:
>>>     Today I submitted this Internet Draft (I-D) to the IETF
>>>     https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/ <https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/>
>>>
>>>     I have been building this site: pacific.ipv6forum.com <http://pacific.ipv6forum.com> and I have been wondering, how could I do an IPv4 outage on this site on 6/6?
>>>
>>>     I have also seen that Czechoslovakia has mandated the end of IPv4 on government sites on 6/6/2032, 6 years from now.
>>>
>>>     I also recall (from recent experience) that it is relatively easy to reach >90% of IPv6 connections to an internal network (think datacenter), but the remaining last % are difficult to identify (or discard) because services may misbehave and prefer IPv4 from time to time: You don't know if they can't really do IPv4 or if they did not bother to do IPv6.
>>>
>>>     In an enterprise environment, micro-services are made redundant, there are multiple IPs and have fallback mechanisms when they encounter a 5xx error on one endpoint.
>>>
>>>     So, I started to work on this Internet Draft. It is ready for the first round of public comments. I suspect, if successful, it will take 1 or 2 years to make it a standard. Then an extra 1 or 2 years, before it is implemented on enough clients (and browsers), we will be just in time for doing enough IPv4 outages on 6/6 to meet the 6/6/2032 deadline.
>>
>>     There is a recent thread about IPv6 at https://mailarchive.ietf.org/arch/msg/ipv6/BxSOgbF34xbBcijtxf85Pfnb5tc/ <https://mailarchive.ietf.org/arch/msg/ipv6/BxSOgbF34xbBcijtxf85Pfnb5tc/> I don't remember seeing anything resulting from that discussion.  Having a draft is, relatively, better than the usual email discussion.  The draft falls under the WIT Area and v6ops (which is in another IETF Area).
> 
>     I quickly read the thread, and also asked for a summary. I agree with many points like : some mobiles are IPv6-only (T-Mobile, Reliance,…), some networks are IPv6-only on the management side (Comcast),.. StarLink is moving the needle A LOT in small countries, see countries on https://pacific.ipv6forum.com <https://pacific.ipv6forum.com>.. but yes the frontier is Entreprise adoption. I have some experience here that I’m trying to share.
> 
>>
>>     Section 1.1 of the draft states that "Governments are also publishing fixed IPv4 end dates" and lists one example [1].  Are there any other governments which have a fixed end date?
> 
>     I am not aware of other governments that have published an equally specific “IPv4 service ends on <date>” policy for their public services. Several others publish IPv6 transition *milestones* rather than a fixed IPv4 shutdown date — for example, US OMB M-21-07 (80% of federal IP-enabled assets in IPv6-only environments by FY 2025, with strategic intent to phase out IPv4): https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf <https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf>
> 
>     The Netherlands and others have long-standing IPv6 “use-or-explain” or adoption targets, but not, to my knowledge, a single published IPv4 end date comparable to the Czech case.
> 
>     There was also a memo from the State of Washington going in the same direction…
> 
>     I used to track all those… looks like I need to do that again.
> 
>     And I agree that those memos come and go… Why? Because it is not trivial, we (IETF?) ought to make it easier.
>>
>>     Section 3 of the draft states that "Many operators plan to remove or disable IPv4 while retaining IPv6 service."  Are those plans available on the operators' websites?
> 
>     I tend to abuse the word “Many”, you caught me! I make a note to change it to “Some"
> 
>     That being said:
> 
>       * Meta is IPv6-only in their data centers: https://engineering.fb.com/2017/01/17/production-engineering/legacy-support-on-ipv6-only-infra/ <https://engineering.fb.com/2017/01/17/production-engineering/legacy-support-on-ipv6-only-infra/>
>       * Google Cloud has guidance for IPv6-only: https://cloud.google.com/blog/products/networking/connect-ipv6-only-workloads-to-ipv4-with-dns64-and-nat64 <https://cloud.google.com/blog/products/networking/connect-ipv6-only-workloads-to-ipv4-with-dns64-and-nat64>
>       * All the could providers are moving to support IPv6 (because for instance K8S bring undue complexity when you use NAT, also with the explosion of AI agents, this will not be sustainable, I’m not worry, they can afford to buy large chunks of IPv4 - side note: I spoke recently with a banker on why IPv4 is not on the balance sheet of companies?)
>       * Cisco has an IPv6-only building: https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future <https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future>
>       * Orange is considering IPv6-only: https://www.youtube.com/watch?v=ahlY1vwM8qE <https://www.youtube.com/watch?v=ahlY1vwM8qE>
>       * Microsoft has IPv6-only deployments (I know that in Azure this is way more complicated): https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/ <https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/>
>       * LinkedIn is moving to Dual Stack and IPv6-only in their Datacenters. I may point you to the links in this post: https://www.patreon.com/posts/ipv6-in-lessons-159595711 <https://www.patreon.com/posts/ipv6-in-lessons-159595711> where I share my experience with IPv6.
> 
> 
>     On this last point, I want to say my motivation is more on how to make life easier for internal deployments than external deployments. As such I found out that making a software outage is easier than an infrastructure outage, and easier and faster to rollback. “You can’t fix what you don’t measure”, if you can differentiate an IPv4 outage from any other outage, then you don’t know what to fix.
> 
>     I’m not expecting the web browsers to implement anything fast, but I think we can have “faster” implementation in open source software like gRPC and Rest.Li to make life easier in enterprises, therefore impacting other software in those enterprises, which will lead to make it easier on the public Internet...
> 
>     So thanks for all those valid points, I’ll figure out how to better answer them in version -01.
> 
>     I tried to address the same with email, a while back. See those expired ID: https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/ <https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/>, https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6/ <https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6/>. I hope this ID has a bit more chances.
> 
>     Franck
>     PS: if any has more references of mandate or wannabe mandates, please let me know.
> 
>>
>>     Regards,
>>     S. Moonesamy
>>
>>     1. The IPv6 adoption rate for a social network in that country is 35.2%.
> 
> 
> _______________________________________________
> v6ops mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
-- 
Witarea mailing list -- [email protected]
To unsubscribe send an email to [email protected]