IPv6 and CDN's

Job Snijders job at fastly.com
Fri Oct 22 15:13:09 UTC 2021


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 :-/


More information about the NANOG mailing list