> In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy.
Not at all--end-to-end encryption is still a very desirable property. I certainly don't want a consumer router decrypting my browser traffic even if it is re-encrypting it to send to my device. I'll tolerate HTTP proxies on the server side when I'm administering the proxy and I need layer 7 routing, but I want to avoid it wherever possible.
> The two biggest use cases for direct p2p connections are multiplayer games and video calling.
You still have to punch a hole in your firewall either way. The only advantage ipv6 has is that you can have two hosts listening on the same port (whereas port-forwarding in a NAT context only works for 1-host-per-port).
Tangentially, I was never a big fan of player-hosted games anyway because they tended to be more vulnerable to cheating and the host always had an unfair advantage (or else a dramatic penalty in the case of lag compensation). Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit (although a poorly written game server might still do just that).
>Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit
What prevents you from putting the same validation logic into the client, thus rejecting malicious packets at the destination?
I mean, correct validation logic is always ideal, but I'm positing a world in which software doesn't always get intentional validation logic. In particular, an intermediate server might prevent packets from flowing to the target client for any number of reasons which aren't intended as "validation". It's just harder to hack through an intermediary.
Ok, but I still don't see why you can't move that intermediary to the client. Spin up a docker container and run the game server there. Ta-da! You have the same security as with a remote server.
My point is that IPv6 restoring the end-to-end principle need not jeopardise the - real or perceived - security of multiplayer games.
It’s not clear to me who “you” is meant to refer to in this scenario.
If “you” refers to the user, then because the game isn’t architected to have a server running next to each client if the server binary is even distributed to users at all.
If “you” refers to the game publisher, then because they aren’t architecting it that way to begin with, because they aren’t thinking about running the server as a security feature.
Moreover, a game developer has incentives to protect its own servers; it has much less incentive to protect its end users. You might argue that it’s end users being hacked is bad for business, but most end users wouldn’t be able to attribute a hack to a particular piece of software or infrastructure if they even know they’re hacked in the first place (consider the rampant insecurity in the consumer router and iot spaces).
I love player hosted gaming. But the people I game with are looking for "fun experiences" (kinda like going to a movie as a group, but more interactive) rather than competitively climbing a leaderboard.
Not at all--end-to-end encryption is still a very desirable property. I certainly don't want a consumer router decrypting my browser traffic even if it is re-encrypting it to send to my device. I'll tolerate HTTP proxies on the server side when I'm administering the proxy and I need layer 7 routing, but I want to avoid it wherever possible.
> The two biggest use cases for direct p2p connections are multiplayer games and video calling.
You still have to punch a hole in your firewall either way. The only advantage ipv6 has is that you can have two hosts listening on the same port (whereas port-forwarding in a NAT context only works for 1-host-per-port).
Tangentially, I was never a big fan of player-hosted games anyway because they tended to be more vulnerable to cheating and the host always had an unfair advantage (or else a dramatic penalty in the case of lag compensation). Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit (although a poorly written game server might still do just that).