🚀 go-pugleaf

"Todd Knarr" <tknarr@silverglass.org> wrote in message
news:BPSd8.2447$2v6.251897@news1.west.cox.net...
> In cox.internet.discussion.athomeconversion
<EDRd8.4547$jC3.171632@news1.east.cox.net> Arthur Hagen <art@broomstick.com>
wrote:
> > Which is kind of hard to do with dynamic and changing IPs, wouldn't you
say?
>
> With changing /32 networks, yes. But then, I tend to work with two
> scenarios:
>
> 1. Public static IPs. The main purpose of giving each machine a public
>    IP is to make them reachable from outside, and addresses that change
>    on a regular basis makes that impossible. Pseudo-static IPs like the
>    ones Cox gives out do work, though, because they don't change often
>    ( at least mine hasn't changed since I got it ). If it ever changes
>    you're going to lose outside connectivity until you find out the new
>    address anyway, regardless of whether the routing tables are correct
>    or not.
> 2. Private static IPs and NAT. In this case your internal network won't
>    change, and the IP of the router isn't even mentioned explicitly in
>    the routing and filter tables so whether it changes or not is
irrelevant.

You forget some scenarios:  You have two hosts who both need to be able to
connect as a client to external non-PASV ftp servers.  With a shared IP and
NAT, this is not possible, as the NAT router has no way of knowing which
machine to route the incoming replies to.  In this case it doesn't matter
whether you get a new IP every so often as long as your client software can
send the remote host its current IP and get a reply back.  Having a routable
IP for multiple hosts is important for other client software too, like X and
NFS (and possibly gnutella, but that isn't allowed on Cox networks anyhow I
bet :-))
With @home, this was no problem.  With Cox, it is.  The service is NOT the
same as it was before - it's been crippled in numerous ways.  I honestly
can't recommend Cox VSI to anyone who wants to do more than basic web
browsing.

Regards,
--
*Art