This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Have we failed as IPv6 Working Group?
- Previous message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
- Next message (by thread): [ipv6-wg] [official] What Shall This WG Do
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Petr Baudis
pasky at pasky.ji.cz
Tue Oct 8 16:59:58 CEST 2019
Hi, there have been many great points made from the perspective of "edge / leaf networks" and end-user connectivity. An equally important is the serving side. One aspect often discussed are the availability of CDNs and major services. But another aspect are various SaaS and other non-infrastructure cloud deployments. Since I did XS26 20 years ago, I now found myself managing a growing set of cloud deployments on the SaaS side. And IPv6 is definitely not a first-class citizen, typically not configured by default, and often actually just unsupported. The current de-facto standard for modern deployments are Kubernetes clusters. And interestingly, I don't even have that clear an idea about how well it supports IPv6 given how completely irrelevant to our daily business life that is (even though I'm personally still subscribed e.g. to this mailing list). Apparently, K8s gained support for IPv6 just in the last year(!), but currently you have choice just between IPv4-only and IPv6-only and work on dualstack is still ongoing. Meanwhile, Docker+Kubernetes is *the* way to deploy cloud services everywhere right now, so that's a pretty tell-tale signal. And who knows what issues one will hit when at least the basic infrastructure is finally in place and can be enabled easily (or even becomes enabled by default). It's also not just about the technical capabilities, but also about the UX. Just replacing IPv4 with IPv6 in the addresses listed in the list of instances / pods / containers would have a huge influence on the mindset of the developers, but this by itself will need to overcome a huge friction. Also, entirely new major UX improvements will likely need to be developed, like having a DNS hostname autoconfiguration for every cluster unit so that you don't need to actually work with IP addresses manually anymore. So it's just not about using DNS for the fileserver (and every workstation) in your office LAN, but also about having one for each of the 1000 pods you have deployed in your microservice-oriented cluster in the cloud. Just wanted to add this perspective, from the cloud side - both the cloud providers, major cloud infrastructure frameworks and numerous other services still have ways to go to (A) support IPv6 at all, (B) support it without friction (esp. w/o endangering IPv4), (C) have first-class UX for IPv6 otherwise the mindset of users will be still IPv4-oriented. Kind regards, -- Petr Baudis, Rossum.ai Creating a world without manual data entry
- Previous message (by thread): [ipv6-wg] Have we failed as IPv6 Working Group?
- Next message (by thread): [ipv6-wg] [official] What Shall This WG Do
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]