> 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. VoIP is still a client-server model when you get down to the individual communications. For that matter so is UDP. In any communication you have to have a listener waiting for attention and a party that initiates the message transfer. This happens even when you look at CSP type mechanisms where there is a symmetric rendezvous. > What if two boxes want to have the same port open? Same thing that happens when two processes on the same box ask for the same port. The latecomer loses. Either that or the port is assigned on a different IP address, these could be pooled at the ISP level. That is not a problem if you know about this restriction when you design the protocol that is NAT listener friendly. You could even build into the protocol a feature that would allow a response of the type, 'the port requested is already in use by machine at address 10.2.1.1, he is accepting requests to share via protocol X on port Y' > 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. Needs attention is not the same as 'impossible'. It is very clear that the negative effects of NAT can be largely eliminated if there is goodwill and an intention to succeed. It is equally clear that the whole issue of NAT has been addressed here with a complete determination to fail. > It's annoying when people complain about a problem when the > solution is right there in their face. A 'solution' that requires action by parties completely out of my control does not qualify as such in my opinion. At present I don't expect much in the way of NAT deployment before 2015, and that is building in expectation of a major shakeup in the management structure in 2010. If things go on as at present I don't expect IPv6 deployed before 2025. > > 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. NAT performs address translation. it is in effect an Ipv4 to IPv4 translator. Make that transparent and you can make Ipv4 to IPv6 and IPv6 to Ipv4 transparent in the same way. > 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. Which is why the empirical observation that firewalls significantly reduce the number of successful penetration incidents is important. The theoretical strength of a firewall against the NSA is irrelevant when 99% of the attacks are from script kiddies. Filtering out the 99% of script kiddies allows more time to focus on the remainder. > 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. Yes, and sign the messages under a key protected by the trustworthy computing base. That is where Palladium gives real value. Phill