Slashdot Mirror
A New Approach to IP Address Exhaustion
akkem writes "For a while now, we've been running out of IPv4 address space, resulting in more and more computers getting put behind NAT devices. That's fine for many computers, but what if you want that computer to be available as a server? As part of his PhD work, my friend Eugene has come up with a nifty solution, AVES, which enables any computer on the Internet to reach one or more servers placed behind a NAT. His approach is to give each server a unique name (via DNS), and to handle all the IP address translation automatically via an overlay network." This looks somewhat similiar to virtual DNS, but taking it another step, and having the server route the requests behind itself instead of just handling it a little differently.
IP Address Exhaustion is a serious concern. We need to do something to keep our IP addresses from getting all tired out and stuff.
Maybe we should propose IP Address Naps.
Here are some stats from ARIN (unfortunatelly these are circa 1996...):
Right... so there are 127 institutions with class A's all to themselves. Now that's really efficient. Even a full class B (which 10000 organizations have been blessed with) is overkill.
Now, the offenders are here (this list _is_ up-to-date). Most notable class A assignments:
The rest goes to IP registries to dish out in comparatively puny class B and C chunks, and of course the US government.
"Hot lesbian witches! It's fucking genius!"
So why is it not being used? Easy. Same reason multicasting isn't used. None of the ISPs want to upgrade first. They want someone else to take the fall, if there's a problem. The whole bit about demand is politik-speak for "we're not telling anyone what we -could- be selling them, cos customers in the dark are so much easier to sponge off."
So, how to get round these neanderthals? Again, easy. Proxy servers. What you need is not NAT as it is currently used, but rather IPv4IPv6 NAT. Then, end-nodes can use IPv6, whether the ISPs ever do or not.
This is the reverse of the dismally failing attempt to push multicasting, by concentrating on the backbone. The backbone doesn't matter! It's what the user can do - and KNOWS they can do - that counts. Everything else is fluff.
If NAT boxes and NAT solutions worked by mapping IPv4 to IPv6, you can be damn sure that Microsoft's IPv6 stack would be stable and on people's desks in a week, with AOL following a few days after.
Why? When it's taken YEARS just to persuade a few hundred sites to even experiment with the protocol? Because image is everything. Mess up your image, and you're dead in the water.
(This goes back to why ISPs are about as likely to try new things as a vulture is to go vegetarian.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
What happens if someone forges a AVES DNS entry to point to an internel IP, and then uses the AVES protocal hooks on the NAT to actually drive through the NAT and hit that machine?
I don't see this shipping in the default "on" position anytime soon in the future, but a neat way around IP connectivity issues behind a NAT.
Robert Morris has a group working on overlay networks as an alternative to basic Internet path selection --- RON. They are concentrating on overlays as a means of allowing intelligent or policy-based routing decisions on a small scale effect decisions on the large-scale Internet.
Of course, multicast is only going to happen via overlay networks. There are many groups building scaleable overlay networks for content and data delivery today. I'd go so far as to say that multicast semantics are going to drive adoption for routed overlay technology, which will then be used to bridge NAT domains later on.
A valid question to ask in response to this article, though, is "what address exhaustion"? Does anyone have real, valid numbers + methodology for address depletion on the post-NAT Internet?
Unfortunately for Cisco, ISPs don't particularly want to deploy IPv6. It doesn't make them more money. Gadget internetworking (http://www.yourwaffleiron.com) hasn't happened yet, and when it does, there's no reason why it can't be made to fit into the 32 bit space we already use. Security has already been addressed by opportunistic IKE/ISAKMP/IPSEC, SSL, and SSH.
In a network that already aggressively uses NAT, private addressing, and overlays, what does extra address space really buy us?
Nonscaleable routing table growth!
Personally, as a low-level network application developer, I'm in no hurry to see IPv6 deployment. I generally have a problem with the way infrastructure developers have pushed more and more problems into the core of the network. This is contrary to the end-to-end argument that the Internet is based on. The more we do in applications, the more flexibility we gain.
The fact that you can't run "Icecast" servers has nothing to do with addressing. Streaming audio distribution over the Internet is a debacle right now. What you're really asking for is multicast, and that's coming around the bend (only riding ON TOP OF IP, not inside of it!). When widespread overlay multicast occurs, you'll have access to an efficient distribution channel without the need to run a "server" that people "connect to" to get audio.
And how on earth do you overlook dynamic DNS in all of this? If the problem is resource location, what is an IP address buying you? DNS already provides enough information to resolve rendesvouz problems. If you are stuck behind NAT, relay/rendesvouz architectures already exist to turn your "clientside" connection into a server feed.
I think this desire to deploy IPv6 is just knee-jerk religious bigotry from people who don't understand the problem.
Stanford recently did the right thing, and gave back an entire Class A netblock, renumbering into the remaining Class B blocks they retained (36.0.0.0/8 was the block they returned to ARIN, in case you're wondering).
Other parties mentioned in that NWFusion article seem to think they have a God-given right to hoard address space they will never use.
According to the NWFusion article, it is estimated that only 69 million IP addresses are actually in use, out of the 160 million to 1 billion that are practicably useable given the limitations of IPv4 routing protocols.
Edith Keeler Must Die
More security issues to contend with. Let's be honest here. How many servers do you really need? For crying out loud, you don't need 19 servers running web pages and DBs and god knows what anymore. Use yous allocated IP's wisely, Nat what can be natted, and let everything else reside peacefully behind that firewall. And wait for IPV6 already.
This works fine for software that uses domain names to communicate. An http request, for example, resolves a domain name and includes that domain name in the request header. That is why virtual domains can work so well under Apache. However, there are other protocols, often somewhat non-standard, that do not use a domain name at any point. These protocols will continue not working under this scheme.
Consider, for example, many multiplayer games. You connect to another person's IP address. You do not use a name. If that person is behind a NAT firewall, I do not see how this proposed solution will help at all.
Besides, for all but huge internal networks protected by NAT, how is this any better than forwarding ports? For example, when you hit port 8080 on the firewall, it is forwarded to port 80 on apache1. When you hit 8081, it is forwarded to apache2, port 80. And so on. Any modern firewall allows this fairly easily and lets you hide a whole series of servers behind a NAT firewall.
The downside, of course, is that the protocol of choice must be able to connect on arbitrary ports. No problem with http but probably you cannot set up your multiplayer game to do this. On the other hand, you do not need to install any new software assuming your firewall is half decent.
--
Oceania has always been at war with Eastasia.
I appreciate all the work your friend has done, but why try to extend IPv4 when IPv6 is already here? This reminds me of companies producing "blazingly-fast" ISA video cards years after the PCI and AGP specs were defined...
--
Have fun: Join D.N.A. (National Dyslexics Association)
AVES, and other domain services are probably going to be the way we do things for a long time to come. Despite the fact that the technology exists, the sheer cost of upgrading the *entire* internet to IPv6 is prohibitive.
If you're Cisco, you're interested in getting IPv6 capable routers out the door, but recognize the fact that very few people want or need them yet because the 'rest of the internet' doesn't use IPv6 yet. Even if you can muster the cash to make the code change (which Cisco has, if I remember correctly) you still have to provide combo routers and switches, and hope for market penetration to make the investment in IPv6 worth it.
If you're an ATT or a Worldcom, you more than have the cash to do it, but it will make your bottom line look bad if you spend millions on upgrading routers and switches. As we all know, in the U.S. nothing is more important that the bottom line (gag).
If you're a home user, you'd love to go to IPv6 so that you can run your own OpenNap, Icecast, FTP, Web, etc... server, but realize that you will never convince your ISP to allow you to do so since they're still using IP4 protocols and working with backbone providers who use IP4 protocols.
So you use AVES, making it possible for those who would otherwise be force to use it put off IPv6 off just a little longer.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Since IP6 is a logical solution to the problem with address, is there any reason we shouldn't push hardware companies to adopt it instead of focusing so much on workarounds?
which will bollix up many kinds of firewalls.
The fourth diagram on the "How Does Aves Work?" page shows this clearly.
An example: my home firewall sees an HTTP request go out to pc.john.avesnet.net, for which (according to the explanation) a DNS lookup gets an IP address [1.2.3.4]. [1.2.3.4] is actually the IP of an "AVES waypoint" host. The waypoint processes my original HTTP request, and sends it along to the actual machine behind some NATbox (which has an IP of [5.6.7.8]) somewhere, which replies to my browser. But the reply doesn't originate from [1.2.3.4], which is where my firewall is looking for a reply to the original query -- instead, it arrives with a source IP of [5.6.7.8], which is the IP of the NATbox behind which pc.john.avesnet.net actually sits. To my firewall, this looks like an incoming connection attempt that is unrelated to any outgoing traffic, so it gets DROPped on the floor.
So, far from requiring no upgrades on the part of the end-browser, this scheme will require anyone with a firewall or a NATbox (such as my P90 running ipchains, or a linksys BEFSR41, or some other cablemodem/DSL access sharing device) to understand the protocol and deploy mechanisms for handling it.
Need a UNIX/Linux/network guru in the Boulde