Mailing List Archive

IPv6 and CDN's
Hi!

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.

A few years back doing such thing was mostly disappointing, but nowadays
is actually quite doable and entertaining.

So, the other day I decided to take this experiment to the next level by
disconnecting my local resolver from IPv4 as well.

Then things started to break. LinkedIn, Bing, Openstreetmap... Although
they all work great on IPv6-only, now they no longer did.

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.

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?

I would love to find out!

Thank you.

--
Marco

This is also fun by the way. Look at that nice banner on
https://clintonwhitehouse2.archives.gov/ :-)
Re: IPv6 and CDN's [ In reply to ]
Marco Davids via NANOG <nanog@nanog.org> writes:

> 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.

Fastly does have IPv6 enabled authoritative DNS server but it looks like
it's not the default.

I ran into this some time ago with deb.debian.org on an IPv6 only Debian
VM with a locally installed resolver. I opened a ticket which was closed
in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296

After some ranting and shouting it now works but a couple of days
ago I ran in the same problem while trying to install something via
pip. fles.pythonhosted.org is also using fastly.

> I guess my question is simple: Why?

I'm asking myself the same question.

> Are there good architectural reason for this? Or is it just something
> that is overlooked and forgotten about?

I don't think it was overlooked or forgotten. More along

"We have always done it this way", "We had problems enabling IPv6 (ages
ago)" or something else you can find on https://ipv6excuses.com/.

Jens
--
----------------------------------------------------------------------------
| Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@quux.de | --------------- |
----------------------------------------------------------------------------
Re: IPv6 and CDN's [ In reply to ]
Hi Jens,

Op 22-10-21 om 14:03 schreef Jens Link:

> I ran into this some time ago with deb.debian.org on an IPv6 only Debian
> VM with a locally installed resolver. I opened a ticket which was closed
> in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296

Just for the record; your issue is slightly different:

You wrote:

"deb.debian.org is a CNAME for debian.map.fastly.net. There are no AAAA
records for fastly.net so any DNS querys from an IPv6 only resolver will
not work."

At the moment debian.map.fastly.net has an AAAA-record though.

The thing is; the authoritative name servers of fastly.net are only
willing to hand out that AAAA-record via IPv4. So it still doesn't work
with the (locally installed) IPv6-only resolver ;-)

Cheers,

--
Marco
Re: IPv6 and CDN's [ In reply to ]
On 10/22/21 14:03, Jens Link wrote:

> I don't think it was overlooked or forgotten. More along
>
> "We have always done it this way", "We had problems enabling IPv6 (ages
> ago)" or something else you can find on https://ipv6excuses.com/.

I think it's a combination of both... they tried back in the day, it
broke, and they "parked" it for later.

When Marketing and The World were happy to see that
www.insert-favorite-content-url-here.com had AAAA and IPv6 PTR records,
who cared whether boring, little-known FQDN's were remembered or not.

And then, all the engineers moved on to some other gig, where they did
better because, why not?

Mark.
Re: IPv6 and CDN's [ In reply to ]
On second thoughts...

I seem to have been confused by the 'no AAAA records for fastly.net' (as
a DNS-purist: that should have said "ns[1234].fastly.net" instead, to
make it relevant). ;-)

>> I ran into this some time ago with deb.debian.org

Right.

So please ignore:

> Just for the record; your issue is slightly different:
>
> You wrote:
>
> "deb.debian.org is a CNAME for debian.map.fastly.net. There are no AAAA
> records for fastly.net so any DNS querys from an IPv6 only resolver will
> not work."


--
Marco
Re: IPv6 and CDN's [ In reply to ]
Hello,

client side IPv6-only is one thing, but IPv6-only recursive DNS
resolution is probably so niche that content providers and CDN's do
not particularly care at this point in time.

On the other hand, there is probably no good reason to run
authoritative DNS servers without IPv6 connectivity.


Lukas
Re: IPv6 and CDN's [ In reply to ]
On Fri, 22 Oct 2021, 13:03 Jens Link, <lists@quux.de> wrote:

