There are good reasons why ISPs are encouraging their customers to use NAT, they provide a weak firewall capability and that in turn significantly reduces exposure to being hacked which in turn reduces the cost of chasing zombie machines.
Hm, but apparently many ISPs don't care about their customer boxes being turned into zombies as they let them persist in their undead state for long periods of time. ISPs would probably love it if there were no NAT (or proxies, NAT is no more than a simple way to implement generic proxying), that way they could extort their customers even more.
I don't think anyone has won here, there are just casualties all over the place: more work for the IETF and vendors, less functionality for the users.
Less functionality is a deliberate, concious choice on the part of the IETF. Fixing the problem is utterly trivial.
A pointer or two to support the former would be nice. An explanation of the latter too, as I'm unfamiliar with this trivial fix.
Or are you referring to the issue that some client/server type interactions are broken when the client is behind NAT? This should probably be fixable in most cases (I wouldn't call updating huge installed bases trivial though), but that still leaves the applications and protocols that don't conform to the client/server model, such as VoIP.
Think of all the machines in my network as a single machine with a single IP address. The requests to open and close ports to the outside world are simply RPC requests (without the RPC syntax).
What if two boxes want to have the same port open? Believe me, you are just making the port number part of the address. Internal address allocation (your RPC w/o RPC mechanism) is only one of the issues that needs attention in this case.
Guess what: we already did pretty much the same thing with IPv6. The logical conclusion here is that we can save a lot of time and effort by simply adding IPv6 to the mix, as it is just a hair shy of being ready for full deployment, while all this stuff to make NAT actually work is all over the place.
Simply repeating the claim that IPv6 is the solution to every issue does not make it so, or advance the deployment of IPv6.
It's annoying when people complain about a problem when the solution is right there in their face.
The problem is the intrinsic asymmetry between the value of an IPv4 and an IPv6 address. An IPv4 address will be visible to the world, an IPv6 address will only be visible to other IPv6 addresses.
In this case, you only need to be visible to the streaming server... Use your IPv4 address for other stuff if you like.
The main reason IPv6 is nowhere is the refusal to deal with NAT except by ideological reactions like the above. NAT is the way to deploy IPv6.
I don't follow.
The whole idea that decent security can be had by allowing packets with certain port numbers in them in and not others is fatally flawed,
Your view is not held by the computer security industry.
The idea that "security" is a substance with an independent existance which underpins a "security industry" is also fatally flawed. (And one of the main reasons why I chose to avoid becoming a part of said industry.) Security is a property of all aspects of life and must be managed as such.
firewalls get to see which applications (and users) are trying to communicate with the outside world, rather than guess based on the port number in the packet.
That is not a bad idea. In essence it would mean extending requests to open incomming AND outgoing ports to the perimeter defense.
"Hey Mr firewall, this is Internet Explorer version 9.2, please allow me to connect up to port 80 on 23.43.2.2"
Right! When the firewall considers IE 9.2 safe it may allow it to communicate freely, but at a later time, when a vulnerability is found and (hopefully) a new version is installed, IE 9.2 isn't allowed to connect to the rest of the world anymore, or only to trusted destinations. This mechanism would also be great to catch trojans and other unauthorized software trying to communicate over the net.