[Witarea] Re: How to make an elegant IPv4 outage
Erik Nygren <[email protected]> Mon, 6 Jul 2026 18:03:17 -0400
| Newsgroups | gmane.ietf.tsv-area,gmane.ietf.general,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CAKC-DJjeMJt7hkKQZWCABwvjxbZU0c6wtUZnbMg4OORBXecsww@mail.gmail.com> |
--===============5368266439643237270==
Content-Type: multipart/alternative; boundary="000000000000d2e0740655f87138"
--000000000000d2e0740655f87138
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Following up on this, I've written up a -00 draft covering this idea:
"Indicating IPv6-only SVCB Endpoints and IPv4 Deprecation in the DNS"
https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-ipv6only-indicator=
-00
(I'll bring it first to dnsop but will discuss with folks in Vienna if that
is the right place
for it or if it wants to instead come via v6ops, 6man, happy, or just
dispatch.)
Erik
On Fri, Jun 12, 2026 at 11:47=E2=80=AFAM Erik Nygren <[email protected]>=
wrote:
> It's because we now have SVCB (and HTTPS) RRS that clients are picking up
> support for in an extensible manner.
> It's not a solution to everything, but the SVCB SvcParams were intended
> for this sort of use-case. It is the person who controls
> the authoritative record who also wants to be able to signal this (eg, an=
d
> they are also going to be the same actor to remove the DNS A record
> in the end to remove IPv4 support), so it is a logical place to put it.
>
> We've talked about this a little in HAPPY -- that WG might be a place for
> a drafr on this.
>
> Erik
>
>
> On Fri, Jun 12, 2026 at 11:36=E2=80=AFAM Franck Martin <franck@peachymang=
o.org>
> wrote:
>
>> I tend not to like DNS for those sorts of things because:
>> 1) you don=E2=80=99t control well the propagation and caching
>> 2) you don=E2=80=99t control the blast radius (unless you set up the red=
undancies
>> zones in your dns
>> 3) DNS feature creep
>> 4) K8S made it even more complicated because everything is now very
>> dynamic
>> 5) there are so many DNS clients/libraries (glibc, java, nscd,..) and DN=
S
>> code in applications is seldom smart/controlled.
>>
>> I brushed some of those points in the ID. May be they need more
>> clarification?
>>
>> That being said, I think we could have several mechanism, some involving
>> DNS, it gives options, and diversity is good. It could be implemented in
>> glibc to reach a maximum of clients.
>>
>> May be you would want to write an ID to better clarify your thoughts?
>>
>> Franck
>>
>> Toute connaissance est une r=C3=A9ponse =C3=A0 une question.
>>
>> On Jun 12, 2026, at 07:19, Erik Nygren <[email protected]> wrote:
>>
>> =EF=BB=BF
>> + v6ops
>>
>> On the topic of the original draft (
>> 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 pa=
th
>> towards phasing out IPv4 in various environments. (Some of the work Jor=
di
>> and v6ops are doing on trying to define "IPv6-only" is a good start in t=
his
>> 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.
>>
>> 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=
.
>> Clients could achive something similar to your proposal by warning if th=
e
>> 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 indicate=
s
>> that it is IPv6-only followed by a lower priority one which is
>> dualstacked. They could later drop the dualstacked endpoint. I think t=
his
>> 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=E2=80=AFPM Franck Martin <franck@peachymango=
.org>
>> 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/
>>>
>>> I have been building this site: 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 kno=
w 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 f=
or
>>> 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/
>>> I don't remember seeing anything resulting from that discussion. Havin=
g a
>>> draft is, relatively, better than the usual email discussion. The draf=
t
>>> 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.. 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 their=
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 federa=
l IP-enabled
>>> assets in IPv6-only environments by FY 2025, with strategic intent to p=
hase
>>> 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-expl=
ain=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 need to do that again.
>>>
>>> And I agree that those memos come and go=E2=80=A6 Why? Because it is no=
t
>>> 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-=
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
>>>
>>> - 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 no=
t 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
>>> - Orange is considering IPv6-only:
>>> https://www.youtube.com/watch?v=3DahlY1vwM8qE
>>> - 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/
>>> - 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 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 infrastructur=
e
>>> outage, and easier and faster to rollback. =E2=80=9CYou can=E2=80=99t f=
ix what you don=E2=80=99t
>>> measure=E2=80=9D, if you can differentiate an IPv4 outage from any othe=
r 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 sourc=
e software like gRPC
>>> and Rest.Li to make life easier in enterprises, therefore impacting oth=
er
>>> 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 be=
tter
>>> 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-fallbac=
k/
>>> ,
>>> https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selectio=
n-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%=
.
>>>
>>>
>>> --
>> Witarea mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
>>
--000000000000d2e0740655f87138
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s=
ans-serif">Following up on this, I've written up a -00 draft covering t=
his idea:</div><div class=3D"gmail_default" style=3D"font-family:tahoma,san=
s-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma=
,sans-serif">=C2=A0 =C2=A0"Indicating IPv6-only SVCB Endpoints and IPv=
4 Deprecation in the DNS"<br><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:tahoma,sans-serif">=C2=A0 =C2=A0<a href=3D"https://datat=
racker.ietf.org/doc/html/draft-nygren-dnsop-ipv6only-indicator-00">https://=
datatracker.ietf.org/doc/html/draft-nygren-dnsop-ipv6only-indicator-00</a><=
/div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><=
br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-seri=
f">(I'll bring it first to dnsop but will discuss with folks in Vienna =
if that is the right place=C2=A0</div><div class=3D"gmail_default" style=3D=
"font-family:tahoma,sans-serif">for it or if it wants to instead come via v=
6ops, 6man, happy, or just dispatch.)</div><div class=3D"gmail_default" sty=
le=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"gmail_default"=
style=3D"font-family:tahoma,sans-serif">=C2=A0 =C2=A0 =C2=A0 Erik</div><di=
v class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></div=
></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Jun 12, 2026 at 11:47=E2=80=AFAM Erik Nygren=
<<a href=3D"mailto:erik%[email protected]">[email protected]</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-seri=
f">It's because we now have SVCB (and HTTPS) RRS that clients are picki=
ng up support for in an extensible manner.</div><div class=3D"gmail_default=
" style=3D"font-family:tahoma,sans-serif">It's not a solution to everyt=
hing, but the SVCB SvcParams were intended for this sort of use-case.=C2=A0=
It is the person who controls</div><div class=3D"gmail_default" style=3D"f=
ont-family:tahoma,sans-serif">the authoritative record who also wants to be=
able to signal this (eg, and they are also going to be the same actor to r=
emove the DNS A record</div><div class=3D"gmail_default" style=3D"font-fami=
ly:tahoma,sans-serif">in the end to remove IPv4 support), so it is a logica=
l place to put it.</div><div class=3D"gmail_default" style=3D"font-family:t=
ahoma,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:tahoma,sans-serif">We've talked about this a little in HAPPY -- that=
WG might be a place for a drafr on this.</div><div class=3D"gmail_default"=
style=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:tahoma,sans-serif">=C2=A0 =C2=A0 Erik</div><div c=
lass=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
Fri, Jun 12, 2026 at 11:36=E2=80=AFAM Franck Martin <<a href=3D"mailto:=
[email protected]" target=3D"_blank">[email protected]</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"auto">I tend not to like DNS for those sorts of things because:<div>1) you=
don=E2=80=99t control well the propagation and caching</div><div>2) you do=
n=E2=80=99t control the blast radius (unless you set up the redundancies zo=
nes in your dns</div><div>3) DNS feature creep</div><div>4) K8S made it eve=
n more complicated because everything is now very dynamic</div><div>5) ther=
e are so many DNS clients/libraries (glibc, java, nscd,..) and DNS code in =
applications is seldom smart/controlled.</div><div><br></div><div>I brushed=
some of those points in the ID. May be they need more clarification?</div>=
<div><br></div><div>That being said, I think we could have several mechanis=
m, some involving DNS, it gives options, and diversity is good. It could be=
implemented in glibc to reach a maximum of clients.</div><div><br></div><d=
iv>May be you would want to write an ID to better clarify your thoughts?</d=
iv><div><br></div><div>Franck</div><div>=C2=A0</div><div><div dir=3D"ltr">T=
oute connaissance est une r=C3=A9ponse =C3=A0 une question.</div><div dir=
=3D"ltr"><br><blockquote type=3D"cite">On Jun 12, 2026, at 07:19, Erik Nygr=
en <<a href=3D"mailto:erik%[email protected]" target=3D"_blank">erik+iet=
[email protected]</a>> wrote:<br><br></blockquote></div><blockquote type=3D"c=
ite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div class=3D"gmail_default=
" style=3D"font-family:tahoma,sans-serif">+ v6ops</div><div class=3D"gmail_=
default" style=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:tahoma,sans-serif">On the topic of the or=
iginal draft (<a href=3D"https://datatracker.ietf.org/doc/html/draft-martin=
-retry-over-ipv6-01" target=3D"_blank">https://datatracker.ietf.org/doc/htm=
l/draft-martin-retry-over-ipv6-01</a>):</div><div class=3D"gmail_default" s=
tyle=3D"font-family:tahoma,sans-serif"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:tahoma,sans-serif">1) I wonder if this is pointing =
towards a desire to either=C2=A0start sunset4 back up again, or to charter =
work within some existing WG (v6ops, 6man, others?) to pick back up on wher=
e sunset4 left off, specifically looking for technology solutions and opera=
tional recommendations to provide a path towards phasing out IPv4 in variou=
s environments.=C2=A0 (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 applicatio=
ns, building infrastructure) where IPv6-only is now viable.</div><div class=
=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">2) For your =
specific proposal, I wonder if DNS signaling might be a less invasive way t=
o do this?=C2=A0 In particular, we might want to define a SVCB SvcParam for=
"ipv6only" to indicate=C2=A0that an endpoint has no IPv4 support=
.=C2=A0 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.=C2=A0=C2=A0For the specific example of the Cz=
echia 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.=C2=A0 They could later drop the dualstacked endpoint.=C2=A0=
I think this could achieve the same results as your retry-over-ipv6 draft =
with less complexity and with less need for fallback.</div><div class=3D"gm=
ail_default" style=3D"font-family:tahoma,sans-serif"><br></div><div class=
=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">Erik</div><div c=
lass=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">=
<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Wed, Jun 3, 2026 at 5:29=E2=80=AFPM Franck Martin <<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div><div>Moving to Witarea, but keeping ietf in the loop for the moment.</=
div><div><br></div>Hi Surya,<div><br></div><div><div>Many thanks for those =
great points.</div><div><br><blockquote type=3D"cite"><div>On Jun 3, 2026, =
at 13:00, S Moonesamy <<a href=3D"mailto:sm%[email protected]" target=
=3D"_blank">[email protected]</a>> wrote:</div><br><div><div>Hi Franc=
k,<br><br>[Cc to witarea@]<br><br>At 11:32 AM 03-06-2026, Franck Martin wro=
te:<br><blockquote type=3D"cite">Today I submitted this Internet Draft (I-D=
) to the IETF<br><a href=3D"https://datatracker.ietf.org/doc/draft-martin-r=
etry-over-ipv6/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-m=
artin-retry-over-ipv6/</a><br><br>I have been building this site: <a href=
=3D"http://pacific.ipv6forum.com" target=3D"_blank">pacific.ipv6forum.com</=
a> and I have been wondering, 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 I=
Pv4 on government sites on 6/6/2032, 6 years from now.<br><br>I also recall=
(from recent experience) that it is relatively easy to reach >90% of IP=
v6 connections to an internal network (think datacenter), but the remaining=
last % are difficult to identify (or discard) because services may misbeha=
ve 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><br>In an enterpris=
e environment, micro-services are made redundant, there are multiple IPs an=
d have fallback mechanisms when they encounter a 5xx error on one endpoint.=
<br><br>So, I started to work on this Internet Draft. It is ready for the f=
irst 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 imp=
lemented on enough clients (and browsers), we will be just in time for doin=
g enough IPv4 outages on 6/6 to meet the 6/6/2032 deadline.<br></blockquote=
><br>There is a recent thread about IPv6 at <a href=3D"https://mailarchive.=
ietf.org/arch/msg/ipv6/BxSOgbF34xbBcijtxf85Pfnb5tc/" target=3D"_blank">http=
s://mailarchive.ietf.org/arch/msg/ipv6/BxSOgbF34xbBcijtxf85Pfnb5tc/</a> I d=
on't remember seeing anything resulting from that discussion.=C2=A0 Hav=
ing a draft is, relatively, better than the usual email discussion.=C2=A0 T=
he draft falls under the WIT Area and v6ops (which is in another IETF Area)=
.<br></div></div></blockquote><div><br></div><div>I quickly read the thread=
, and also asked for a summary. I agree with many points like : some mobile=
s 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 <a href=3D"https://pacific.ipv6forum.com=
" target=3D"_blank">https://pacific.ipv6forum.com</a>.. but yes the frontie=
r is Entreprise adoption. I have some experience here that I=E2=80=99m tryi=
ng to share.</div><br><blockquote type=3D"cite"><div><div><br>Section 1.1 o=
f the draft states that "Governments are also publishing fixed IPv4 en=
d dates" and lists one example [1].=C2=A0 Are there any other governme=
nts which have a fixed end date?<br></div></div></blockquote><div><br></div=
><div>I am not aware of other governments that have published an equally sp=
ecific =E2=80=9CIPv4 service ends on <date>=E2=80=9D policy for their=
public services. Several others publish IPv6 transition *milestones* rathe=
r 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 s=
trategic intent to phase out IPv4): <a href=3D"https://www.whitehouse.gov/w=
p-content/uploads/2020/11/M-21-07.pdf" target=3D"_blank">https://www.whiteh=
ouse.gov/wp-content/uploads/2020/11/M-21-07.pdf</a></div><div><br></div><di=
v>The Netherlands and others have long-standing IPv6 =E2=80=9Cuse-or-explai=
n=E2=80=9D or adoption targets, but not, to my knowledge, a single publishe=
d IPv4 end date comparable to the Czech case.</div><div><br></div><div>Ther=
e was also a memo from the State of Washington going in the same direction=
=E2=80=A6</div><div><br></div><div>I used to track all those=E2=80=A6 looks=
like I need to do that again.</div><div><br></div><div>And I agree that th=
ose memos come and go=E2=80=A6 Why? Because it is not trivial, we (IETF?) o=
ught to make it easier.</div><div>=C2=A0</div><blockquote type=3D"cite"><di=
v><div><br>Section 3 of the draft states that "Many operators plan to =
remove or disable IPv4 while retaining IPv6 service." =C2=A0Are those =
plans available on the operators' websites?<br></div></div></blockquote=
><div><br></div>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"</div><div><br></div>=
<div>That being said:=C2=A0</div><div><ul><li>Meta is IPv6-only in their da=
ta centers:=C2=A0<a href=3D"https://engineering.fb.com/2017/01/17/productio=
n-engineering/legacy-support-on-ipv6-only-infra/" target=3D"_blank">https:/=
/engineering.fb.com/2017/01/17/production-engineering/legacy-support-on-ipv=
6-only-infra/</a>=C2=A0</li><li>Google Cloud has guidance for IPv6-only:=C2=
=A0<a href=3D"https://cloud.google.com/blog/products/networking/connect-ipv=
6-only-workloads-to-ipv4-with-dns64-and-nat64" target=3D"_blank">https://cl=
oud.google.com/blog/products/networking/connect-ipv6-only-workloads-to-ipv4=
-with-dns64-and-nat64</a>=C2=A0</li><li>All the could providers are moving =
to support IPv6 (because for instance K8S bring undue complexity when you u=
se 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 shee=
t of companies?)</li><li>Cisco has an IPv6-only building:=C2=A0<a href=3D"h=
ttps://blogs.cisco.com/networking/an-ipv6-campus-of-the-future" target=3D"_=
blank">https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future</a><=
/li><li>Orange is considering IPv6-only:=C2=A0<a href=3D"https://www.youtub=
e.com/watch?v=3DahlY1vwM8qE" target=3D"_blank">https://www.youtube.com/watc=
h?v=3DahlY1vwM8qE</a></li><li>Microsoft has IPv6-only deployments (I know t=
hat in Azure this is way more complicated):=C2=A0<a href=3D"https://labs.ri=
pe.net/author/mirjam/ipv6-only-at-microsoft/" target=3D"_blank">https://lab=
s.ripe.net/author/mirjam/ipv6-only-at-microsoft/</a></li><li>LinkedIn is mo=
ving to Dual Stack and IPv6-only in their Datacenters. I may point you to t=
he links in this post:=C2=A0<a href=3D"https://www.patreon.com/posts/ipv6-i=
n-lessons-159595711" target=3D"_blank">https://www.patreon.com/posts/ipv6-i=
n-lessons-159595711</a> where I share my experience with IPv6.</li></ul><di=
v><br></div><div>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 infra=
structure 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 f=
ix.=C2=A0</div><div><br></div><div>I=E2=80=99m not expecting the web browse=
rs 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 en=
terprises, which will lead to make it easier on the public Internet...</div=
><div><br></div><div>So thanks for all those valid points, I=E2=80=99ll fig=
ure out how to better answer them in version -01.</div><div><br></div><div>=
I tried to address the same with email, a while back. See those expired ID:=
=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to=
-ipv4-fallback/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-m=
artin-smtp-ipv6-to-ipv4-fallback/</a>,=C2=A0<a href=3D"https://datatracker.=
ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6/" target=3D"=
_blank">https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-sele=
ction-ipv4-ipv6/</a>. I hope this ID has a bit more chances.</div><div><br>=
</div><div>Franck</div><div>PS: if any has more references of mandate or wa=
nnabe mandates, please let me know.</div></div><div><br><blockquote type=3D=
"cite"><div><div><br>Regards,<br>S. Moonesamy<br><br>1. The IPv6 adoption r=
ate for a social network in that country is 35.2%.</div></div></blockquote>=
</div><br></div></div></blockquote></div>
<span>-- </span><br><span>Witarea mailing list -- <a href=3D"mailto:witarea=
@ietf.org" target=3D"_blank">[email protected]</a></span><br><span>To unsubs=
cribe send an email to <a href=3D"mailto:[email protected]" target=3D"=
_blank">[email protected]</a></span><br></div></blockquote></div></div=
></blockquote></div>
</blockquote></div>
--000000000000d2e0740655f87138--
--===============5368266439643237270==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
LS0gCldpdGFyZWEgbWFpbGluZyBsaXN0IC0tIHdpdGFyZWFAaWV0Zi5vcmcKVG8gdW5zdWJzY3Jp
YmUgc2VuZCBhbiBlbWFpbCB0byB3aXRhcmVhLWxlYXZlQGlldGYub3JnCg==
--===============5368266439643237270==--