> I ran into this some time ago with deb.debian.org on an IPv6 only Debian
> VM with a locally installed resolver. I opened a ticket which was closed
> in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296
>
> After some ranting and shouting it now works
>

I'm going to post the relevant message here:

> Sometimes I wonder why I report bugs..
>
> But your answer was the answer I was expecting. Thanks for noting.
>
> So I can summarize this as "The Debian Project doesn't care if IPv6 is
working"?

Jens, you went into that ticket looking for a fight, in a place staffed by
largely unpaid volunteers, choosing to belittle their efforts and then
attempting to shame them into action.

You even chose to mark the bug severity higher than the default, despite
you having chosen that mirror for your install.
https://www.debian.org/Bugs/Developer#severities

Marco explained to you that the mirror network has plenty of selections to
make, but you choose to make a fuss about one supported option not working
to a standard the rest of the community pretty much agrees is nowhere near
attainable at this time. Using netselect
https://packages.debian.org/stable/net/netselect to choose a reachable
mirror with the lowest latency would have easily mitigated this issue for
you.

DNS64 and NAT64 are going to be with us for a very long time, and if you
refuse to support IPv4 even through a translation layer then it is clear
you are acting against the interests of further IPv6 adoption by
associating IPv6 issues with zealotry. The apathy sometimes associated with
IPv6 support today is because of this perceived high effort low reward
nature of confrontation.

I would strongly advise you apologise to Marco for your grandstanding, and
adopt a more constructive way of furthering your ideology. The NANOG code
of conduct clearly states:

https://www.nanog.org/about/code-conduct/

> In the spirit of mutual respect and collaboration, NANOG does not
tolerate any unwelcome behavior, including but not limited to:
> * Aggressively pushing your own services, products, or causes.
> [...]

Please join the rest of us in advocating for IPv6 adoption, rather than the
current bullying tactics you seem to be choosing that wins the battle and
loses the war. We are all friends* here. You can be a great asset in this
effort we should all seek.

M


*FSVO friends, obvs.
Re: IPv6 and CDN's [ In reply to ]
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 :-/
Re: IPv6 and CDN's [ In reply to ]
On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
> 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?

Even the DNS root servers are not 100% reachable via IPv6. I would think IANA
would have some standard about reachability for root operators.

FWIW, I just was able to change my home office internet (I reside in the most
densely populated county of Florida). The new provider sold me a dual stack
connection, however when they came to deliver it, there was no IPv6 as
promised. After spending almost a week playing phone tag, I finally got some
one with clue. I was told they have no support if IPv6 and no plans to ever
support IPv6 as there is no way to monetize it.

This leaves me in the same position as my prior circuit via the local cable
co. (no plans to offer IPv6) but at least it's faster than the 2 meg up cable
service.

Until IPv6 becomes provides a way to make money for the ISP, I don't see it
being offered outside of the datacenter.
--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
Re: IPv6 and CDN's [ In reply to ]
On Friday, 22 October, 2021 16:45, "Bryan Fields" <Bryan@bryanfields.net> said:

> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.

I don't think it'll ever make money, but I think it will reduce costs. CGNAT boxes cost money, operating them costs money, dealing with the support fallout from them costs money. Especially in the residential space, where essentially if the customer calls you, ever, you just blew years' worth of margin.

My residential ISP here in the UK routes me (and every other subscriber) a /56 without being asked. (Their supplied CPE router just puts the first /64 on the LAN and refuses to process PD requests to hand out any of the other /64s, but baby steps...)

Cheers,
Tim.
Re: IPv6 and CDN's [ In reply to ]
Hi again,

Op 22-10-21 om 17:13 schreef Job Snijders:

> Tl;DR

Not at all. This was a very interesting read! Thank you.

While pondering over it, I noticed that the ns[1234].fastly.net servers
are nicely anycasted throughout the globe. If anyone could turn on IPv6
on their authoritatives without therisk of loosing too much performance,
I reckon it would be them... our Cloudflare. But they already did it. ;-).

> work in progress!

I have good hopes. Rumour has it that Fastly employs some very smart
people. I'm sure we'll see nice things happening when the time is right.

