Not every server is bad. If you run a personal SMTP server that merely collects your incoming email, you're actually doing the cable company a favor. You reduce the load on their mail servers without increasing the load on the cable network. (This assumes you've disabled SMTP relaying, which everyone should do to prevent their SMTP server from being abused by spammers.)
An enlightened cable company should also have no objection to running Telnet, FTP or SSH servers for personal use, such as remotely accessing your computer when you're away. Just keep the traffic reasonable.
It goes without saying that any special software required by the cable network must be installed on any computer that is to connect directly to the cable modem. For Road Runner, this includes a DHCP client and the Road Runner login program. @Home requires neither program, so you need only configure the second computer with the same IP settings as the first.
You must generally reset the cable modem each time you swap computers. The Motorola CyberSURFR cable modem (or possibly the head-end cable router) appears to enforce the limit on the number of connected computers by memorizing the first client Ethernet link-level address it sees at startup and only allowing packets from that address. In the Road Runner systems, additional computers may be able to obtain IP addresses (i.e., DHCP will succeed) but attempts to actually use those addresses will fail.
Some cable modem services hardwire the customer's Ethernet address into their databases, and a call to customer support is required to change it (some MediaOne systems reportedly do this). The most expedient way to change computers (or Ethernet cards, for that matter) on such a system is to configure the new system or Ethernet card to use the same Ethernet link level address. I don't know if this is possible in Windows 95, but it is easy to do in Linux and BSD. In Linux,
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:60:97:AD:10:55 inet addr:24.1.1.1 Bcast: [etc]
shows the link level (hardware) address of interface eth0, and
# ifconfig eth0 hw ether 00:60:97:AD:10:55
sets it to the specified value. You must do this before the interface is activated, e.g., with a DHCP client.
This is a simple approach, but beyond the extra monthly charge it can have some serious limitations. On the San Diego Road Runner system, IP addresses are dynamically allocated from several noncontiguous blocks, and the addresses assigned to your computers are not necessarily on the same IP subnet. This means your computers may have to talk to each other by way of the Road Runner system even though they're plugged into the same hub!
Even if the assigned addresses are on the same IP subnet so that your computers can talk directly to each other, Road Runner may go down. If it stays down for a while (as it often does), the leases on your IP addresses may expire and your computers will stop talking to each other. This problem is exacerbated by the short lease period typically used, only 1 hour on the San Diego system.
For those running Windows systems whose only need for local communications is file sharing, some users recommend using the NETBIOS or IPX protocols for this purpose. Both run directly atop Ethernet without using IP addresses, so it is immune to the problems just described. Because Road Runner cannot route these protocols off your physical LAN, this also has the side benefit of improving security by making it impossible to access your file servers from the outside.
You may not even need an Ethernet hub if you only have two computers. You can add a second Ethernet card to your relay computer and then connect one interface to your cable modem and the other to your second computer, using a "crossover" cable for the latter connection. Even if you do have a hub, you may still wish to dedicate an interface on your relay system to the cable modem. This can improve security (by isolating the cable modem from your LAN) and performance (by not having all the data to or from a user machine pass over your LAN twice.)
These three relay techniques share several significant advantages. You only need one IP address from the cable company. You can use fixed IP addresses on your LAN to avoid the hassle of dynamic addresses on arbitrary subnets that may change arbitrarily or go away when the cable network goes down. This is especially important if you use your machines as local servers for each other. For NAT, the fixed local IP addresses can be in a private address block as specified in RFC 1918. In the case of IP-in-IP tunneling, you use globally unique IP addresses.
The main disadvantage of all three relay approaches is that you
have to leave the relay machine up and running for the other computers
to access the cable modem. The relay system need not be dedicated to
the task; it's easiest if the relay functions can be performed on a
machine you'd leave on anyway. Many people who run Windows on their
primary computers resurrect their old dusty 486s or slower Pentiums,
bring up Linux and use them as dedicated relays. Still, this consumes
electricity and generates noise.
NAT, also known as IP masquerading, works as follows.
When the computer acting as the NAT relay between the LAN and the
cable modem receives a packet from a local computer destined for the
outside Internet, it replaces the source address in the IP packet
header with its own address and the source port in the TCP or UDP
packet header with another value chosen out of a local pool. It then
recomputes the appropriate header checksums and forwards the packet to
the Internet as if it originated from the relay host using the IP
address assigned to it by the cable modem service provider. When reply
packets from the external Internet are received over the cable modem
by the NAT relay, the original IP source address and TCP/UDP source
port numbers are written into the destination fields of the
packet (since it is now moving in the opposite direction), the
checksums are recomputed, and the packet is delivered to its true
destination. This is possible because the NAT relay keeps a table of
the IP addresses and port numbers of the local systems currently using
it.
NAT is very popular, and it works very well for many people. But
it is not without problems. The most important limitation is that
every computer on the LAN that uses a NAT relay must, without
exception, originate every transaction to the external Internet. In
other words, computers on the LAN behind the NAT relay can only
function as clients; it is impossible to access a server running
behind a NAT relay from the outside Internet (though one may run
on the NAT relay itself, using the IP address assigned to it by the
cable service provider.)
Another problem with NAT appears when application protocols
pass IP addresses to their peers. Because the applications are
unaware that NAT is in use, the IP address sent from behind a NAT
relay may not be the one seen on the connection by the recipient. The
most common offender in this regard is FTP, the file transfer
protocol, where by default the FTP server opens a TCP connection to
the client for each data transfer. Fortunately there exists a
"passive" command in the protocol that tells the server to allow the
client to open the data connection to the server. This must
be used whenever a FTP client connects through a NAT relay.
Additional problems appear with NAT when a transport protocol other
than TCP or UDP is used, because the NAT relay may not be able to
translate its port numbers (or the protocol may not even have port
numbers at all). This problem is most serious with the new IP
Security Protocol (IPSEC), where all transport layer information is
encrypted and thus inaccessible to the NAT relay. If IPSEC is to be
used in conjunction with NAT, the IPSEC end point will have to reside
on the NAT relay system itself. NAT is not a barrier, however,
to encryption schemes that operate above the transport layer, such as
SSL (secure web pages),
SSH (secure login and file transfer)
and PGP (secure email).
NAT is already incorporated in the Linux kernel, although it may
have to be recompiled to enable this option. Here are links to
pages with information on how to use this feature in Linux:
Several NAT packages are available for Windows platforms. I do not
have any personal experience with them, as I cannot understand why
anyone would pay good money for proprietary software when the same
feature can be had for free in
open source software
that is invariably of higher quality.
But if you don't want to do this, a list of many different NAT
products for Windows can be found on
The NAT Page.
Once again, the necessary features are provided in
Linux; see my earlier essay IP-in-IP Tunneling
Over Road Runner With Linux for the details.
On the downside, an IP-in-IP tunnel is significantly harder to set
up and maintain than a NAT relay, an external system to serve as the
tunnel end point is required, and performance can be less because of
the extra packet header overhead and suboptimal routing that must
always include the tunnel system.
IP-in-IP tunneling also aggravates the
Path MTU Black Hole problem. Although the fault is actually in the
configuration of the servers and firewalls you're (trying) to reach,
it may be easier to work around the problem locally by lowering the
MTU (maximum transmission unit) on the network interfaces of your
computers behind the tunnel relay machine by 20 bytes to allow room
for the extra IP header added by the encapsulation process.
This is simple and straightforward with Linux, which allows the MTU
to be specified on a per-route basis in the routing table, e.g.,:
TCP connections using the default route will ask their peers to
limit the size of the packets they send to 1480 bytes (the normal
limit for Ethernet is 1500), and they will also limit the size of the
packets they send. (Note the use of the term mss in the route
command when mtu is properly meant; this is a minor goof in
Linux). The TCP maximum segment size (mss) actually used on a
connection will be 40 bytes less than the MTU to allow for the IP and
TCP headers, or even smaller if header options such as TCP header
timestamps are used.
SMTP, POP and HTTP are the protocols for which this is most easily
done. Popular mail and web clients such as Eudora, Netscape Navigator
and Internet Explorer all support the use of gateway servers. For SMTP
and POP, servers such as sendmail, qmail and popper are universally
used on Linux, BSD and UNIX systems.
HTTP (web) transactions can be gatewayed through any of several
caching web proxy packages, such as
squid.
An alternative is my own
httproute
package, written in Perl. It is not as efficient as Squid, but in addition to
web caching it provides additional features such as HTTP routing,
banner ad blocking and cookie cutting.
Both squid and httproute are open source software
designed for UNIX, BSD and Linux.
Running your own caching web proxy has the advantage of allowing
your local users to share copies of web objects that would otherwise
be downloaded more than once over the cable modem to the different
computers on your local network.
Application gatewaying can be used in conjunction with NAT or
IP-in-IP tunneling; the application protocols not gatewayed can be
NATed or tunneled.
I understand that similar functionality is available for Windows
systems with after-market packages, but again I see no reason to pay
for something I can get for free in an open-source operating
system. One such gateway product for Windows is Wingate.
Network Address Translation
IP-in-IP Tunneling
An alternative to NAT is IP-in-IP tunneling or encapsulation. In this
scheme, each packet from the LAN to the outside Internet is wrapped
inside another packet by the relay system that is addressed to a
system on the external Internet that can unwrap the packet and send it
on its way. Encapsulation escapes the problems with NAT described
above; it is the best way to provide all the computers on your local
network with static, globally routeable IP addresses while using only a
single dynamically allocated address from the cable service provider.
$ route add default dev eth0 gw 1.2.3.4 mss 1480
Application Gatewaying
Some important applications can be handled by running an application
layer gateway on the relay machine. Clients on the local network are
configured to talk to the servers running on the application gateway
system, which in turn establishes its own connections as necessary to
the outside world.
Summary
Swapping the Ethernet cable
Advantages
Disadvantages:
Buying extra IP addresses from the cable company (if available)
Advantages:
Disadvantages:
Network Address Translation (aka IP Masquerading)
Advantages
Disadvantages
IP-in-IP Tunneling
Advantages
Disadvantages
Application layer relaying
Advantages:
Disadvantages: