Possible IPv6 Routing Issue for Paramount Plus?

[kernelpanic1]

Hi, I've been having issues streaming Paramount Plus in my household for the past few weeks and started to troubleshoot after not finding anything online about major outages. Typically I'm streaming from a Chromecast 4k, but decided to test from my PC and found I was being automatically redirected to the German site at https://www.paramountplus.com/de/. If I disable my HE IPv6 tunnel, it loads the proper US site ok. This is what a traceroute looks like:

Code Select Expand

tracert www.paramountplus.com

Tracing route to paramountplus.map.fastly.net [2a04:4e42:1c::347]
over a maximum of 30 hops:

  1     1 ms     1 ms     2 ms  <my network>
  2     1 ms     1 ms     1 ms  <my network>
  3    13 ms     9 ms     9 ms  tunnel85994.tunnel.tserv4.nyc4.ipv6.he.net [2001:470:1f06:d7c::1]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7    31 ms    31 ms    31 ms  2001:504:24:1::d361:2
  8    17 ms    15 ms    14 ms  2a04:4e42:1c::347

Any thoughts on this? Could this be a HE issue or possibly Paramount?

[coxim]

Exact same problem here. Would love to know a solution to this. Had to disable IPv6 to get Paramount Plus to work.

[kernelpanic1]

A bit of an update, I was able to null route AAAA records on my DNS server based on the similar workaround needed for Netflix here and Paramount seems to be working again. The domains I came up with for Paramount are below:

server=/cbsivideo.com/#
address=/cbsivideo.com/::
server=/cbsi.com/#
address=/cbsi.com/::
server=/cbsistatic.com/#
address=/cbsistatic.com/::
server=/cbsimg.net/#
address=/cbsimg.net/::
server=/pplusstatic.com/#
address=/pplusstatic.com/::
server=/paramountplus.com/#
address=/paramountplus.com/::
server=/www.paramountplus.com/#
address=/www.paramountplus.com/::
server=/paramountplus.map.fastly.net/#
address=/paramountplus.map.fastly.net/::
server=/saa.paramountplus.com/#
address=/saa.paramountplus.com/::
server=/cbsaavideo.com/#
address=/cbsaavideo.com/::
server=/cbsinteractive.data.adobedc.net/#
address=/cbsinteractive.data.adobedc.net/::
server=/cbsig.net/#
address=/cbsig.net/::
server=/irdeto.com/#
address=/irdeto.com/::

I'm still not sure if this is some kind of IPv6 routing issue or if Paramount is silently blocking HE IPv6 tunnel traffic. If they are blocking, there is no mention of this on their support site, in any error messages, or any other references found on Google.

[cshilton]

The streaming services have a problem in general with the HE tunnelbroker service. Netflix was the first but others have followed. Other people have issues too because the freedom and the performance that makes the service great opens the doors for a technical person to abuse things.

Netflix:

Netflix's specific beef was that there was a person or company somewhere in Europe who advertised a "service" that got you the United States Netflix catalog from Europe. It wasn't a service, the entity was setting up HE tunnels to Europe that terminated on East Coast tunnelbroker servers. So the IP addresses that you got were in the US and originally, Netflix gave you the US catalog rather than the European one. Netflix retaliated by blocking all of 2001:470::/32 via a proxy warning rather than just emitting a TCP RST. Sigh...

Other streaming services:

So far as I can see, many other streaming services followed Netflix. This kindof sucks.

Other issues:

There are people in the world who abuse the Tunnelbroker service to harass both Google and Wikipedia. In the case of Google, we vacillate between an outright kick/ban of 2001:470::/32 and a forced CAPTCHA if our devices hit google over IPv6. In Wikipedia it turns into long kick/bans for editing Wikipedia pages. I haven't seen issues with browsing Wikipedia though.

Conclusion:

None of the options are good here. Outside of HE, the opinion seems to be that "dynamic IP's" ought to be "dynamic" meaning that they should change often even if they don't need to. This belief seems to be as stubborn as the "NAT provides security" argument that's also prevalent. Just in general, people don't seem to get IPv6 because it breaks the conception of network addressing which seems to be bound to the limitations that we see with IPv4. I can get native IPv6 on one of my connections and possibly soon both, my wife works out of Boston so we keep an apartment up there but we generally live in CT, but I'm still using HE tunnels but the IP addresses are static and that's really really useful, especially at the price that HE is charging.

So long as the service is structured the way it is and free, as in freedom from restrictions, you're gonna see this. I think that leaves your choices as: Don't use the service because asshats being asshats, random stuff is going to get broken at random times; Do use the service and employ a subset of the workarounds for the breakage.

The workarounds are basically:

• Employ a domain based dns block list -- E.g. doing resolve AAAA queries for anything in *.google.com;
• Employ a program that does the DNS resolution periodically and update your firewall so as to block by external IP address;
• Enumerate your internal assets which shouldn't be using IPv6 and arrange to block outbound IPv6 on them.

As an example of the last issue, if you use SLAAC, you can't stop an AppleTV from getting and IPv6 address. It won't be able to get to Netflix if your IPv6 address comes from HE. You could put your AppleTV into a separate VLAN but to have them in a different broadcast domain than your iPhones and iPads is to nerf a lot of their capabilities.

At the end of the day, none of the solutions are great. For me, using HE is still better than figuring out where my moved to on FiOS when Verizon changes my prefix. Before people start, I get that Verizon changing my IPv6 address is a "me" issue. But the fact that people think that dynamic means stuff should changes makes it a little harder to find the correct DHCPv6 configuration to use on Verizon for an OpenBSD router.