--
Marco
Re: IPv6 and CDN's [ In reply to ]
On 10/22/21 17:45, Bryan Fields wrote:

>
> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.

It is being offered, it's just not being adopted.

We deliver an IPv6 /126 p2p and /56 or /48 onward assignment to all our
DIA customers. No interest.

We deliver an IPv6 /125 p2p and eBGP session to all our IP Transit
customers. 5/10 are interested.

You can only do what you can only do.

Mark.
Re: IPv6 and CDN's [ In reply to ]
On 10/22/21 18:08, tim@pelican.org wrote:

> I don't think it'll ever make money, but I think it will reduce costs. CGNAT boxes cost money, operating them costs money, dealing with the support fallout from them costs money. Especially in the residential space, where essentially if the customer calls you, ever, you just blew years' worth of margin.

The problem is accurately modelling cost reduction using native IPv6 in
lieu of CG-NAT is hard when the folk that need convincing are the CFO's.

They are more used to "spend 1 to get 2". Convincing them to "save 2 by
spending 1" - not as easy as one may think.

Mark.
Re: IPv6 and CDN's [ In reply to ]
Bryan,

On Oct 22, 2021, at 11:45 AM, Bryan Fields <Bryan@bryanfields.net> wrote:
> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
>> 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?
>
> Even the DNS root servers are not 100% reachable via IPv6.

Excepting temporary failures, they are as far as I am aware. Why do you think they aren’t?

> I would think IANA
> would have some standard about reachability for root operators.

I think you might misunderstand relationships here.

The IANA team’s standards are what the community defines. In the case of the root operators, RFC 7720 says “root service” must be available via IPv6 and RSSAC-001 (“Service Expectations of Root Servers”, https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf) says:

"[E.3.1-B] Individual Root Servers will deliver the service in conformance to IETF standards and requirements as described in RFC 7720 [4] and any other IETF standards-defined Internet Protocol as deemed appropriate."

So, in theory, all the root servers should be available via IPv6 and, as far as I can tell, they are.

However, the IANA team is not the enforcement arm of the Internet. If a root server operator chooses to not abide by RFC 7720, there is nothing the IANA team can do unilaterally other than make the root server operator aware of the fact.

> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.

Different markets, different approaches. In the areas I’ve lived in Los Angeles, commodity residential service via AT&T (1 Gbps up/down fiber) and Spectrum (varying speeds) is dual stack by default (as far as I can tell). I suspect all it would take would be one of the providers in your area to offer IPv6 and advertise the fact in their marketing to cause the others to fall into line.

Regards,
-drc
Re: IPv6 and CDN's [ In reply to ]
On Fri, Oct 22, 2021 at 8:48 AM Bryan Fields <Bryan@bryanfields.net> wrote:

> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
> > 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?
>
> Even the DNS root servers are not 100% reachable via IPv6. I would think
> IANA
> would have some standard about reachability for root operators.
>
> FWIW, I just was able to change my home office internet (I reside in the
> most
> densely populated county of Florida). The new provider sold me a dual
> stack
> connection, however when they came to deliver it, there was no IPv6 as
> promised. After spending almost a week playing phone tag, I finally got
> some
> one with clue. I was told they have no support if IPv6 and no plans to
> ever
> support IPv6 as there is no way to monetize it.
>
> This leaves me in the same position as my prior circuit via the local cable
> co. (no plans to offer IPv6) but at least it's faster than the 2 meg up
> cable
> service.
>
> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.


87% of mobiles in the usa are ipv6

https://www.worldipv6launch.org/measurements/





> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>
Re: IPv6 and CDN's [ In reply to ]
And ipv4 I presume so there is still easier and cost less money to just go with that.
From our point as an MSP no customer has a requirement that they want to be able to be reached via IPV6 so it’s still cheaper to buy up IPV4 address space and do a lot of nat than to convert all our services to function properly with IPV6.
Sure one could argue that they should have been made that way from the beginning but without customer demand why would we spend the money?

//Gustav


