I've been trying to figure out why I can reach an IPv6 address at
Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
Internet connections as well as via an HE IPv6 tunnel but not the other
of my two ISP connections
At one point in time a traceroute was dying inside of he.net:
When I asked the kind folks at he.net for some advice about the problem
(i.e. in the first traceroute above) their diagnosis was that
Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
IPv6 address.
Trying to talk to my ISP (again, Cogeco) has been impossible. One
simply cannot reach the people who know more than how to reset your
router and configure your e-mail.
I wonder how I could go any further with this to confirm the diagnosis
that Facebook doesn't have a route to the Cogeco network's IPv6 address
space given that I only have access to my end of the path.
Google and HE don't have IPv6 connectivity with Cogent because Cogent's CEO has been in some decades long pissing match with them about free settlement free peering. That's the unfortunate reality of the situation; nothing you can do other than have another route to HE/Google IPv6 targets. We have some Cogent circuits that are effectively useless for IPv6 as our customer base has heavy traffic to/from Google cloud services, so they can't be used for a backup / DR scenario; their only real value is an optimal route to other Cogent customers. I'm slowly replacing our Cogent circuits when feasible because the reality is our customers reaching Google over IPv6 via all our upstreams is more valuable than Cogent's cost savings.
At this moment it appears there are multiple rifts in the IPv6 default-free zone (that don’t exist in the IPv4 realm), between various organizations. Focusing on one particular partitioning may not help address the other issues.
They should probably just rebrand to CoGeCo, but that does look kinda
silly, so, they probably won't.
Cogeco is an acronym for Compagnie Générale de Communication ("General Communications Company").
Both Cogent Communications and Cogeco are in pretty different market
segments (for anyone in the know), so, they each probably don't really
care about the confusion in their respective target markets.
Interesting. As in a general problem across the Internet or a well
known problem with Cogeco specifically?
You can use our tunnel broker connection (tb.netassist.ua) as a
workaround.
Thanks. But I actually already have a tunnel as well as a(nother)
native IPv6 ISP (yes, I have two consumer ISP connections) which routes
to Facebook properly.
The problem is that for the clients behind this router receiving RAs
for all three upstream connections and plumbing IPv6 addresses on each
of those networks, I know of no way to prevent them from choosing their
Cogeco IP address among the 3 and thus trying to use the Cogeco route.
I can (and have) put a rule into that router to refuse connections to
Facebook when using the Cogeco source address which sends TCP clients a
TCP reset with the hope that (good at least) clients/IPv6 stacks will
try a different source address but the results on that seem spotty at
best.
The most famous lack of IPv6 connectivity is between AS6939 (Hurricane
Electric LLC) and AS174 (Cogent Communication), not to be confused
with AS7992 (Cogeco Cable), which actually does peer with both cogentco.com and he.net, including on IPv6.
The HE/Cogent issue is so widely known that, apparently, nearly
everyone in this thread is misattributing the well-known issue as the
reason for the problems described by the OP, but they're very
obviously not related, apart from the similarity in the brand names.
Cogent started business in 1999 and Cogeco has been around since the 1950s. Who should change their name again?
(To OP: I believe that every last-mile provider in Canda is still offering IPv6 as a best-effort, unsupported service. As a former Canadian networking guy, this ... angers me. Good luck ...)
Yeah. I'm aware of this. But I want to give them the benefit of the
doubt that this problem is simply ignorance and something they'd like
to fix rather than any of the more depressing alternatives.
But what's exactly at 2a03:2880:f012:3:face:b00c:0:1?
It's one of the endpoints involved in Facebook's Messenger service.
IIRC it's "graph.facebook.com", although I note that that address is
currently answering as:
graph.facebook.com. 2068 IN CNAME api.facebook.com.
api.facebook.com. 2068 IN CNAME star.c10r.facebook.com.
star.c10r.facebook.com. 25 IN AAAA 2a03:2880:f00e:a:face:b00c:0:2
To be fair though, that one could just be what a load-balancing name
service is responding at the moment. Notice that the two addresses are
only off by one.
But even more interesting is that it's now working:
I think TFBNW folks definitely read these lists, even if they never
respond officially.
Their whole network was apparently down via IPv6 for like at least a
few days several years ago; they've then fixed it back in the day by
simply removing the AAAA records.
It's kind of amazing that tech reporters never really pick up these
stories, TBH. I guess these outages don't really sell, especially if
noone but a few selected users can even detect it in the first place,
even if they do last for days or even weeks/years for certain users in
certain configurations.
vs. CogentCo 
confusion, I don't think
