> Firewalling P2P traffic effectively remains just as hard with IPv6 as with NAT.
Nope, it's much easier because the addresses are easy to predict. When both parties are behind NAT, neither side knows which address and port they will appear to be coming from to the other side, while without NAT, both parties know exactly what address the other side will see (it's the one the local socket is bound to ...), that makes it relatively easy to establish a connection through a stateful firewall with a simultaneous connect if both sides can somehow tell each other where their respective sockets are.
It's outright trivial with UDP, not quite that easy with TCP: Assume both sides are behind a stateful firewall, both sides simply send a packet from their socket to the respective remote address/port, which will cause each local firewall to establish a connection tracking entry that will allow packets in the respective opposite direction to pass through. There is a race condition that might cause one of the packets to be rejected by the remote firewall (if it arrives before the locally originated packet passed through the firewall), but that doesn't matter: Afterwards, both firewalls have an entry for the connection, and all subsequent packets will pass through just fine. This is impossible with NAT because you cannot know the remote address that the NAT will assign for the connection, so you cannot send a packet to establish the entry in your firewall, and you cannot learn the address because you would need to receive the packet to see the address on it, which you can't as long as the firewall doesn't know about it.
Also, a protocol for opening ports on the stateful firewall would be much simpler without NAT, as the firewall doesn't need to allocate ports or handle conflicts between multiple clients wishing to be forwarded the same port: The address/port allocation authority is with the client, the client('s kernel/network stack) can simply allocate ports on its assigned addresses and then only needs to tell the firewall that connections to a specific address plus port should be allowed in. This also means that, for example, the firewall forgetting those open ports doesn't cause much trouble: The clients simply can tell it again whith ports to open, and they will be reachable again, at the same address, no need to tell peers a new address because a uPnP gateway forgot which ports it had allocated to which client.
And maybe most importantly: P2P traffic between devices on the same LAN becomes much, much simpler. Currently, if you have two participants of some P2P system in one LAN segment, where both establish an open port on the NAT gateway via uPnP, when one wants to connect to the other, there are roughly three possible scenarios: It can try to connect to the public address/port as established by uPnP, just like any remote client would. If you are unlucky, the NAT gateway only does DNAT, in which case the connection won't work because any responses will come from the local address of the peer instead of from the public address of the NAT gateway, so won't be recognized as belonging to the connection. If you are lucky, the NAT gateway does hairpin NAT, in which case the connection works, but all traffic has to go through the NAT gateway in order to rewrite addresses, instead of directly from one machine to the other at the ethernet level, which usually will be much slower than a direct transfer (even more so when there might be multiple people doing the same thing on the same LAN, where the switch might well be able to forward multiple gigabit flows at once, but your DSL NAT gateway most likely will not, not even if they are both in the same case). Or, if you want to avoid both of that, you'd have to somehow detect that you are in the same LAN and then figure out what the address of the peer on the LAN is in order to connect to that address instead (and note that you can't use the local addresses to decide that, even if you know them, as you might well have addresses in the same private address range, but still be connected to completely different LANs).
Without NAT? You simply connect to whatever address the peer announces. If you are on the same LAN, your machine's routing table will automatically route the packets to your local LAN, directly to the other machine, at full LAN speed. If not, they will be forwarded to your local gateway, through the internet, through the remote stateful firewall, and to the remote peer. No difference at all, apart from the speed, possibly, it just works.
Nope, it's much easier because the addresses are easy to predict. When both parties are behind NAT, neither side knows which address and port they will appear to be coming from to the other side, while without NAT, both parties know exactly what address the other side will see (it's the one the local socket is bound to ...), that makes it relatively easy to establish a connection through a stateful firewall with a simultaneous connect if both sides can somehow tell each other where their respective sockets are.
It's outright trivial with UDP, not quite that easy with TCP: Assume both sides are behind a stateful firewall, both sides simply send a packet from their socket to the respective remote address/port, which will cause each local firewall to establish a connection tracking entry that will allow packets in the respective opposite direction to pass through. There is a race condition that might cause one of the packets to be rejected by the remote firewall (if it arrives before the locally originated packet passed through the firewall), but that doesn't matter: Afterwards, both firewalls have an entry for the connection, and all subsequent packets will pass through just fine. This is impossible with NAT because you cannot know the remote address that the NAT will assign for the connection, so you cannot send a packet to establish the entry in your firewall, and you cannot learn the address because you would need to receive the packet to see the address on it, which you can't as long as the firewall doesn't know about it.
Also, a protocol for opening ports on the stateful firewall would be much simpler without NAT, as the firewall doesn't need to allocate ports or handle conflicts between multiple clients wishing to be forwarded the same port: The address/port allocation authority is with the client, the client('s kernel/network stack) can simply allocate ports on its assigned addresses and then only needs to tell the firewall that connections to a specific address plus port should be allowed in. This also means that, for example, the firewall forgetting those open ports doesn't cause much trouble: The clients simply can tell it again whith ports to open, and they will be reachable again, at the same address, no need to tell peers a new address because a uPnP gateway forgot which ports it had allocated to which client.
And maybe most importantly: P2P traffic between devices on the same LAN becomes much, much simpler. Currently, if you have two participants of some P2P system in one LAN segment, where both establish an open port on the NAT gateway via uPnP, when one wants to connect to the other, there are roughly three possible scenarios: It can try to connect to the public address/port as established by uPnP, just like any remote client would. If you are unlucky, the NAT gateway only does DNAT, in which case the connection won't work because any responses will come from the local address of the peer instead of from the public address of the NAT gateway, so won't be recognized as belonging to the connection. If you are lucky, the NAT gateway does hairpin NAT, in which case the connection works, but all traffic has to go through the NAT gateway in order to rewrite addresses, instead of directly from one machine to the other at the ethernet level, which usually will be much slower than a direct transfer (even more so when there might be multiple people doing the same thing on the same LAN, where the switch might well be able to forward multiple gigabit flows at once, but your DSL NAT gateway most likely will not, not even if they are both in the same case). Or, if you want to avoid both of that, you'd have to somehow detect that you are in the same LAN and then figure out what the address of the peer on the LAN is in order to connect to that address instead (and note that you can't use the local addresses to decide that, even if you know them, as you might well have addresses in the same private address range, but still be connected to completely different LANs).
Without NAT? You simply connect to whatever address the peer announces. If you are on the same LAN, your machine's routing table will automatically route the packets to your local LAN, directly to the other machine, at full LAN speed. If not, they will be forwarded to your local gateway, through the internet, through the remote stateful firewall, and to the remote peer. No difference at all, apart from the speed, possibly, it just works.