> 23 okt. 2021 kl. 15:33 skrev Ca By <cb.list6@gmail.com>:
>
> ?
>
>
>> On Fri, Oct 22, 2021 at 8:48 AM Bryan Fields <Bryan@bryanfields.net> wrote:
>> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
>> > 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?
>>
>> Even the DNS root servers are not 100% reachable via IPv6. I would think IANA
>> would have some standard about reachability for root operators.
>>
>> FWIW, I just was able to change my home office internet (I reside in the most
>> densely populated county of Florida). The new provider sold me a dual stack
>> connection, however when they came to deliver it, there was no IPv6 as
>> promised. After spending almost a week playing phone tag, I finally got some
>> one with clue. I was told they have no support if IPv6 and no plans to ever
>> support IPv6 as there is no way to monetize it.
>>
>> This leaves me in the same position as my prior circuit via the local cable
>> co. (no plans to offer IPv6) but at least it's faster than the 2 meg up cable
>> service.
>>
>> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
>> being offered outside of the datacenter.
>
> 87% of mobiles in the usa are ipv6
>
> https://www.worldipv6launch.org/measurements/
>
>
>
>
>>
>> --
>> Bryan Fields
>>
>> 727-409-1194 - Voice
>> http://bryanfields.net
Re: IPv6 and CDN's [ In reply to ]
> On Oct 23, 2021, at 8:30 AM, Ca By <cb.list6@gmail.com> wrote:
>
> 87% of mobiles in the usa are ipv6
>
> https://www.worldipv6launch.org/measurements/ <https://www.worldipv6launch.org/measurements/>
>

Agreed. When they have to connect to an IPv4 only host, they do some type of AFTR. These devices have never known a world outside of this situation. That is a major difference.


>
>
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net <http://bryanfields.net/>
Re: IPv6 and CDN's [ In reply to ]
I think you will find that there are some places in which getting IPv6 network service has been difficult, and as a result even IPv6-capable equipment is not reachable by IPv6. Those are, however, few and far between.

Sent using a machine that autocorrects in interesting ways...

> On Oct 23, 2021, at 6:04 AM, David Conrad <drc@virtualized.org> wrote:
>
> So, in theory, all the root servers should be available via IPv6 and, as far as I can tell, they are.
Re: IPv6 and CDN's [ In reply to ]
On Sat, Oct 23, 2021, 15:17 Fred Baker <fredbaker.ietf@gmail.com> wrote:

> I think you will find that there are some places in which getting IPv6
> network service has been difficult, and as a result even IPv6-


Fred, do you mean places like, all of Verizon FiOS?


capable equipment is not reachable by IPv6. Those are, however, few and far
> between.
>
> Sent using a machine that autocorrects in interesting ways...
>
> > On Oct 23, 2021, at 6:04 AM, David Conrad <drc@virtualized.org> wrote:
> >
> > So, in theory, all the root servers should be available via IPv6 and, as
> far as I can tell, they are.
>
Re: IPv6 and CDN's [ In reply to ]
On 10/23/21 9:03 AM, David Conrad wrote:
> Bryan,
>
>> Even the DNS root servers are not 100% reachable via IPv6.
>
> Excepting temporary failures, they are as far as I am aware. Why do you
> think they aren’t?

I can't reach C, 2001:500:2::c, from many places in v6 land. My home and
secondary data center can't reach it, but my backup VM's at another data
center can.

<snip>

> However, the IANA team is not the enforcement arm of the Internet. If a
> root server operator chooses to not abide by RFC 7720, there is nothing the
> IANA team can do unilaterally other than make the root server operator
> aware of the fact.

Surely IANA has the power to compel a root server operator to abide by policy
or they lose the right to be a root server?

>> Until IPv6 becomes provides a way to make money for the ISP, I don't see
>> it being offered outside of the datacenter.
>
> Different markets, different approaches. In the areas I’ve lived in Los
> Angeles, commodity residential service via AT&T (1 Gbps up/down fiber) and
> Spectrum (varying speeds) is dual stack by default (as far as I can tell).
> I suspect all it would take would be one of the providers in your area to
> offer IPv6 and advertise the fact in their marketing to cause the others to
> fall into line.

