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.
In the paper, the researchers mention that that can cause problems with ingress filtering by ISPs, which can be fixed by forwarding the return traffic through the waypoint as well.
Read one of their papers.
IP v4 space is not in much danger or running out - lots of space exists. The reason that they are rationing so tightly (www.arin.net) is that the global internet table was growing at such an alarming rate, it threatened to overrun the memory available on even the high end routers. 128M of ram will currently just fit the current table. If you are interested in more about this, read up at Arin (american registry for internet numbers) or go read the archives for NANOG (north am. network oper. group) at www.nanog.org. Again, lots of ipv4 space exists - especially b/c of NAT and the US DOD giving up large portions that it was sitting on. I return you to your programming.
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.
CMU's unwilling to use a BSD-style license? Really?
Funny, when I worked there my lab released a big chunk of code under a BSD license, and the Cyrus IMAP server and Cyrus SASL library both appear to be released under a BSD license.
Also, you do realize that this project is still in the experimental phase, right? Academic research doesn't have the same release model as open source software -- the goals and constraints are very different. In the open source world, someone else grabbing your code and running with it is great; you've contributed to the community, and people are doing useful things. In the academic research world, that can easily mean that someone else publishes before you do, and you've just spent a lot of time and funding with nothing to show for it. Oops.
The same goes for the IETF comment -- taking things to the IETF too early is a waste of everybody's time. It's better to try something out and see if it works before trying to standardize it. Not everything is best hashed out completely in committees and over mailing lists.
I would suggest that you give this project time to develop before trashing it for not being finished the way you'd like it to be, but I do realize that doing so would violate the Slashdot 'gimme gimme, I want it MY way!' ethic.
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!"
Obtaining a multicast tunnel, these days, is an impossibility inside an absurdity. Try asking for a tunnel on the MBone mailing list, some time. If you're lucky, you'll only be talked down to, as if a small child.
(Personally, I know children who can out-program pseudo-intellectuals any day. A degree and a job in an ivory tower doesn't make you smarter or better. It just gives you a better view of the ground, when the foundations collapse.)
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)
There are also alpha-quality patches for Win 95/98 from Microsoft's development website.
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)
(That assumes, though, that ISPs have an interest in providing a service, rather than simply making a quick buck.)
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)
(Pointers to them are on: http://www.6bone.net)
IPv6 and IPv4 can run concurrently, but unless you have some kind of translation layer, you can't simply connect to an IPv4 machine through IPv6. It isn't backwards-compatiable.
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)
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)
Why don't we just use the RT (route-through) resource record? It's been around for ages, is supported by bind et al, and could allow nearly unlimited use of existing address space.
Then game publishers should put out a patch to change the IP address inputs to a textbox input, require names to connect, and be done with it. The code to use a name instead of an IP address is about 5 lines longer and adds about half a second to execution times in bad DNS traffic conditions. Besides, if any number of names could map to a single IP address, then no company would have cause to prevent you from requesting TBONE.MYISP.COM on your account when you dialed in. In fact, you could have your own internal IP address in your provider, assuming every provider used the Class A private network for their internals.
This space for rent. Call 1-800-STEAK4U
IPv6 may well happen first in mobile networks - this is due to the number of mobile phones (about 500 million currently), and the fact they are becoming IP enabled (about 70% of mobile phones use GSM, and most GSM networks are going GPRS, enabling IP to the phone).
GPRS is an easy upgrade for GSM networks and US TDMA (IS-36, i.e. digital cellular other than CDMA) networks. It includes a tunnelling protocol that allows the tunnelled address of the phone to be IPv4 or IPv6. And in the 3G world, IPv6 is part of the standards from the beginning.
This is really horrible - anything that discourages ingress filtering makes it a lot easier for script kiddies to DDoS the world. And routing all traffic via the waypoint server means you have now created a centralised network with sub-optimal routing.
This really does illustrate how successive kludges on top of IPv4 (NAT, AVES, etc) will make it essential to migrate to IPv6...
Of course, in the modern web you can assume that every client will include a "Host" header in its requests... Netscape has done it since 1.1, and you're required to do it if you claim to be HTTP/1.1 compliant (which is just about everyone these days except for squid, and they still conform to a good chunk of RFC2616 except for the caching nitty-gritty).
Unfortunately only HTTP 1.1 supports a hostname in the packet header. Most web hosts use virtual hosts in order to stick a shitload of domains on a single server (and thus IP) and charge you a bit of mula for it.
I'm a loner Dottie, a Rebel.
What the fuck? Port assignments are an RFC stanrd (I don't remember exactly which one) they aren't just random assignments people decided looked pretty. Theres 65000 or so ports because the designers of TCP weren't exactly sure how they were going to be assigned. You can't just open up 65,000 or so ports to the outside world. Thats how people easily DoS your network.
I'm a loner Dottie, a Rebel.
You can run a network service on any port of your choosing but if my client isn't trying to access your server on the right port I CAN'T CONNECT TO YOU.
I'm a loner Dottie, a Rebel.
Looking at their AVES "setup" page, anyone is permited to go and setup dns mapings. How do they authenticate that I own the machine I am mapping? Otherwise I can just map right through the NAT.
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.
All computers should have publicly reachable IP addresses; this makes writing new network applications far easier. You can assume a fairly transparent network. With the IP shortage, this is no longer the case.
BTW.. they aren't 'fake' IPs, they are 'reserved' IPs.
And http is one of the ONLY protocols that includes the domain being looked up in it's own protocol.
In short, we have something that came about via an oversight in the original design of the protocol (that 32 bits would be enough address space), and now people like you are complacent about the hacks we use to get around it?
What we need is IPv6, deployed properly. And it's going to happen.
Ipv6 will take years to deploy. My guess is that you won't see it until something like ten years from now. Consumer operating systems do not support ipv6 and/or require significant and non trivial tweaking to support it (this is not likely to change for a while). As long as this is the case, ipv6 will be the standard. Port forwarding does not really help because you can only forward a port once (which sort of sucks if you are running more than one webserver behind NAT).
A kludgy solution like outlined above might just be a nice solution for many small companies and home users. I'd hate to get a more expensive account from my isp just for the additional IPv4 nrs when stuff this would solve my problem just fine.
Jilles
I meant "ipv4 will be the standard" of course, silly me.
Sorry, I really should preview,
Jilles
Jilles
IPv6 is the long term solution to the ip-exhaustion-problem.
However, the adoption of IPv6 is dependent on several other parties, over which you personally may have no control whatsoever.
This solution could be deployed today, without having to wait for all parties to adopt IPv6, something which may actually never happen.. a different protocol may be used at the time that people actually convert.
If you've got enough servers behind a NAT box to care about that, you've got plenty of reason to get a small range of IPs from your service provider. Simply "dedicate" one IP per server that needs some ports forwarded, or overlap as needed.
"That's Tron. He fights for the Users."
It loosk liek a good way to help out bulk web server farms, but it does not even come close to the IP shortage problems.
Because one is using DNS as the map to the NAT'd server, the server must actually receive the DNS address as part of the request. HTTP is the only common "over the internet" internet protocol that has this functionality.
I am not too afraid of the IP shortage much in the short term anyway. ICANN and the IP sub-orgs have handled the translation to more effective IP blocks very well, and since people have to pay for them now, it is unlikely that the will be used frivilously. Plus, the internet, despite its massive growth in user nodes will eventually crest I think soon enough to eliviate heavy strains.
etc...
By taking a position of superiority you show how nearsighted you are. Thus Spake ADRA
Bye!
Apart from the fact that CMU does release plenty of BSD-style-licensed code, any talk about the IETF is totally irrelevant because AVES does not introduce any new standards or require any new infrastructural support. It can and is being deployed today with no cooperation from anybody.
It would be nice to have the DNS protocol changed a little bit so that forwarded requests contain the address of the original requestor. But that's a completely orthogonal issue and other people (e.g., Akamai) want that too.
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.
Why can't we just promote IPv6 ? Instead of hacking together something that works, why not just design it right from the start akak IPv6 ?
(Not meant as a flame, but as an honest question.)
Doesn't work for DHCP of the firewall. Theoretically, when the firewall starts up, it is reconnected to name-tree with the new IP address, thus quakerserver.mygames.XXX will allow one-stop-configuration. Existing methods require the startup process to post the firewall's new IP address on some 3'rd party's site, which is less than convinient.
-Michael
-Michael
why try to extend IPv4 when IPv6 is already here?
Can you assign an IPv6 address to a cable-internet modem/gateway and play everquest today?
Thank you.
-Michael
-Michael
The only systems that need real IPs are servers. It's as simple as that. Multiple www and ftp sites can be placed on a single server; all the server software has to do is check the request string. (eg. 'http://www.server1.com' goes to one virtual directory, 'http://www.server2.com' goes to another; both are on the same server).
I don't know what all the fuss is about.
Local networks can use fake IPs (just use a range of IPs that are reserved for local networks; I'm not sure what they are off the top of my head, though...)
-Egon
Actually I think that NAT is quite a nice solution for most of the problems of non-routable IP addresses (even servers can be handled with a bit of tinkering at the gateway.)
IIRC IPv4 has had client routed protocol packets for forever though. I don't get why you couldn't just add a loose-route optional protocol header to the IP packet to route traffic past gateways rather than add layers upon layers to the IP stack (which invariably seems to result in protocol stack inversion.)
LibBT: BitTorrent for C - small - fast - clean (Now Versio
After spouting off this morning about how simple it should be to do the same thing with core IP, I did eventually go back and reread RFC 760 & 761. And I agree that it wouldn't be nearly as simple as I thought to use client packet routing.
Among other things it looks like client routed IP packets were never completely specified. The packet route is destroyed as the packet is being routed (each hop specified in the route gets pulled off when as the gateway is reached, and the only way of building a reverse route is by setting the packet tracing option which would require knowing in advance how many hops the packet will go through.
In addition there doesn't seem to be any supported way (at least in Linux) of using that packet as the basis for a response. Instead the user-mode program manually copies the sockaddr_in from source to destination, and that structure only uses the basic IP address.
Ick!
LibBT: BitTorrent for C - small - fast - clean (Now Versio
Where is this in the IETF standards process?
NATs violate the concept of direct connections to the internet that a large part of the IETF want to see. (Strike 1)
Where is the source code? What is the license terms? (given CMU's lack of willingness to use BSD style license....Strike 2)
Two strikes as to why the IETF would look at this and click their tounges. If they are uynwilling to submit this to the IETF and go through the process, this is nothing more than an acedemic excersize, and can be safly ignored.
If it was said on slashdot, it MUST be true!
Interoperability and a clear migration path are part of IPv6 ( Transition Mechanisms for IPv6 Hosts and Routers, Routing Aspects Of IPv6 Transition and Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels ). As a home user you can easily join the 6bone and be part of the magic. So, anyone who wants to switch to IPv6 can do so without a lot of trouble. For more info and the site where I stole those links from check out: IPv6 site
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.
The one listed in this article is pretty reasonable for a lot of uses. The article talks about web servers etc. That isn't one of the uses that this would be good for. You will almost always have packets doing some backtracking from the waypoint. This backtracking represents a slowdown. If there are only waypoints in the U.S., imagine a two Europeans trying to use this system. It also represents a cost on behalf of the waypoint. This cost will be passed on to you, as the subscriber. If you are running a heavy, multiserver farm. I'm willing to bet that that cost will be more than buying your own IPs. Besides, there are way easier ways to have multiple webservers behind a NAT which give you more control over the load.
I guess if your ISP (in my case AT&T broadband) set this up, then there would be no or negligable backtracking. ISPs can then entice newer subscribers by allowing them to do this (possibly for an extra fee). I would probably switch ISPs, if there were a broadband ISP that offered this.
What it might be good for is for a home user with a multinode network behind a NAT who ocassionally P2P things, like network gaming and telephony. With this system, each computer could have a copy of Net2Phone running, and can be called by entering the machine's DNS into that product. Similarily, you might be able to do this in games (not in Alien vs Predator, where you can only give an IP, but some games allow DNS).
Where I am skeptical of the above is the speed costs. I said above there would be backtracking. There is also costs in the routing. Telephony doesn't require a low ping, but it is better without it. Gaming requires a low ping.
This might also work well with the file sharing thing. This adds one last bit of skepticism. There is nothing in ICQ that lets me set my DNS. I don't think there is anything in Napster to specify a DNS. Napster and ICQ "know" how to contact you by the IP address you use when connecting to the central server. There is no way to tell htem how to use this system.
Which brings us back to web servers, ftp servers, telephony, and gaming. Don't get me wrong. If telephony worked with this, and I were an international business, I would use this at the very least for intracompany calling/conferencing. I might even have my employees put their machine DNS on their business cards to promote other companies to use telephony.
The chances that the applications will change to allow a DNS field are much higher than the chances of everyone changing to my NATCP idea above. Software, even that much software, is much cheaper to change than all that routing hardware.
I give it a B+ for solving the problem. It may be the best mark I give.
-no broken link
I am going to begin speaking as if you have read the "How does AVES work" page. If you haven't, do it now. When I say "locks up", I mean the waypoint won't be able to create new connections to a different NATed machine.
Essentially the problem is that there is a very easy DOS attack, that cannot be removed by the design of the system.
Basically, what you do is you make a bunch of DNS requests without ever making a connection. This will allocate all of the waypoints. If my understanding of this system is correct, a DNS lookup will allocate the waypoint to the specific machine for quite at least a few seconds (so that the proxy can form) if not longer (otherwise it may have problems with applications that cache the IP address, like IE, which don't do a DNS lookup for each connection).
So, find a bunch of unique DNSs (if you use the same DNS, the system can just reuse the same locked machine) that use the same service, and begin allocating. Pretty soon, no one will be able to make a connection to any subscriber.
Note that it is the whole machine that locks up waiting to form the bridge, because the DNS server can't know what port the remote application is going to try to use.
This goes back to the reason why I wouldn't use this system for web servers: there are other ways of having multiple machines as web servers behind a NAT that give you more control over the load.
I would limit this to home use, and even then, expect some script kiddies to knock out your service now and then.
-no broken link
This hasn't happened...yet. However, it will occur not too far down the road. Actually, I should rephrase that. Unless IPv6 is used, increasingly cumbersome methods of increasing that available IP pool will need to be used.
The growth of broadband, WAP devices and talk of such things as ovens, air conditioners and god-only knows what else being hooked up to the internet will rapidly drain this pool. This is why IPv6 is neccessary. For a really good article on it, check out this CNet story.
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
one problem with schemes like this is that compared to IP routing, DNS is much slower, less reliable, and more prone to misconfiguration. for another approach to solving the address exhaustion problem in the context of NATs, see RFC 3056 and draft-moore-6overnat-00.txt.
So far we have been saved by the Alan Greenspan approach to IP address shortage. Send the economy into a tailspin, put all the "dot coms" out of business, and watch the IP addresses come rolling in.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
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.
You just have to coax it a little... "c'mon feel the burn", and "where's your second wind?" or even "you've almost acheived runner's high!"...
BlackNova Traders
In the article, they say:
and
Do they have any plans to support *BSD? I mean, OpenBSD makes a really nice firewall, and I like the way IPFilter works. (It seems a whole lot less kludgy to have a simple text configuration file than to have a full-blown script calling the iptables/ipchains command once for each rule you have. Sigh... I wish Linux used IPFilter.)
--
--
We have fought the AC's, and they have won.
http://slashdot.org/articles/00/06/25/0230223.s
(look at post #44)
Replace government search-engine with IP exhaustion an you have some instant karma whoring!
---
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
________
Does anyone actually have a Java program designed to control air traffic, or for the operation of a nuclear facility?
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)
I use port address translation (Port forwarding) at home and it works great with all my apps. In addition their are very few services that don't respond to this technology anymore. I also have the option of running a DMZ or "1 to 1 NAT" to futher assist me in the "Special Cases." I can see very little practical use in the technology that this article proposes. Sounds like someone trying to reinvent the wheel to me... but that just my opinion.
I couldn't fail to disagree with you any less.
--
A feeling of having made the same mistake before: Deja Foobar
Yadda Yadda Yadda
What?
Oh, yeah! Y-A-W-N
We already have a solution to fix the IP address depletion problem, not to mention other issues with the current IP infrastructure.
It's called (drumroll)
IP V 6
Perhaps you've heard of it?
Always amazes me why people bother directing such a large amount of energy to solving a problem which has already been solved.
Can anyone say "fragmentation"?
People who say it cannot be done should not interrupt those who are doing it.
These documents indicate that hosts who want to use IPv6 need a DNS server that will support it. Unless you run your own DNS, which is not something that most home users do, this is dependent on the whim and pocketbooks of ISP's and BB providers.
You may run your own DNS, but I can count the people I know who would get any use out of their own DNS server on one hand.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
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!
This appears to be about as revolutionary as a coal-fired pocket calculator. Sure, it addresses a need, but in a round-about and probably unsustainable way.
Individual machine addressing through NAT has always been possible using free, commonly-available VPN tools. I've done this for my home machines for years by bouncing traffic through a colo box. It works because I'm willing to pay for the bandwidth. Who's going to pay to run these "Waystations" when they could instead put their resources into fine-tuning IPv6?
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
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?
The problem isn't a shortage of IP addresses, it's a shortage of well-known ports. There are only so many port 80s and port 23s to go around. However, there are a lot of other ports, and there are good, reliable, safe ways of forwarding them (firewall forwarders, ssh, SOCKS, ...). Rather than fixing subtle assumptions about name/IP correspondences in lots of software, I'd rather be fixing software that hardcodes port numbers; the latter is much easier to find and code.
AVES is a prototypical example of how we create messes and maintenance headaches: it looks like it solves most of the problem and, hey, we can fix the remaining problems, right? But it isn't the right thing to do, and the long term costs of creating such a mess would be high. Fortunately, I don't think it will catch on: ISPs don't want people to run servers anyway.
can't a nat box be set up for an easy port fordwarding scheme to enable hosts to be found behind a nat? if i want to get to a mail server behind a nat, i forward all "standard" requests from nat interface to my mail server, etc...
after reading through that stuff, i didn't see anything that new or breath-takingly cool. so a dns lookup scheme that works with nat to do host forwarding instead of port forwarding. true, i hadn't thought of it meself, so i'll give them that credit.
and the Irishman took the fly in his hands and yelled, "spit it out!"
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