> The quickest answer is: Server services are not available behind a NAT. > Yes, P2P applications would have difficulty behind NAT, but many are > designed with this in mind and have alternate means to work from behind > "firewalls" or NAT devices.
Indeed. The typical solution is to have a centralized box to route traffic through. Both end points connect to the box as clients and it routes traffic between them. Skype http://www.skype.com/ is one of the more interesting solutions. I've read their technical information a couple times, and it sounds like they used those unfortunate enough to connect to their network in front of a firewall as call routers. I suspect they assume that there will be enough such users that they will have a widely distributed network. > > NAT was never designed to be a part of ipv4 when the protocol was originally > drafted. NAT is more of a carefully designed hack to allow node(s) to masquerade behind one true ip address. Of course there are wonderful benefits to NAT in other ways. Ahh yes like its firewalling effect? I guess I didn't understand your goal. To me IPv4 NAT is fine for most clients, although I will admit I've never set up a wireless network big enough to require routing. One subnet connected to the wire is all I've needed. I guess I've never thought of wireless as a content distribution mechanism -- mostly just for content consumption networks. As soon as you want to serve content to the internet the NAT problem comes back anyway. _______________________________________________ RLUG mailing list [EMAIL PROTECTED] http://lists.rlug.org/mailman/listinfo/rlug
