Speaking as the designer of the network portion of a couple of those popular games, the applications are _not_ broken. Sending the IP addresses is the only working method to dynamically join and redirect multiplayer games. I'm reasonably familiar with DNS, DynDNS, and DHCP. :-) And the lack of deployment thereof. :-( And GreenDragon runs its own ISP (WaterValley.Net), which I built, so I'm extremely familiar with the operational side, too. ---- In general: I've checked passing the DNS name. I've experimented with a generic URL-style syntax. If both the forward and inverse DNS is not updated properly, then these methods fail to work. In my experience, they fail to work almost everywhere in the current Internet, including at such unimportant locations as Apple.Com. Very hard to get paid by the client, when they can't test the game at the vendor's main software platform testing site. ---- Specifically: The users should not need and do not want to enter their own DNS names. They must be dynamically discoverable from the inverse. Many inverses are not properly maintained. Worse, many inverse addresses at dial-up networks don't map to a unique DNS name that forward maps to a unique address. Until such maintenance is automatic and universal, there is no DNS name to pass. Thus, the address must be passed. Even if I included the DNS name in the discovery data, the DNS forward needs to be resolvable by the prospective peer on the other network. In my experience, RFC-1918 exterior forward DNS is not dynamically updated with the NAT translation address. Since DNS name passing won't work, and passing RFC-1918 addresses won't work, the result is that RFC-1918 sites simply don't work. ---- Conclusion: My advice is to never use RFC-1918 for connected networks. NAT was a terrible kludge. Demand DHCP with Secure Dynamic DNS from your vendors!
From: Joel Gallun <joel@wauug.erols.com> On Mon, 9 Jun 1997, Edward Fang wrote:
This is all great and dandy, but then why does it appear that anybody with a cable modem this side of the sun are using static IP's. Granted that the Nic probably didn't allocate the current /8 (or the next one), but I don't see any (and didn't see any prior) 'investigation' to make dynamic allocation possible (or using RFC1918 addresses). Are they looking at DHCP or RFC1918 as a solution for their userbase ?
We're doing cablemodems out of RFC1918 address space using PIXes in several communities and it hasn't been fun. Many of the latest-n-greatest network apps (games, video, voice, what have you) are broken by NAT. They seem to like to transmit the client's address at the application layer. This of course doesn't work, since the client's address is 10.x.x.x...
You can dismiss this problem by saying the apps are broken (which they are), but the simple fact is our customers want to use these apps.
I'd recommend DHCP. In communities where we've used it, it has worked fine and not caused any of the problems that NAT does.
WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2