Hi everyone, goedenmiddag Marco! On Fri, Oct 22, 2021 at 01:40:42PM +0200, Marco Davids via NANOG wrote:
We currently live in times where is actually fun to go IPv6-only. In my case, as in: running a FreeBSD kernel compiled without the IPv4-stack.
Indeed, this is fun experimentation. Shaking the (source code) trees through excercises like these is a valuable way to identify gaps.
It turns out that there underlying CDN's with domain names such as ‘l-msedge.net’ and ‘trafficmanager.net’ (Microsoft) or 'fastly.net', that reside on authoritative name servers that *only* have an IPv4 address.
As some observant readers noticed (hint: https://ip6.nl/#!deb.debian.org), Fastly is working hard with select customers and friends to support IPv6 for everyone.
I guess my question is simple: Why?
Are there good architectural reason for this? Or is it just something that is overlooked and forgotten about?
The universal deployment of IPv6 appears to be a multi-decennial multigenerational project. Allow me to shed some light on various aspects. One of the challenges faced by those wishing to deploy IPv6 (compared to IPv4) is how from a BGP Default-Free Zone perspective, IPv4 and IPv6 are not alike at all! The Internet's IPv6 routing topology is vastly different from the IPv4 topology. The above phenomenon is perfectly understandable following from the fact that IPv4 predates IPv6 - and IP networks grow as they grow. In a perfect world the IPv6 network would grow perfectly congruent alongside the global IPv4 network. In this perfect world indeed IPv6 can "just be enabled", and used whenever available! Unfortunately the reality of the situation is far more chaotic! For example if you look at PeeringDB's 'netixlan' table, large discrepancies between the number of absent IPv4 entries and absent IPv6 entries are visible: $ curl -s https://peeringdb.com/api/netixlan | jq '.' | fgrep -c '"ipaddr4": null' 1286 $ curl -s https://peeringdb.com/api/netixlan | jq '.' | fgrep -c '"ipaddr6": null' 8160
From the above it's implied that the density of the 'IPv4 mesh' is much higher than the density and diversity of the 'IPv6 mesh', simply because more operators present more IPv4 traffic-exchange opportunities to other operators - compared to IPv6. This has performance implications.
Another aspect that flabbergasts me anno 2021 is how there *still* are BGP peering disputes between (more than two) major global internet service providers in which IPv6 is 'held hostage' as part of slow commercial negotiations. Surely end-to-end IPv6 connectivity should be a priority? Anyway, back to your question: content delivery networks who leverage all possible technical knobs and buttons to increase performance (such as BGP traffic engineering) might be reluctant to offer IPv6 services "as if they are the same as IPv4". More study is required. Tl;DR - work in progress! :-) Kind regards, Job ps. Have you tried running an IPv6-only RPKI validator? About 1.4% of RPKI VRPs appears to be 'missing' in IPv6-only environments :-/