Prior ISP charged me $15/month per IPv4 address and a mandatory router rent of
$10/month. New one gets $5/month per IPv4 address. The reason for this is IP
scarcity. They have plenty of v4 space, so this allows them to charge for it.
v6 isn't going to make them any more money as they can't charge for it.


--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
Re: IPv6 and CDN's [ In reply to ]
On 10/23/21 9:30 AM, Ca By wrote:
>> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
>> being offered outside of the datacenter.
>
> 87% of mobiles in the usa are ipv6
>
> https://www.worldipv6launch.org/measurements/

Mobile is different, v6 makes financial sense as CG NAT doesn't scale to 400m
cell phones in north America. (does NANOG scope include Mexico?)

That said most (all) IPv6 cellular providers still don't use it for end to end
connectivity, as inbound connections are silently dropped. In the US if you
want inbound connectivity to work via cellular, you must to buy the static IP
service from Verizon, and it has no IPv6 support, and no plans for it in the
future.

Oddly enough the MVNO services over T-Mobile seem to allow inbound IPv6, but
TMO proper doesn't. V6 that works everywhere would simplify a _huge_
connectivity problem for me.


--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
Re: IPv6 and CDN's [ In reply to ]
Sent using a machine that autocorrects in interesting ways...

> On Oct 23, 2021, at 1:55 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
>
>> On Sat, Oct 23, 2021, 15:17 Fred Baker <fredbaker.ietf@gmail.com> wrote:
>> I think you will find that there are some places in which getting IPv6 network service has been difficult, and as a result even IPv6-
>
>
> Fred, do you mean places like, all of Verizon FiOS?

That would be an example. If I traceroute to an ipv6 address, the fact that I get a response is proof that the path works. F root has some servers for which, MOU be damned, there is no working IPv6 path. Mumble…

>> capable equipment is not reachable by IPv6. Those are, however, few and far between.
>>
>> Sent using a machine that autocorrects in interesting ways...
>>
>> > On Oct 23, 2021, at 6:04 AM, David Conrad <drc@virtualized.org> wrote:
>> >
>> > So, in theory, all the root servers should be available via IPv6 and, as far as I can tell, they are.
Re: IPv6 and CDN's [ In reply to ]
On Fri, Oct 22, 2021 at 05:13:09PM +0200, Job Snijders via NANOG wrote:
> 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.
>
> ** SNIP **
>
> 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! :-)

Some of the other CDNs do have IPv6 on the authorities and
should work without issues.

eg:

dig -6 +trace www.akamai.com.

- Jared

--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: IPv6 and CDN's [ In reply to ]
On Mon, Oct 25, 2021 at 04:20:28PM -0400, Jared Mauch wrote:
> Some of the other CDNs do have IPv6 on the authorities and
> should work without issues.
>
> eg:
>
> dig -6 +trace www.akamai.com.

Yes of course :-)

dig -6 +trace www.fastly.com.

Kind regards,

Job
Re: IPv6 and CDN's [ In reply to ]
Bryan,

On Oct 23, 2021, at 5:56 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
>> Excepting temporary failures, they are as far as I am aware. Why do you
>> think they aren’t?
>
> I can't reach C, 2001:500:2::c, from many places in v6 land. My home and

> secondary data center can't reach it, but my backup VM's at another data
> center can.

Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a cake.

>> However, the IANA team is not the enforcement arm of the Internet. If a
>> root server operator chooses to not abide by RFC 7720, there is nothing the
>> IANA team can do unilaterally other than make the root server operator
>> aware of the fact.
>
> Surely IANA has the power to compel a root server operator to abide by policy
> or they lose the right to be a root server?

To compel? No. Not in the slightest. That is not how the root server system works. This is a (very) common misconception.

There has been some effort to create a governance model for the root server system (see https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I believe it has gotten bogged down in the question of “what do you do when a root server operator isn’t doing the job ‘right’ (whatever that means and after figuring out who decides) but doesn’t want to give up being a root server operator?”. It’s a hard question, but it isn’t the folks at IANA who answer it.

Regards,
-drc

1 2 3 4 5  View All