Return-Path: X-Original-To: witarea@mail2.ietf.org Delivered-To: witarea@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 755E6FCE2E3C; Sun, 7 Jun 2026 11:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780857531; bh=9pelbER+yyFKdrnlYun+rfTVKDLiwyeBPWJEiRy0OLo=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=ElQ5+w38dMsBmgREvv20ztmvF5FxW403wnMevrSz6GR9MHpKZoXunSas9MLKfJRfm hEt5b2j3ANkisRJe64IjJDIe1m/7PvXYX5skZWPJ/M7YGsjuiqOKSonPjTKOm1adrP +nypf3vymm18ruO0uAPTc54+ws9gywr4VvBZy6Ww= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=peachymango.org Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH6hSCUIHGFC; Sun, 7 Jun 2026 11:38:49 -0700 (PDT) Received: from zmcc-4-mx.zmailcloud.com (zmcc-4-mx.zmailcloud.com [34.203.170.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B0154FCE2E28; Sun, 7 Jun 2026 11:38:49 -0700 (PDT) Received: from zmcc-3.zmailcloud.com (ec2-3-15-255-223.us-east-2.compute.amazonaws.com [3.15.255.223]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by zmcc-4-mx.zmailcloud.com (Postfix) with ESMTPS id 96B21782D699; Sun, 7 Jun 2026 13:38:49 -0500 (CDT) Received: from zmcc-3.zmailcloud.com (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTPS id 7606FA00E323; Sun, 7 Jun 2026 13:38:49 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 5B778A00E33C; Sun, 7 Jun 2026 13:38:49 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.10.3 zmcc-3-mta-1.zmailcloud.com 5B778A00E33C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=8CB80586-E3FE-11EB-B0E7-C1E0928D69D1; t=1780857529; bh=9pelbER+yyFKdrnlYun+rfTVKDLiwyeBPWJEiRy0OLo=; h=Date:From:To:Message-ID:MIME-Version; b=dX+Lr6mOeLf5V6cdegaoxKBmb6opFyHI36iHtj0eR4fcWlseuviXtYX2MpmqkLV/b +lq6V5Yel5hfCWIK33ZCSeiZyZlk2hoLtJM7n9BCSSOwUZlKUXgNKHZumJ0/eliZig 8QW4aMBl397Ufka4gL9oUx52rsoGtuh6/oMIrgtcLVDnPSupBcFU+YWL5/yPQP7Tu+ MiyOvZPE2/zO55smogOY1odRml/xC/csczSSjL3eV+xwNxTQNDmx9b9qYwa4VEJ00Y Fom+26i+BI2IPSTLIY8dHL0OgV/+FflGQhMK0zRFvVkBYSHy7uFsvAGgP1vLQ19hcQ nH5d5qRWkWSsg== Received: from zmcc-3.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-3-mta-1.zmailcloud.com [127.0.0.1]) (amavis, port 10026) with ESMTP id mgt3DgW0URMa; Sun, 7 Jun 2026 13:38:49 -0500 (CDT) Received: from zmcc-3-mailbox-1.zmailcloud.com (zmcc-3-mailbox-1.zmailcloud.com [172.31.18.168]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 05F97A00E323; Sun, 7 Jun 2026 13:38:48 -0500 (CDT) Date: Sun, 7 Jun 2026 13:38:48 -0500 (CDT) From: Franck Martin To: Nick Buraglio Message-ID: <1019057082.341169112.1780857528310.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <456388925.296572478.1780511571678.JavaMail.zimbra@zmcc-3-mailbox-1.zmailcloud.com> <6.2.5.6.2.20260603121059.18d33668@elandnews.com> <1123312645.298995989.1780522146673.JavaMail.zimbra@zmcc-3-mailbox-1.zmailcloud.com> <3a456baf-2507-487e-bb09-2d5dae6165fa@gmail.com> <109008554.300485918.1780530680809.JavaMail.zimbra@zmcc-3-mailbox-1.zmailcloud.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_98f739d3-bf1b-4b6f-b417-9026a918702b" X-Mailer: Zimbra 10.1.13_GA_4837 (ZimbraWebClient - SAF26.5 (Mac)/10.1.14_GA_4838) Thread-Topic: How to make an elegant IPv4 outage Thread-Index: zwpuRCMuRIfzt9L+q3sEuTU8LFu8Xg== Message-ID-Hash: SJMIZYP6ZQXP7FNEJ535RUZQ3X2DN4RU X-Message-ID-Hash: SJMIZYP6ZQXP7FNEJ535RUZQ3X2DN4RU X-MailFrom: franck@peachymango.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Xipengxiao , Brian E Carpenter , S Moonesamy , witarea , ietf , v6ops X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BWitarea=5D_Re=3A_=5Bv6ops=5D_Re=3A_How_to_make_an_elegant_IPv4_?= =?utf-8?q?outage?= List-Id: "Web and Internet Transport (WIT) Area" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=_98f739d3-bf1b-4b6f-b417-9026a918702b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I spent some time diving into various K8S deployments. K8S is great, but yo= u really really need to standardize your deployments. And because K8S uses = eBPF, and sometimes some network namespaces and sometimes not, you can no l= onger trust /proc/net to tell you the reality. you need to dive into the na= mespaces too...=20 so K8S NAT is often not stored in the routing or iptable, but in eBPF, and = it is very hard to get that information when you are on the host itself... = At least that was my experience.=20 having K8S with IPv6-only makes life much easier.=20 From: "Nick Buraglio" =20 To: "Xipengxiao" =20 Cc: "Franck Martin" , "Brian E Carpenter" , "S Moonesamy" , "witarea" , "ietf" , "v6ops" =20 Sent: Sunday, June 7, 2026 8:32:24 AM=20 Subject: Re: [v6ops] Re: How to make an elegant IPv4 outage=20 +1=20 We have done k8s with IPv6-only in our data centers and once the initial hu= rdles are past, it is significantly easier to work with.=20 Where the complications lie are in the random libraries inside of random co= ntainers, and in some cases in the container repositories.=20 I=E2=80=99m curious to see what your experience is/was, and how it differed= from ours, if at all.=20 nb=20 On Fri, Jun 5, 2026 at 10:21 Xipengxiao wrote:=20 Hi Franck,=20 You are very welcome to take the lead on "Deploying IPv6 in the Data Center= /Enterprises". We look forward to your drafts.=20 XiPeng=20 -----Original Message-----=20 From: Franck Martin < [ mailto:franck@peachymango.org | franck@peachymango.= org ] >=20 Sent: Thursday, June 4, 2026 1:51 AM=20 To: Brian E Carpenter < [ mailto:brian.e.carpenter@gmail.com | brian.e.carp= enter@gmail.com ] >=20 Cc: S Moonesamy < [ mailto:sm%2Bietf@elandsys.com | sm+ietf@elandsys.com ] = >; witarea < [ mailto:witarea@ietf.org | witarea@ietf.org ] >; ietf < [ mai= lto:ietf@ietf.org | ietf@ietf.org ] >; [ mailto:v6ops@ietf.org | v6ops@ietf= .org ]=20 Subject: [v6ops] Re: How to make an elegant IPv4 outage=20 Adding v6ops to the list of Cc=20 Brian,=20 Getting myself up to date with the v6ops.=20 I see there is a milestone to adopt by dec 2026 Deploying IPv6 in the Data = Center and Deploying IPv6 in the Enterprise. I have some experience with th= is having done that at LinkedIn and been very close to an IPv6-only deploym= ent. I also was aware of what was happening at the mothership at Microsoft.= =20 I don=E2=80=99t see any lead for this besides the WG chair. I would be happ= y to contribute and may be to reach out to folks. I quickly looked through = the archives but did not see anything obvious on those topics.=20 Franck=20 > On Jun 3, 2026, at 15:34, Brian E Carpenter < [ mailto:brian.e.carpenter@= gmail.com | brian.e.carpenter@gmail.com ] > wrote:=20 >=20 > Franck,=20 >=20 > You definitely need to keep [ mailto:v6ops@ietf.org | v6ops@ietf.org ] aw= are of this.=20 >=20 > I assume you are aware of [ https://datatracker.ietf.org/doc/draft-palet-= v6ops-ipv6-only/ | https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-= only/ ] and other work in v6ops related to IPv6-only and IPv6-mostly.=20 >=20 > Regards/Ng=C4=81 mihi=20 > Brian Carpenter=20 >=20 > On 04-Jun-26 09:29, Franck Martin wrote:=20 >> Moving to Witarea, but keeping ietf in the loop for the moment.=20 >> Hi Surya,=20 >> Many thanks for those great points.=20 >>> On Jun 3, 2026, at 13:00, S Moonesamy < [ mailto:sm%2Bietf@elandsys.com= | sm+ietf@elandsys.com ] > wrote:=20 >>>=20 >>> Hi Franck,=20 >>>=20 >>> [Cc to witarea@]=20 >>>=20 >>> At 11:32 AM 03-06-2026, Franck Martin wrote:=20 >>>> Today I submitted this Internet Draft (I-D) to the IETF=20 >>>> [ https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/ | htt= ps://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/ ]=20 >>>>=20 >>>> I have been building this site: [ http://pacific.ipv6forum.com/ | paci= fic.ipv6forum.com ] and I have been wondering, how could I do an IPv4 outag= e on this site on 6/6?=20 >>>>=20 >>>> I have also seen that Czechoslovakia has mandated the end of IPv4 on g= overnment sites on 6/6/2032, 6 years from now.=20 >>>>=20 >>>> I also recall (from recent experience) that it is relatively easy to r= each >90% of IPv6 connections to an internal network (think datacenter), bu= t the remaining last % are difficult to identify (or discard) because servi= ces 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.=20 >>>>=20 >>>> In an enterprise environment, micro-services are made redundant, there= are multiple IPs and have fallback mechanisms when they encounter a 5xx er= ror on one endpoint.=20 >>>>=20 >>>> So, I started to work on this Internet Draft. It is ready for the firs= t round of public comments. I suspect, if successful, it will take 1 or 2 y= ears to make it a standard. Then an extra 1 or 2 years, before it is implem= ented on enough clients (and browsers), we will be just in time for doing e= nough IPv4 outages on 6/6 to meet the 6/6/2032 deadline.=20 >>>=20 >>> There is a recent thread about IPv6 at [ https://mailarchive.ietf.org/a= rch/msg/ipv6/BxSOgbF34xbBcijtxf85Pfnb5tc/ | https://mailarchive.ietf.org/ar= ch/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).=20 >> I quickly read the thread, and also asked for a summary. I agree with ma= ny points like : some mobiles are IPv6-only (T-Mobile, Reliance,=E2=80=A6),= some networks are IPv6-only on the management side (Comcast),.. StarLink i= s moving the needle A LOT in small countries, see countries on [ https://pa= cific.ipv6forum.com/ | https://pacific.ipv6forum.com ] < [ https://pacific.= ipv6forum.com/ | https://pacific.ipv6forum.com ] >.. but yes the frontier i= s Entreprise adoption. I have some experience here that I=E2=80=99m trying = to share.=20 >>>=20 >>> Section 1.1 of the draft states that "Governments are also publishing f= ixed IPv4 end dates" and lists one example [1]. Are there any other governm= ents which have a fixed end date?=20 >> I am not aware of other governments that have published an equally=20 >> specific =E2=80=9CIPv4 service ends on =E2=80=9D policy for their = public=20 >> services. Several others publish IPv6 transition *milestones* rather=20 >> than a fixed IPv4 shutdown date =E2=80=94 for example, US OMB M-21-07 (8= 0% of=20 >> federal IP-enabled assets in IPv6-only environments by FY 2025, with=20 >> strategic intent to phase out IPv4):=20 >> [ https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf | ht= tps://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf ]=20 >> The Netherlands and others have long-standing IPv6 =E2=80=9Cuse-or-expla= in=E2=80=9D or adoption targets, but not, to my knowledge, a single publish= ed IPv4 end date comparable to the Czech case.=20 >> There was also a memo from the State of Washington going in the same=20 >> direction=E2=80=A6 I used to track all those=E2=80=A6 looks like I need = to do that again.=20 >> And I agree that those memos come and go=E2=80=A6 Why? Because it is not= trivial, we (IETF?) ought to make it easier.=20 >>>=20 >>> Section 3 of the draft states that "Many operators plan to remove or di= sable IPv4 while retaining IPv6 service." Are those plans available on the = operators' websites?=20 >> I tend to abuse the word =E2=80=9CMany=E2=80=9D, you caught me! I make a= note to change it to =E2=80=9CSome"=20 >> That being said:=20 >> * Meta is IPv6-only in their data centers:=20 >> [ https://engineering.fb.com/2017/01/17/production-engineering/legacy-s = | https://engineering.fb.com/2017/01/17/production-engineering/legacy-s ]= =20 >> upport-on-ipv6-only-infra/=20 >> < [ https://engineering.fb.com/2017/01/17/production-engineering/legacy-= | https://engineering.fb.com/2017/01/17/production-engineering/legacy- ]= =20 >> support-on-ipv6-only-infra/>=20 >> * Google Cloud has guidance for IPv6-only:=20 >> [ https://cloud.google.com/blog/products/networking/connect-ipv6-only-w = | https://cloud.google.com/blog/products/networking/connect-ipv6-only-w ]= =20 >> orkloads-to-ipv4-with-dns64-and-nat64=20 >> < [ https://cloud.google.com/blog/products/networking/connect-ipv6-only-= | https://cloud.google.com/blog/products/networking/connect-ipv6-only- ]= =20 >> workloads-to-ipv4-with-dns64-and-nat64>=20 >> * All the could providers are moving to support IPv6 (because for=20 >> instance K8S bring undue complexity when you use NAT, also with the=20 >> explosion of AI agents, this will not be sustainable, I=E2=80=99m not wo= rry,=20 >> they can afford to buy large chunks of IPv4 - side note: I spoke=20 >> recently with a banker on why IPv4 is not on the balance sheet of=20 >> companies?)=20 >> * Cisco has an IPv6-only building:=20 >> [ https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future | http= s://blogs.cisco.com/networking/an-ipv6-campus-of-the-future ]=20 >> < [ https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future | ht= tps://blogs.cisco.com/networking/an-ipv6-campus-of-the-future ] >=20 >> * Orange is considering IPv6-only:=20 >> [ https://www.youtube.com/watch?v=3DahlY1vwM8qE | https://www.youtube.co= m/watch?v=3DahlY1vwM8qE ]=20 >> < [ https://www.youtube.com/watch?v=3DahlY1vwM8qE | https://www.youtube.= com/watch?v=3DahlY1vwM8qE ] >=20 >> * Microsoft has IPv6-only deployments (I know that in Azure this is=20 >> way more complicated):=20 >> [ https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/ | https://= labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/ ]=20 >> < [ https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/ | https:= //labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/ ] >=20 >> * 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/i= pv6-in-lessons-159595711 | https://www.patreon.com/posts/ipv6-in-lessons-15= 9595711 ] where I share my experience with IPv6.=20 >> On this last point, I want to say my motivation is more on how to make l= ife easier for internal deployments than external deployments. As such I fo= und out that making a software outage is easier than an infrastructure outa= ge, and easier and faster to rollback. =E2=80=9CYou can=E2=80=99t fix what = you don=E2=80=99t measure=E2=80=9D, if you can differentiate an IPv4 outage= from any other outage, then you don=E2=80=99t know what to fix.=20 >> I=E2=80=99m not expecting the web browsers to implement anything fast, b= ut I think we can have =E2=80=9Cfaster=E2=80=9D implementation in open sour= ce software like gRPC and Rest.Li to make life easier in enterprises, there= fore impacting other software in those enterprises, which will lead to make= it easier on the public Internet...=20 >> So thanks for all those valid points, I=E2=80=99ll figure out how to bet= ter answer them in version -01.=20 >> 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-fallb= ack/ | https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fall= back/ ] < [ https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4= -fallback/ | https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv= 4-fallback/ ] >, [ https://datatracker.ietf.org/doc/draft-martin-smtp-targe= t-host-selection-ipv4-ipv6/ | https://datatracker.ietf.org/doc/draft-martin= -smtp-target-host-selection-ipv4-ipv6/ ] < [ https://datatracker.ietf.org/d= oc/draft-martin-smtp-target-host-selection-ipv4-ipv6/ | https://datatracker= .ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6/ ] >. I hop= e this ID has a bit more chances.=20 >> Franck=20 >> PS: if any has more references of mandate or wannabe mandates, please le= t me know.=20 >>>=20 >>> Regards,=20 >>> S. Moonesamy=20 >>>=20 >>> 1. The IPv6 adoption rate for a social network in that country is 35.2%= .=20 _______________________________________________=20 v6ops mailing list -- [ mailto:v6ops@ietf.org | v6ops@ietf.org ]=20 To unsubscribe send an email to [ mailto:v6ops-leave@ietf.org | v6ops-leave= @ietf.org ]=20 _______________________________________________=20 v6ops mailing list -- [ mailto:v6ops@ietf.org | v6ops@ietf.org ]=20 To unsubscribe send an email to [ mailto:v6ops-leave@ietf.org | v6ops-leave= @ietf.org ]=20 --=_98f739d3-bf1b-4b6f-b417-9026a918702b Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I spent some time diving into various K8S dep= loyments. K8S is great, but you really really need to standardize your depl= oyments. And because K8S uses eBPF, and sometimes some network namespaces a= nd sometimes not, you can no longer trust /proc/net to tell you the reality= . you need to dive into the namespaces too...

so K8S NAT is often not stored in the routing or iptable,= but in eBPF, and it is very hard to get that information when you are on t= he host itself... At least that was my experience.

having K8S with IPv6-only makes life much easier.

From: "Nick Buraglio" <buraglio@forwardingpla= ne.net>
To: "Xipengxiao" <xipengxiao=3D40huawei.com@dmarc.i= etf.org>
Cc: "Franck Martin" <franck@peachymango.org>, "= Brian E Carpenter" <brian.e.carpenter@gmail.com>, "S Moonesamy" <s= m+ietf@elandsys.com>, "witarea" <witarea@ietf.org>, "ietf" <iet= f@ietf.org>, "v6ops" <v6ops@ietf.org>
Sent: Sunday, June= 7, 2026 8:32:24 AM
Subject: Re: [v6ops] Re: How to make an elega= nt IPv4 outage

+1

We= have done k8s with IPv6-only in our data centers and once the initial hurd= les are past, it is significantly easier to work with. 
Where the complications lie are in the random libraries inside of= random containers, and in some cases in the container repositories. <= /div>
I=E2=80=99m curious to see what your experience is/w= as, and how it differed from ours, if at all. 
=
nb

On Fri, Jun 5, 202= 6 at 10:21 Xipengxiao <xipengxiao=3D40huawei.= com@dmarc.ietf.org> wrote:
Hi Franck,

You are very welcome to take the lead on "Deploying IPv6 in the Data Center= /Enterprises".  We look forward to your drafts.

XiPeng

-----Original Message-----
From: Franck Martin <franck@peachymango.org>= ;
Sent: Thursday, June 4, 2026 1:51 AM
To: Brian E Carpenter <brian.e.carpenter@gmai= l.com>
Cc: S Moonesamy <sm+ietf@elandsys.com>; wit= area <witarea@ietf.org>; ietf <ie= tf@ietf.org>; v6ops@ietf.org
Subject: [v6ops] Re: How to make an elegant IPv4 outage

Adding v6ops to the list of Cc

Brian,

Getting myself up to date with the v6ops.

I see there is a milestone to adopt by dec 2026 Deploying IPv6 in the Data = Center and Deploying IPv6 in the Enterprise. I have some experience with th= is having done that at LinkedIn and been very close to an IPv6-only deploym= ent. I also was aware of what was happening at the mothership at Microsoft.=

I don=E2=80=99t see any lead for this besides the WG chair. I would be happ= y to contribute and may be to reach out to folks. I quickly looked through = the archives but did not see anything obvious on those topics.

Franck

> On Jun 3, 2026, at 15:34, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> Franck,
>
> You definitely need to keep v6ops@ietf.org aware o= f this.
>
> I assume you are aware of https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv= 6-only/ and other work in v6ops related to IPv6-only and IPv6-mostly. >
> Regards/Ng=C4=81 mihi
>   Brian Carpenter
>
> On 04-Jun-26 09:29, Franck Martin 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 <https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/<= br> >>>>
>>>> I have been building this site: pacific.ipv6forum.com and I have been wondering, how could I do a= n 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 relative= ly 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.<= br> >>>>
>>>> In an enterprise environment, micro-services are made redu= ndant, there are multiple IPs and have fallback mechanisms when they encoun= ter 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 t= ake 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.iet= f.org/arch/msg/ipv6/BxSOgbF34xbBcijtxf85Pfnb5tc/ I don't remember seein= g anything resulting from that discussion.  Having a draft is, relativ= ely, better than the usual email discussion.  The draft falls under th= e WIT Area and v6ops (which is in another IETF Area).
>> I quickly read the thread, and also asked for a summary. I agree w= ith many points like : some mobiles are IPv6-only (T-Mobile, Reliance,=E2= =80=A6), some networks are IPv6-only on the management side (Comcast),.. St= arLink is moving the needle A LOT in small countries, see countries on https://pacific.ipv6forum.com <https://pacific.ipv6forum.com>.. but yes t= he frontier is Entreprise adoption. I have some experience here that I=E2= =80=99m trying to share.
>>>
>>> Section 1.1 of the draft states that "Governments are also pub= lishing fixed IPv4 end dates" and lists one example [1].  Are there an= y other governments which have a fixed end date?
>> I am not aware of other governments that have published an equally=
>> specific =E2=80=9CIPv4 service ends on <date>=E2=80=9D polic= y for their public
>> services. Several others publish IPv6 transition *milestones* rath= er
>> than a fixed IPv4 shutdown date =E2=80=94 for example, US OMB M-21= -07 (80% of
>> federal IP-enabled assets in IPv6-only environments by FY 2025, wi= th
>> strategic intent to phase out IPv4):
>> https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf >> The Netherlands and others have long-standing IPv6 =E2=80=9Cuse-or= -explain=E2=80=9D or adoption targets, but not, to my knowledge, a single p= ublished IPv4 end date comparable to the Czech case.
>> There was also a memo from the State of Washington going in the sa= me
>> direction=E2=80=A6 I used to track all those=E2=80=A6 looks like I= need to do that again.
>> And I agree that those memos come and go=E2=80=A6 Why? Because it = is not trivial, we (IETF?) ought to make it easier.
>>>
>>> Section 3 of the draft states that "Many operators plan to rem= ove or disable IPv4 while retaining IPv6 service."  Are those plans av= ailable on the operators' websites?
>> I tend to abuse the word =E2=80=9CMany=E2=80=9D, you caught me! I = make a note to change it to =E2=80=9CSome"
>> That being said:
>>  * Meta is IPv6-only in their data centers:
>> https://engineering.fb.com/2017/01/17/production-engineering/legacy-= s
>> upport-on-ipv6-only-infra/
>> <https://engineering.fb.com/2017/01/17/production-engineering/le= gacy-
>> support-on-ipv6-only-infra/>
>>  * Google Cloud has guidance for IPv6-only:
>> https://cloud.google.com/blog/products/networking/connect-ipv6-only-= w
>> orkloads-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 (becaus= e for
>> instance K8S bring undue complexity when you use NAT, also with th= e
>> explosion of AI agents, this will not be sustainable, I=E2=80=99m = not worry,
>> they can afford to buy large chunks of IPv4 - side note: I spoke <= br> >> 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.youtu= be.com/watch?v=3DahlY1vwM8qE
>> <https://www.= youtube.com/watch?v=3DahlY1vwM8qE>
>>  * Microsoft has IPv6-only deployments (I know that in Azure = this is
>> way more complicated):
>> htt= ps://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 Da= tacenters. I may point you to the links in this post: 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 suc= h I found out that making a software outage is easier than an infrastructur= e outage, and easier and faster to rollback. =E2=80=9CYou can=E2=80=99t fix= what you don=E2=80=99t measure=E2=80=9D, if you can differentiate an IPv4 = outage from any other outage, then you don=E2=80=99t know what to fix.
>> I=E2=80=99m not expecting the web browsers to implement anything f= ast, but I think we can have =E2=80=9Cfaster=E2=80=9D implementation in ope= n source software like gRPC and Rest.Li to make life easier in enterprises,= therefore impacting other software in those enterprises, which will lead t= o make it easier on the public Internet...
>> So thanks for all those valid points, I=E2=80=99ll figure out how = to better answer them in version -01.
>> I tried to address the same with email, a while back. See those ex= pired ID: https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4= -fallback/ <https://datatracker.ietf.org/doc/draft-martin-smtp-ipv= 6-to-ipv4-fallback/>, https://datatracker.ietf.org/doc/d= raft-martin-smtp-target-host-selection-ipv4-ipv6/ <https= ://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ip= v6/>. I hope this ID has a bit more chances.
>> Franck
>> PS: if any has more references of mandate or wannabe mandates, ple= ase let me know.
>>>
>>> Regards,
>>> S. Moonesamy
>>>
>>> 1. The IPv6 adoption rate for a social network in that country= is 35.2%.

_______________________________________________
v6ops mailing list -- v6ops@ietf.org
To unsubscribe send an email to v6ops-leave@ietf.org
_______________________________________________
v6ops mailing list -- v6ops@ietf.org
To unsubscribe send an email to v6ops-leave@ietf.org

--=_98f739d3-bf1b-4b6f-b417-9026a918702b--