This might be a totally off-topic tangent. I apologize if it is.
It seems to me that if consumer routers are configured to refuse to forward inbound IPv6 packets to machines on the LAN, we would be in almost exactly the same situation vis a vis home service hosting as we are with IPv4 addresses, NATs, and automated port forwarding protocols. Frankly, this would be a giant step backwards from IPv6 as she is envisioned.
From what I understand, the "average" home user has little to no idea of what a port is or why one might want to forward it. They are also very likely to be incapable of classifying machines that need not be globally reachable. So, either we have to write smart software that can determine whether or not a network device requires protection from inbound traffic, or we have to make a forwarding policy decision for this user when we send them their router.
If we're serious about IPv6, we shouldn't configure our gateway devices to require the software that we write to assume that a globally-reachable address is likely to actually not be globally-reachable.
It would be slightly less evil without NAT. You'd still need the three-party handshake but it would always work. You'd no longer have the symmetric NAT craziness.
You could also dispense with the need for frequent keepalives, a boon to mobile battery life.
Getting rid of NAT is step one. Step two is deperimeterization: getting rid of in-line firewalls. Step two is going to have to wait on OSes having better service encapsulation and app isolation models and for programmers to remove their heads from their behinds and stop writing code that is vulnerable to stack-smashing and buffer overflow attacks.
The last part will be tough. How much longer will the Sun be a main-sequence star? :)
A sends packet to B, which gets dropped by B's stateful firewall.
B sends packet to A, which gets interpreted as response and accepted.
A sends packet to B, which gets interpreted as response and accepted.
The third party is only necessary for telling B about the outgoing port chosen by A's NAT. With IPv6 where there's a stateful firewall but no NAT, a direct connection on a well-known port is possible.
Although in practice, you still need some third party to exchange each other's IP addresses.
> It seems to me that if consumer routers are configured to refuse to forward inbound IPv6 packets to machines on the LAN, we would be in almost exactly the same situation vis a vis home service hosting as we are with IPv4 addresses, NATs, and automated port forwarding protocols. Frankly, this would be a giant step backwards from IPv6 as she is envisioned.
I don't think it is such a giant step back. Devices still get to have addresses in a way that makes sense. Routing still gets to make sense. If two people in the same house want to play a peer-to-peer multiplayer game with a third person not in the same house, under IPv6+automated-firewall-exceptioning they can, whereas under IPv4+automated-port-forwarding they can't.
It's kind of dumb that we need automated port forwarding at all - opening a port should already be a deliberate indication from an application that it wants to accept external connections. If you want to listen only for connections from the same machine, bind to 127.0.0.1 - an equivalent for which will still exist under IPv6. If you want to listen only for connections from the same LAN, think again about what you really want - when the user goes to college, do they really want to be accepting connections from 400 students with poor security practices? If you can stand that, you have nothing to fear from the open internet.
But in the meantime we have the software we have rather than the software we want to have; for home routers, blocking traffic and requiring uPnP or the like is a reasonable default. Even if we do that, IPv6 is still worth it.
I think you're ignoring (or are maybe just innocently ignorant of) one key topic: state.
Stateful firewalls are exactly that - when an internal client initiates a TCP socket, for instance, the firewall knows to expect a series of replies back from whatever system the client contacted and is able to allow that traffic through.
In netfilter (iptables) land, this is handled by the "RELATED" qualifier, so you instruct the firewall to allow any related packets back through to the client.
IPv6 doesn't mean everything has to be globally reachable (except for certain ICMP messages that should always work). By default, I think blocking general inbound traffic is the right way.
When you want to run a service (i.e. something peer to peer or a web server or something), there are protocols for applications to tell the firewall to open certain ports, such as PCP - http://en.wikipedia.org/wiki/Port_Control_Protocol
It seems to me that if consumer routers are configured to refuse to forward inbound IPv6 packets to machines on the LAN, we would be in almost exactly the same situation vis a vis home service hosting as we are with IPv4 addresses, NATs, and automated port forwarding protocols. Frankly, this would be a giant step backwards from IPv6 as she is envisioned.
From what I understand, the "average" home user has little to no idea of what a port is or why one might want to forward it. They are also very likely to be incapable of classifying machines that need not be globally reachable. So, either we have to write smart software that can determine whether or not a network device requires protection from inbound traffic, or we have to make a forwarding policy decision for this user when we send them their router.
If we're serious about IPv6, we shouldn't configure our gateway devices to require the software that we write to assume that a globally-reachable address is likely to actually not be globally-reachable.