[martinald]

But how does eg a device programmatically tell the firewall to allow traffic in in this case? This is done via UPNP on ipv4 NAT.

If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.

Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.

[jeroenhd]

Every guide I see tells you to disable Upnp (or IGD, the part of UPNP that lets you open ports), for good reason. It's a protocol that just disables the security you thought you had before.

The reason Xboxes need port forwarding in the first place is that IPv4 relies on NAT. The unreliability and unpredictability of NAT means remote devices won't know what ports to talk to or if those ports will even be mapped to the right device. IPv6 removes that problem all together! It alleviates the need for 99% of the port forwarding cases that UPNP provides, assuming you've manually enabled it in the first place.

If port forwards are really necessary for Xboxes to work, then IPv6 brings another advantage: you can run multiple Xboxes behind the same IPv4 address. That IPv4 address can be your home connection, or it can be a thousand people behind CGNAT. In countries where CGNAT is the norm (India comes to mind) you can't possibly expect UPNP to be a requirement for Xbox to work!

[martinald]

UPNP is just fine assuming a secure implementation (some of the early ones were awful, but that doesn't make the concept bad). It doesn't reduce security anywhere near like what is made out. If you already have a device on your network that is compromised and is able to do UPNP requests, then you have a much bigger problem (in a home setting).

But IPv6 doesn't solve the problem at all if all incoming connections are blocked on the firewall - which they have to be for security! You need some protocol for the xbox to be able to tell the firewall to open ports, which doesn't exist. Or users have to manually set the firewall rules, which is the same as port forwarding on NAT from a users perspective (ie impossibly complicated)

You can run multiple xboxes behind NAT right now, they get different ports.

Again, for a non technical user there is no major difference between being behind CGNAT IPv4 (impossible to get incoming connections), and firewalled IPv6 (possible to get incoming connections, but the firewall is too complicated to use so it may as well be impossible). If there was a protocol which would allow devices to open ports on IPv6 firewalls programmatically similar to UPNP it would be entirely different, but there isn't.

[jeroenhd]

libupnp/miniupnp seem to support IPv6 pinholes just fine through WANIPv6FirewallControl. I don't sell routers so I don't know how up to date the libraries on your average router firmware are (most likely "ancient") but this isn't a protocol problem. If you run firmware like OpenWRT you've had support for it for at least five years now.

Most consumer routers I've seen these days come with UPNP disabled by default, though.

For most P2P traffic (which includes a third party handshake server) you can probably skip port forwarding entirely; just send UDP packets both ways and the firewall will figure it out. For stateful protocols like TCP and friends (SCTP etc.) that's harder to accomplish this, that's where you need pinholing.

It's possible that your router simply doesn't support IPv6 pinholing but I think the more likely scenario for breakages is that client software doesn't bother implementing it.

[zoredache]

Lots router have UPNP disabled or blocked, and thing still work. UPNP isn't great.

First The firewalls are stateful. Client inside your network attempts to connect to some system outside. The firewall adds an entry to the state table with client ip, destination ip, protocol, ports, and so on. If an incoming packet is received by the firewall, the state table is checked. If there is an matching entry for the ips, proto, ports, etc, then the packet is forwarded. If there is no match the packet is dropped or rejected depending on your config. So it is easy to permit packets based on the interface it was received or transmitted on.

Ports can be opened for some incoming traffic pretty much the same with as IPv4 using STUN, TURN, and so on.

Past that, you can do manual port forwards the same way you do with IPv4.

[martinald]

I understand how stateful firewalls work. But to allow game servers etc to run, you need to explicitly accept incoming connections somewhere, as you don't know the IPs in advance that will connect.

Then if you're using STUN and TURN (which you'll have to, because non technical users do not find configuring firewalls easy) then what is the advantage of IPv6 to a consumer? There is no real p2p benefits.

I'm trying to call out this contradiction:

1) You need a firewall on IPv6 instead of relying on NAT, otherwise everything is routable globally and insecure 2) There will be this glorious new p2p world for consumers with ipv6

If you need a firewall, then really for non technical users you cannot have this p2p world. It is too complicated.

[wolrah]

> But how does eg a device programmatically tell the firewall to allow traffic in in this case? This is done via UPNP on ipv4 NAT.

https://en.wikipedia.org/wiki/Port_Control_Protocol, which also allows for UPnP-like functionality when NAT64 is in play.

That said most "P2P" traffic is still mediated by a central server though and does not need this. The lack of port remapping from NAT means that tricks like UDP hole punching work simply and reliably rather than the semi-random performance seen through NAT. Multiplayer gaming, VoIP, voice/video chat, etc. where a central server does the setup doesn't need ports opened to the world, it just needs to punch a hole for that specific session. A SIP phone opening a port forward on 5060 for itself is a bad thing, but it's sometimes needed in the NAT world.

True unsolicited incoming traffic will still need an allow rule but that's a lot more rare.

> If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.

I disagree. These days the sorts of things normal people do that deal with P2P connections are pretty good at dealing with NAT, but far from perfect. You don't have to look far in to the gaming world to find people complaining about not being able to join a session, not being able to connect to voice, etc.

Any VoIP provider serving users on their own internet connections is going to be doing things like regular keepalives, setting their media systems to accept RTP from and send it back to whatever port it comes out of the user's NAT on instead of the one it's supposed to be on, etc.

All these things work pretty well, most of the time. But they're not perfectly reliable because every NAT implementation is different in subtle ways.

> Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.

As noted previously, in IPv6 it doesn't need to open the port at all. Anything the Xbox, or any other modern game console, will be doing is server-mediated P2P for which standard basic UDP hole punching is a perfect fit.

Basically anything that definitely always requires a port forward in IPv4 NAT will probably still require an allow rule in the firewall, but anything where port forwards aren't supposed to be required but sometimes they help some people more reliably connect is a problem caused entirely by the NAT and those problems go away. Hosting a dedicated game server is in the former category, playing games is in the latter category.

There's a reason all the modern consoles include NAT tests in their network diagnostics, but can only offer vague suggestions at the fix, because how the NAT is breaking things varies by the NAT and may or may not be fixable. The only real fix is to eliminate the NAT.

FWIW Xbox prefers IPv6 when available and Xbox Support specifically recommends having it enabled if you can. That tells me that it works either equally well or better than IPv4 in the real world, which fits my view of things.