Is there a similar diagnostic that can be run on a Playstation 5? I generally have good download speeds on my network but it seems to take forever to install games on my PS5.
If you don't have a router you can capture pcaps with, setup a box with two nics, bridged, between your ps5 and your router and take pcaps on that.
I'd expect slow downloads to be either a pMTU problem (but I over index on that), the tcp window is too small, or the download server is far away/high latency. Too small window and far away download server combine to make it worse. Sibling's suggestion of adding a squid proxy likely helps because squid is highly likely to have large tcp windows. Other sibling's suggestion of disable ipv6 is likely to help if Sony didn't bother to do happy eyeballs and their ipv6 infrastructure chooses far away mirrors or is otherwise partially broken.
Could also be using a download server with high path loss, that would show up in the pcap as lots of out of order packets.
I tried to find an article covering this but I've had no luck, so I'm just going off memory here, but I'm pretty certain that's all that was required.
It was badly designed in the first place, CLAT should have been mandated as part of the spec rather than dual stack nonsense.
But I do narrowly agree with GP that CLAT should’ve been a goal from the beginning. Dual stack is such a losing proposition for any org that doesn’t substantially benefit from deploying IPv6. Adding in CLATs with a plan to go 464XLAT from almost day one would have massively changed the calculus.
Even on my standard linux laptop, and corporate windows laptop, with the hack of DNS64, I still have issues with my ipv6 subnet. Yet I have no problem with my ipv4 subnets.
So I don't bother with ipv6 - it's a toy. There is no benefit at all to me, but I can't get rid of IPv4 because some devices won't work with ipv6, and others will work but have bugs.
The ivory towers felt "we know best, everyone will move to us, we don't need backwards compatibility". That arrogance put ipv6 back probably 30 years, maybe more. Building in backward compatibility at the protocol level (so 464 etc) would have removed the need for other hacks (dns64) and allowed a trivial transition.
Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.
I still haven't had a single failure for someone who can't reach an ipv4 endpoint.
As such I see it as just a toy.
All these transitions methods are far to expensive and an unnecessary overhead.
I think you forgot half a sentence here. What was your point?
> And dual stack is no issue.
How can that possibly be so? Having enough address space to comfortably architect gives you room for far superior topologies, meaning that running dual stack at the bare minimum means that either your IPv6 topology is being compromised to map cleanly to your v4 topology, or that you're running two different topologies altogether. You need two times the sets of firewall rules, two times the number of address configurations...everything in your infra roughly 2x.
> All these transitions methods are far to expensive and an unnecessary overhead.
How so? Running 464XLAT on a device with a proper CLAT has minimal overhead, and the PLAT is no worse than running a NAT for IPv4.
Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.
Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).
I completely agree, which is why dual stack is terrible.
> Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.
Dual stack doesn't solve that
> stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used
The source port is ephemeral for almost all applications, and I can't think of a good reason it wouldn't be, just legacy crap
I'd love to have an ipv6 only network with NAT66 at the boundary, at home and at work, but while it still requires ipv4 I don't see the point.
In anticipation for GTA6 I actually bought a PS5 Pro 2 weeks ago. I had to create a separate IPv4-only network because it would not complete the user-sign-up on the device on my IPv4/IPv6 network.
Absolutely insane.