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

[Daryll Swer <[e-mail]>]

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=2153471>


On Fri, 5 Jun 2026 at 13:49, Xipengxiao <xipengxiao=
[e-mail]> 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 <[e-mail]>
> Sent: Thursday, June 4, 2026 1:51 AM
> To: Brian E Carpenter <[e-mail]>
> Cc: S Moonesamy <[e-mail]>; witarea <[e-mail]>; ietf <
> [e-mail]>; [e-mail]
> 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
> 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’t see any lead for this besides the WG chair. I would be happy 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 <[e-mail]>
> wrote:
> >
> > Franck,
> >
> > You definitely need to keep [e-mail] 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=2153471>
> and other work in v6ops related to IPv6-only and IPv6-mostly.
> >
> > Regards/Ngā 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 <[e-mail]> 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=2153471>
> >>>>
> >>>> I have been building this site: pacific.ipv6forum.com
> <https://l.shortlink.es/l/a0a3eeb92f076b0db35049148851703dbc73ba34?u=2153471>
> 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=2153471>
> 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://l.shortlink.es/l/ad99bf450f0286341131f2f33fff89006401ea1b?u=2153471>
> <https://pacific.ipv6forum.com
> <https://l.shortlink.es/l/c741d231d5eef3006240931b88614ab1e04e3127?u=2153471>>..
> 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://l.shortlink.es/l/ff416e69eaca025edecef67a37c2acb7edfd7369?u=2153471>
> >> 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-s
> <https://l.shortlink.es/l/cb9427357feddb933e96cabd27377204a34076fe?u=2153471>
> >> upport-on-ipv6-only-infra/
> >> <https://engineering.fb.com/2017/01/17/production-engineering/legacy-
> <https://l.shortlink.es/l/96223337e9a7c94e0aa2b25d8bb633759edfd671?u=2153471>
> >> 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=2153471>
> >> orkloads-to-ipv4-with-dns64-and-nat64
> >> <https://cloud.google.com/blog/products/networking/connect-ipv6-only-
> <https://l.shortlink.es/l/c1c6c404c2124d733236fefb1fb6bb4711db4f8e?u=2153471>
> >> 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://l.shortlink.es/l/3497a778e992cc66f3933daed527f153839b166d?u=2153471>
> >> <https://blogs.cisco.com/networking/an-ipv6-campus-of-the-future
> <https://l.shortlink.es/l/4211dd46eadd235d71c37765a9ca9184c432570f?u=2153471>
> >
> >>  * Orange is considering IPv6-only:
> >> https://www.youtube.com/watch?v=ahlY1vwM8qE
> <https://l.shortlink.es/l/10a6451a14af8e1a2c9e153259d679123742988e?u=2153471>
> >> <https://www.youtube.com/watch?v=ahlY1vwM8qE
> <https://l.shortlink.es/l/dc4579af66514ec386f43f40194491c6b1ff2512?u=2153471>
> >
> >>  * 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=2153471>
> >> <https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/
> <https://l.shortlink.es/l/35a0c5085cecbf9284e9d63784e692b0b5005f00?u=2153471>
> >
> >>  * 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=2153471>
> 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://l.shortlink.es/l/3e238440d9669c831fbd157bc06ae9084166b66f?u=2153471>
> <https://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/
> <https://l.shortlink.es/l/2e41943e2fba646b2527f26a559ac786b29b2465?u=2153471>>,
>
> https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6/
> <https://l.shortlink.es/l/13fe90cc5d186f4a4049deb976ca8d2a510f9240?u=2153471>
> <
> https://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6/
> <https://l.shortlink.es/l/84eb06c4d3cb622d197262b0c20e66679eda2b56?u=2153471>>.
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>