What To Do If You Have Only One IP Address?

Back in the day when I lived with my parents and we first got dial-up, we're already sharing that single internet connection between two computers, mine and my brother's. The modem is connected to my computer, and I setup HTTP proxy and SOCKS proxy using WinGate. My brother's computer is connected to my computer using a crossed Ethernet cable. We had a small LAN thanks to our involvement in LAN parties back in high school.

When we got DSL, I retired WinGate, and used the NAT masquerading capability built into the Linux 2.4 kernel to share the Internet connection. Although NAT is much more transparent (no cumbersome proxy configuration), we could only have one computer play online at a time because the game servers would get confused if it sees two clients coming from the same IP address. These game servers are definitely more lenient nowadays, thanks to the proliferation of DSL sharing.

At that time, I also started playing around with running various kinds of servers: web servers and game servers. I learned that you have to setup port forwarding at the NAT gateway if you want the server to be reachable from the Internet. Port forwarding allows me to forward all connections to this particular port on the Internet side of the gateway to one computer on the LAN. It cannot forward one port to two computers. If I have two computers running the same type of server, wanting the same port to be forwarded to both of them, I would be in trouble.

What if I do want to run web server for two or more websites? For web servers I have several options:

• Run two servers and forward two ports, port 80 to one computer, and 81 to another. The URL would have to specify the port number explicitly, e.g. http://www.example.com:81. This is admittedly ugly.
• Run just one server, and use virtual hosting. This is a feature of HTTP/1.1.
• I could forward port 80 to a reverse HTTP proxy, and let the reverse proxy decide how to handle the traffic. Some may go to one server, and some goes to the other.

However, options are very limited for other kinds of servers, especially game servers. They often insist on using a fixed, non-configurable port number as well. The situation gets a bit hairy during sibling rivalry when both me and my brother want to run our own game server, and neither want to participate in the other one's. Of course, me being the network admin, I get the unfair upper hand.

The lesson is that, if you want to run multiple instances of certain servers, you will need multiple IP addresses. The problem is that IP addresses are suffering shortage, and it's running out. Also, residential Internet users only get one IP address. Only business users get multiple static IP assignments, which costs extra money.

Fast forward ten years. Game servers are still as stubborn as ever, requiring the use of a fixed port number. However, other services are becoming more flexible, allowing the use of any port numbers (it used to be the case that port number uniquely identifies a service). Some examples are XMPP and SIP. These services use the SRV record configured in a DNS server to locate the port and IP address. It would be nice if HTTP, probably the most popular server type on the Internet, could become SRV-aware one day.

Meanwhile, more peer to peer technologies such as Skype, both voice and video, have been developed. Peer to peer sometimes requires both parties to be directly reachable on the Internet, and certainly requires at least one party to be reachable. However, recall that computers sharing Internet connection behind NAT needs special setup to be reachable, the proliferation of shared home DSL is a big headache for these peer to peer technologies.

In order for peer to peer technologies to work when both parties are behind NAT, more technologies like UPnP and STUN have been developed. UPnP allows a program running on a LAN computer to find the gateway (which needs to be UPnP aware, certainly not the case for my home-brew Linux NAT box 10 years ago) and add dynamic port forwarding; it works for TCP connections. STUN uses clever packet header forging to puncture holes for UDP connections. Otherwise, a third party relay that is reachable by both peers is required.

The third party relay certainly makes the "peer to peer" part of the technology moot. For the service operator, this means they require additional network and computing resource to run the relays. For end users, they are asked to trust the third party to not misuse the content of the communication that is supposed to involve only two parties in the first place. The only real solution is to have both peers have their own IP addresses. Again, this is not possible.

Until now.

More and more ISPs are deploying IPv6, which solves the address shortage issue. Even if an ISP does not provide IPv6, you could often use a free tunnel service that gives you IPv6 connectivity tunneled over the old IP, which is now called IPv4. Airport Express has an advanced option to configure IPv6 tunneling. If your ISP provides a tunnel, Airport Express can pick it up automatically using RFC 3068. If not, it will use a tunnel broker provided by Sprint. The end result is that Airport Express gives each device on the LAN a publicly addressable IPv6 address using the IPv4 address concatenated with the MAC address of the device. One perk of using IPv6 is that you'll see the Kame turtle dancing.

Nowadays, I use Comcast business class network with 1 static IP address (courtesy to my employer who pays for it). Using Airport Express, I'm happy with the fact that each computer on my LAN now has a publicly addressable static IPv6 address. I look forward to more IPv6-only peer to peer technologies being developed, technologies that are free from ugly workarounds such as UPnP and STUN.