RFC-1918, NATs and games

Mon Jun 9 16:24:20 UTC 1997

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 at 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 at UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson at MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2