[Witarea] Re: [v6ops] Re: How to make an elegant IPv4 outage
Daryll Swer <[email protected]> Sat, 6 Jun 2026 19:13:02 +0530
| Newsgroups | gmane.ietf.tsv-area,gmane.ietf.general,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CACyFTPE7KoDmAV5=W5eE1HB02t6G_5dSvwBYUbOOwqZCjpAY8g@mail.gmail.com> |
--===============0878965783331144731== Content-Type: multipart/alternative; boundary="000000000000f21be8065395f6ca" --000000000000f21be8065395f6ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IIRC, there was some discussion on v6ops in the past about K8s + NAT-less IPv6. In my idealised thought process: If we're using hypervisors/VMs, then: IPv6 prefixes are routed from the leaf switch to the server node (BGP-to-the-host). If VMs exist, the hypervisor's routing table then has, say, a /56 routed per-VM where the next-hop is the VM's link-local address. This ensures each VM has a /56 routed fully to it, and the end-user/customer can use multiple /64s as needed. For example, they could have a container/pod that further receives a routed /64 for WireGuard endpoints or peers. If it's a VM-less model where everything is just pods/containers, then: Say a /52 is routed to each physical server from the leaf switch; from there you can slice it into /64s per container/pod or as needed based on applications. Perhaps we could optimise further. If I have pods for example.com and want my AAAA record to never change *without* using *NAT66/NPTv6* on my infrastructure, we might want two /52s: one /52 for inter-pod and inter-server node communications and the other /52 for anycasting publicly exposed pods across all worker node instances, ensuring my AAAA records never change. Of course there's more involved with statefulness/failover, but that's probably outside the scope of v6ops. I'm happy to hear better ideas/solutions if there are any, as long as we achieve *NAT-less IPv6* in K8s. This would also allow the users to run protocols beyond TCP/UDP (such as GRE, SCTP or IPSec) natively without relying on NAT traversal mechanisms/hacks. *--* Best Regards Daryll Swer Website: daryllswer.com <https://l.shortlink.es/l/cc795e71f3c96b7e91e300c5f495b19f9dee016b?u=3D2153= 471> On Fri, 5 Jun 2026 at 13:49, Xipengxiao <xipengxiao=3D [email protected]> 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 <[email protected]> > Sent: Thursday, June 4, 2026 1:51 AM > To: Brian E Carpenter <[email protected]> > Cc: S Moonesamy <[email protected]>; witarea <[email protected]>; ietf = < > [email protected]>; [email protected] > 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 Dat= a > Center and Deploying IPv6 in the Enterprise. I have some experience with > this having done that at LinkedIn and been very close to an IPv6-only > deployment. 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 ha= ppy 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 <[email protected]= m> > wrote: > > > > Franck, > > > > You definitely need to keep [email protected] aware of this. > > > > I assume you are aware of > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > <https://l.shortlink.es/l/68ff76b159f24b8f9856723580a5b38b9db366ac?u=3D21= 53471> > 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 <[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://l.shortlink.es/l/d2351750ec19ecdee341a147237926229ec23971?u=3D21= 53471> > >>>> > >>>> I have been building this site: pacific.ipv6forum.com > <https://l.shortlink.es/l/a0a3eeb92f076b0db35049148851703dbc73ba34?u=3D21= 53471> > 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://l.shortlink.es/l/74c7fa8274f6ee185bcf5919a10f5f588a33a58c?u=3D21= 53471> > 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,=E2=80= =A6), 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://l.shortlink.es/l/ad99bf450f0286341131f2f33fff89006401ea1b?u=3D21= 53471> > <https://pacific.ipv6forum.com > <https://l.shortlink.es/l/c741d231d5eef3006240931b88614ab1e04e3127?u=3D21= 53471>>.. > but yes the 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 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 =E2=80=9CIPv4 service ends on <date>=E2=80=9D policy for thei= r public > >> services. Several others publish IPv6 transition *milestones* rather > >> 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, with > >> strategic intent to phase out IPv4): > >> https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf > <https://l.shortlink.es/l/ff416e69eaca025edecef67a37c2acb7edfd7369?u=3D21= 53471> > >> The Netherlands and others have long-standing IPv6 =E2=80=9Cuse-or-exp= lain=E2=80=9D 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=E2=80=A6 I used to track all those=E2=80=A6 looks like I nee= d to do that > again. > >> And I agree that those memos come and go=E2=80=A6 Why? Because it is n= ot > 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 =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 > <https://l.shortlink.es/l/cb9427357feddb933e96cabd27377204a34076fe?u=3D21= 53471> > >> upport-on-ipv6-only-infra/ > >> <https://engineering.fb.com/2017/01/17/production-engineering/legacy- > <https://l.shortlink.es/l/96223337e9a7c94e0aa2b25d8bb633759edfd671?u=3D21= 53471> > >> support-on-ipv6-only-infra/> > >> * Google Cloud has guidance for IPv6-only: > >> https://cloud.google.com/blog/products/networking/connect-ipv6-only-w > <https://l.shortlink.es/l/80b09af7fd8769246e546aac564579307e562ab8?u=3D21= 53471> > >> orkloads-to-ipv4-with-dns64-and-nat64 > >> <https://cloud.google.com/blog/products/networking/connect-ipv6-only- > <https://l.shortlink.es/l/c1c6c404c2124d733236fefb1fb6bb4711db4f8e?u=3D21= 53471> > >> 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=E2=80=99m 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://l.shortlink.es/l/3497a778e992cc66f3933daed527f153839b166d?u=3D21= 53471> > >> <https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future > <https://l.shortlink.es/l/4211dd46eadd235d71c37765a9ca9184c432570f?u=3D21= 53471> > > > >> * Orange is considering IPv6-only: > >> https://www.youtube.com/watch?v=3DahlY1vwM8qE > <https://l.shortlink.es/l/10a6451a14af8e1a2c9e153259d679123742988e?u=3D21= 53471> > >> <https://www.youtube.com/watch?v=3DahlY1vwM8qE > <https://l.shortlink.es/l/dc4579af66514ec386f43f40194491c6b1ff2512?u=3D21= 53471> > > > >> * 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://l.shortlink.es/l/1f389e1484e9fc6721ffb8cd8664d279554d52ce?u=3D21= 53471> > >> <https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/ > <https://l.shortlink.es/l/35a0c5085cecbf9284e9d63784e692b0b5005f00?u=3D21= 53471> > > > >> * 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://l.shortlink.es/l/3bffb5e0ee2c0fb8cb43302d0274e46e0efcc048?u=3D21= 53471> > 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. =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 fast,= but I > think we can have =E2=80=9Cfaster=E2=80=9D 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=E2=80=99ll figure out how to b= etter > answer them in version -01. > >> I tried to address the same with email, a while back. See those expire= d > ID: > https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/ > <https://l.shortlink.es/l/3e238440d9669c831fbd157bc06ae9084166b66f?u=3D21= 53471> > <https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback= / > <https://l.shortlink.es/l/2e41943e2fba646b2527f26a559ac786b29b2465?u=3D21= 53471>>, > > https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-= ipv4-ipv6/ > <https://l.shortlink.es/l/13fe90cc5d186f4a4049deb976ca8d2a510f9240?u=3D21= 53471> > < > https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-= ipv4-ipv6/ > <https://l.shortlink.es/l/84eb06c4d3cb622d197262b0c20e66679eda2b56?u=3D21= 53471>>. > 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] > _______________________________________________ > v6ops mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000f21be8065395f6ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div>IIRC, there was some discussion on v= 6ops in the past about K8s=C2=A0+ NAT-less IPv6.</div><div><br></div><div>I= n my idealised thought process:</div><div>If we're using hypervisors/VM= s, then:</div><div>IPv6 prefixes are routed from the leaf switch to the ser= ver node (BGP-to-the-host). If VMs exist, the hypervisor's routing tabl= e then has, say, a /56 routed per-VM where the next-hop is the VM's lin= k-local address. This ensures each VM has a /56 routed fully to it, and the= end-user/customer can use multiple /64s as needed. For example, they could= have a container/pod that further receives a routed /64 for WireGuard endp= oints or peers.</div><div><br></div><div>If it's a VM-less model where = everything is just pods/containers, then:</div><div>Say a /52 is routed to = each physical server from the leaf switch; from there you can slice it into= /64s per container/pod or as needed based on applications.</div><div><br><= /div><div>Perhaps we could optimise further. If I have pods for <a href=3D"= http://example.com">example.com</a> and want my AAAA record to never change= <b>without</b> using <b>NAT66/NPTv6</b> on my infrastructure, we might wan= t two /52s: one /52 for inter-pod and inter-server node communications and = the other /52 for anycasting publicly exposed pods across all worker node i= nstances, ensuring my AAAA records never change.</div><div><br></div><div>O= f course there's more involved with statefulness/failover, but that'= ;s probably outside the scope of v6ops.</div><div><br></div><div>I'm ha= ppy to hear better ideas/solutions if there are any, as long as we achieve = <b>NAT-less IPv6</b> in K8s. This would also allow the users to run protoco= ls beyond TCP/UDP (such as GRE, SCTP or IPSec) natively without relying on = NAT traversal mechanisms/hacks.</div><div><div dir=3D"ltr" class=3D"gmail_s= ignature"><div dir=3D"ltr"><font color=3D"#000000" face=3D"arial, sans-seri= f"><br><b>--</b><br></font><div><font color=3D"#000000" face=3D"arial, sans= -serif">Best Regards</font></div><div><font color=3D"#000000" face=3D"arial= , sans-serif">Daryll Swer</font></div><div><font color=3D"#000000" face=3D"= arial, sans-serif">Website: <a href=3D"https://l.shortlink.es/l/cc795e71f3c= 96b7e91e300c5f495b19f9dee016b?u=3D2153471" target=3D"_blank">daryllswer.com= </a></font></div></div></div></div><br></div><br><img width=3D"0" height=3D= "0" class=3D"mailtrack-img" alt=3D"" style=3D"display:flex" src=3D"https://= mailtrack.io/trace/mail/5eea1a7ee51ff14bd4c9e8a51fbc84566ce74945.png?u=3D21= 53471"><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Fri, 5 Jun 2026 at 13:49, Xipengxiao <xipengxiao= =3D<a href=3D"mailto:[email protected]">[email protected]= rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= ">Hi Franck,<br> <br> You are very welcome to take the lead on "Deploying IPv6 in the Data C= enter/Enterprises".=C2=A0 We look forward to your drafts.<br> <br> XiPeng <br> <br> -----Original Message-----<br> From: Franck Martin <<a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>> <br> Sent: Thursday, June 4, 2026 1:51 AM<br> To: Brian E Carpenter <<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>><br> Cc: S Moonesamy <<a href=3D"mailto:sm%[email protected]" target=3D"_bl= ank">[email protected]</a>>; witarea <<a href=3D"mailto:witarea@ie= tf.org" target=3D"_blank">[email protected]</a>>; ietf <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>>; <a href=3D"mail= to:[email protected]" target=3D"_blank">[email protected]</a><br> Subject: [v6ops] Re: How to make an elegant IPv4 outage<br> <br> Adding v6ops to the list of Cc<br> <br> Brian,<br> <br> Getting myself up to date with the v6ops.<br> <br> 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.= <br> <br> 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.<br> <br> Franck<br> <br> > On Jun 3, 2026, at 15:34, Brian E Carpenter <<a href=3D"mailto:bria= [email protected]" target=3D"_blank">[email protected]</a>&= gt; wrote:<br> > <br> > Franck,<br> > <br> > You definitely need to keep <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a> aware of this.<br> > <br> > I assume you are aware of <a href=3D"https://l.shortlink.es/l/68ff76b1= 59f24b8f9856723580a5b38b9db366ac?u=3D2153471" rel=3D"noreferrer" target=3D"= _blank">https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/</a> a= nd other work in v6ops related to IPv6-only and IPv6-mostly.<br> > <br> > Regards/Ng=C4=81 mihi<br> >=C2=A0 =C2=A0Brian Carpenter<br> > <br> > On 04-Jun-26 09:29, Franck Martin wrote:<br> >> Moving to Witarea, but keeping ietf in the loop for the moment.<br= > >> Hi Surya,<br> >> Many thanks for those great points.<br> >>> On Jun 3, 2026, at 13:00, S Moonesamy <<a href=3D"mailto:sm= %[email protected]" target=3D"_blank">[email protected]</a>> wrote:= <br> >>> <br> >>> Hi Franck,<br> >>> <br> >>> [Cc to witarea@]<br> >>> <br> >>> At 11:32 AM 03-06-2026, Franck Martin wrote:<br> >>>> Today I submitted this Internet Draft (I-D) to the IETF <b= r> >>>> <a href=3D"https://l.shortlink.es/l/d2351750ec19ecdee341a1= 47237926229ec23971?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https:= //datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/</a><br> >>>> <br> >>>> I have been building this site: <a href=3D"https://l.short= link.es/l/a0a3eeb92f076b0db35049148851703dbc73ba34?u=3D2153471" rel=3D"nore= ferrer" target=3D"_blank">pacific.ipv6forum.com</a> and I have been wonderi= ng, how could I do an IPv4 outage on this site on 6/6?<br> >>>> <br> >>>> I have also seen that Czechoslovakia has mandated the end = of IPv4 on government sites on 6/6/2032, 6 years from now.<br> >>>> <br> >>>> 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 d= o IPv6.<br> >>>> <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.<br> >>>> <br> >>>> 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.<br> >>> <br> >>> There is a recent thread about IPv6 at <a href=3D"https://l.sh= ortlink.es/l/74c7fa8274f6ee185bcf5919a10f5f588a33a58c?u=3D2153471" rel=3D"n= oreferrer" target=3D"_blank">https://mailarchive.ietf.org/arch/msg/ipv6/BxS= OgbF34xbBcijtxf85Pfnb5tc/</a> I don't remember seeing anything resultin= g from that discussion.=C2=A0 Having a draft is, relatively, better than th= e usual email discussion.=C2=A0 The draft falls under the WIT Area and v6op= s (which is in another IETF Area).<br> >> 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 <a h= ref=3D"https://l.shortlink.es/l/ad99bf450f0286341131f2f33fff89006401ea1b?u= =3D2153471" rel=3D"noreferrer" target=3D"_blank">https://pacific.ipv6forum.= com</a> <<a href=3D"https://l.shortlink.es/l/c741d231d5eef3006240931b886= 14ab1e04e3127?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://pac= ific.ipv6forum.com</a>>.. but yes the frontier is Entreprise adoption. I= have some experience here that I=E2=80=99m trying to share.<br> >>> <br> >>> Section 1.1 of the draft states that "Governments are als= o publishing fixed IPv4 end dates" and lists one example [1].=C2=A0 Ar= e there any other governments which have a fixed end date?<br> >> I am not aware of other governments that have published an equally= <br> >> specific =E2=80=9CIPv4 service ends on <date>=E2=80=9D polic= y for their public <br> >> services. Several others publish IPv6 transition *milestones* rath= er <br> >> than a fixed IPv4 shutdown date =E2=80=94 for example, US OMB M-21= -07 (80% of <br> >> federal IP-enabled assets in IPv6-only environments by FY 2025, wi= th <br> >> strategic intent to phase out IPv4): <br> >> <a href=3D"https://l.shortlink.es/l/ff416e69eaca025edecef67a37c2ac= b7edfd7369?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://www.wh= itehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf</a><br> >> 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.<br> >> There was also a memo from the State of Washington going in the sa= me <br> >> direction=E2=80=A6 I used to track all those=E2=80=A6 looks like I= need to do that again.<br> >> 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.<br> >>> <br> >>> Section 3 of the draft states that "Many operators plan t= o remove or disable IPv4 while retaining IPv6 service."=C2=A0 Are thos= e plans available on the operators' websites?<br> >> 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"<br> >> That being said:<br> >>=C2=A0 * Meta is IPv6-only in their data centers: <br> >> <a href=3D"https://l.shortlink.es/l/cb9427357feddb933e96cabd273772= 04a34076fe?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://engine= ering.fb.com/2017/01/17/production-engineering/legacy-s</a><br> >> upport-on-ipv6-only-infra/ <br> >> <<a href=3D"https://l.shortlink.es/l/96223337e9a7c94e0aa2b25d8b= b633759edfd671?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://en= gineering.fb.com/2017/01/17/production-engineering/legacy-</a><br> >> support-on-ipv6-only-infra/><br> >>=C2=A0 * Google Cloud has guidance for IPv6-only: <br> >> <a href=3D"https://l.shortlink.es/l/80b09af7fd8769246e546aac564579= 307e562ab8?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://cloud.= google.com/blog/products/networking/connect-ipv6-only-w</a><br> >> orkloads-to-ipv4-with-dns64-and-nat64 <br> >> <<a href=3D"https://l.shortlink.es/l/c1c6c404c2124d733236fefb1f= b6bb4711db4f8e?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://cl= oud.google.com/blog/products/networking/connect-ipv6-only-</a><br> >> workloads-to-ipv4-with-dns64-and-nat64><br> >>=C2=A0 * All the could providers are moving to support IPv6 (becaus= e for <br> >> instance K8S bring undue complexity when you use NAT, also with th= e <br> >> explosion of AI agents, this will not be sustainable, I=E2=80=99m = not worry, <br> >> 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 = <br> >> companies?)<br> >>=C2=A0 * Cisco has an IPv6-only building: <br> >> <a href=3D"https://l.shortlink.es/l/3497a778e992cc66f3933daed527f1= 53839b166d?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://blogs.= cisco.com/networking/an-ipv6-campus-of-the-future</a> <br> >> <<a href=3D"https://l.shortlink.es/l/4211dd46eadd235d71c37765a9= ca9184c432570f?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://bl= ogs.cisco.com/networking/an-ipv6-campus-of-the-future</a>><br> >>=C2=A0 * Orange is considering IPv6-only: <br> >> <a href=3D"https://l.shortlink.es/l/10a6451a14af8e1a2c9e153259d679= 123742988e?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://www.yo= utube.com/watch?v=3DahlY1vwM8qE</a> <br> >> <<a href=3D"https://l.shortlink.es/l/dc4579af66514ec386f43f4019= 4491c6b1ff2512?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://ww= w.youtube.com/watch?v=3DahlY1vwM8qE</a>><br> >>=C2=A0 * Microsoft has IPv6-only deployments (I know that in Azure = this is <br> >> way more complicated): <br> >> <a href=3D"https://l.shortlink.es/l/1f389e1484e9fc6721ffb8cd8664d2= 79554d52ce?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://labs.r= ipe.net/author/mirjam/ipv6-only-at-microsoft/</a> <br> >> <<a href=3D"https://l.shortlink.es/l/35a0c5085cecbf9284e9d63784= e692b0b5005f00?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://la= bs.ripe.net/author/mirjam/ipv6-only-at-microsoft/</a>><br> >>=C2=A0 * LinkedIn is moving to Dual Stack and IPv6-only in their Da= tacenters. I may point you to the links in this post: <a href=3D"https://l.= shortlink.es/l/3bffb5e0ee2c0fb8cb43302d0274e46e0efcc048?u=3D2153471" rel=3D= "noreferrer" target=3D"_blank">https://www.patreon.com/posts/ipv6-in-lesson= s-159595711</a> where I share my experience with IPv6.<br> >> 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.<br> >> 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...<br> >> So thanks for all those valid points, I=E2=80=99ll figure out how = to better answer them in version -01.<br> >> I tried to address the same with email, a while back. See those ex= pired ID: <a href=3D"https://l.shortlink.es/l/3e238440d9669c831fbd157bc06ae= 9084166b66f?u=3D2153471" rel=3D"noreferrer" target=3D"_blank">https://datat= racker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/</a> <<a hre= f=3D"https://l.shortlink.es/l/2e41943e2fba646b2527f26a559ac786b29b2465?u=3D= 2153471" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/= doc/draft-martin-smtp-ipv6-to-ipv4-fallback/</a>>, <a href=3D"https://l.= shortlink.es/l/13fe90cc5d186f4a4049deb976ca8d2a510f9240?u=3D2153471" rel=3D= "noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/draft-marti= n-smtp-target-host-selection-ipv4-ipv6/</a> <<a href=3D"https://l.shortl= ink.es/l/84eb06c4d3cb622d197262b0c20e66679eda2b56?u=3D2153471" rel=3D"noref= errer" target=3D"_blank">https://datatracker.ietf.org/doc/draft-martin-smtp= -target-host-selection-ipv4-ipv6/</a>>. I hope this ID has a bit more ch= ances.<br> >> Franck<br> >> PS: if any has more references of mandate or wannabe mandates, ple= ase let me know.<br> >>> <br> >>> Regards,<br> >>> S. Moonesamy<br> >>> <br> >>> 1. The IPv6 adoption rate for a social network in that country= is 35.2%.<br> <br> _______________________________________________<br> v6ops mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">v= [email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a><br> _______________________________________________<br> v6ops mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">v= [email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a><br> </blockquote></div></div> --000000000000f21be8065395f6ca-- --===============0878965783331144731== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0gCldpdGFyZWEgbWFpbGluZyBsaXN0IC0tIHdpdGFyZWFAaWV0Zi5vcmcKVG8gdW5zdWJzY3Jp YmUgc2VuZCBhbiBlbWFpbCB0byB3aXRhcmVhLWxlYXZlQGlldGYub3JnCg== --===============0878965783331144731==--