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.
Anything incoming to port 80 on the NAT goes to port 80 on foo.hidden.domain.tld. Repeat as needed.
Gee, this looks amazingly similar to the summary paragraphs from an interactive week (or one of those rags) article a few months ago!
Cut-n-paste still good for a few quick&cheap karma points, it seems?
The reason no one is using IPV6 is because Microsoft Windows doesn't support it.
You have to have N AVES "waypoints" to access N internal machines using a single NAT gateway.
The total bandwidth available to AVES "waypoints" has to be at least bandwidth used by all Z AVES-NAT gateways (which is the sum of the bandwidth usage of all their AVES-NAT'd internal machines). This is a lot of bandwidth.
And regardless of theoretical bandwith comparisons, this will never work for significant amounts of bandwidth. Anyone who has experimented with any kind of tunnelling has probably noticed that the internet sucks.
Peering points suck. Bandwidth sucks unless you pay tons of money and have dedicated fiber, and even then peering points still suck.
So what you really need is N AVES "waypoints" for each AVES-NAT gateway that are close to the direct path between A and B. Unfortunately this is pretty impractical even given massive amounts of money to deploy these things.
And as 8 billion people have already pointed out, AVES makes it impossible to do any real packet filtering by essentially anonymizing the incoming connections, unless you're [un]lucky enough to be running linux 2.4 and want to write a netfilter plugin that gets the real remote ip from the AVES-NAT daemon. As if filtering didn't chew up enough CPU already.
I really want to know why people are coming up with schemes like this that don't scale at all. Don't they have better things to do with their time?
DO SOMETHING USEFUL. PROMOTE IPV6 (And learn more about it too, ipv4->ipv6 migration has been thoroughly addressed, no pun intended)
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.
Combined with the fact that router manufacturers should have a much stabler IPv6 base by then and critical mass of IP wireless devices should be arriving about then, expect to see a sudden surge in IPv6 connectivity and demand. You heard it here first!
I just downloaded cyrus-imap-2.0.12 and cyrus-sasl-1.5.24. Neither license says that. In fact, no file in the cyrus-sasl archive even contains the string "commercial".
Where exactly did you get that quote from? My guess is that you just pulled it out of your butt.
I see.
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.
now, holly hunter - there's a babe! plus she's from conyers, georgia!
"shop smart:shop s-mart" ash
But what is being implememnted isn't much better. It's going to have just as many security holes in it, if not more than V6. Why not just work with the new and contend? It's like constantly replacing your cars radiator, while the body rusts out.
The biggest problem is probably training people to use it. At this point it is still a big unknown. We have to wait for everyone to learn how to use it.
Actually, a lot of the early companies got lots of IPs because, well, they were there early. Xerox, IBM, DEC, Apple, MIT. I don't know my Internet history well enough to know what role BBN played, but obviously they got something for it. All these companies have got to be wasting TONS of IPs... Apple for example... I'm sure all of Microsoft's IP blocks don't nearly add up to a class A, what's Apple doing with theirs?
"Hot lesbian witches! It's fucking genius!"
So in the future please refrain from getting snooty on people and referring to them as MCSEs without cause.
"Hot lesbian witches! It's fucking genius!"
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!"
You can start using IPv6 right now even if your ISP only supports IPv6, by tunneling it using 6to4 to another 6to4 machine acting as gateway. The 6to4 tunneling protocol is in the kernel as of at least 2.4.1 (earlier version than that I believe you need to apply a patch or two). If you live in Sweden (like me), check out SICS' 6to4 gateway. They have connections to the 6bone and to several ISPs (it is recommended that you try one of those first).
---
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
We are NOT running out of IP addresses. We are adding too many routes to the global routing tables that must be held by all routers running bgp connected to multiple tier 1 backbone providers. This is one reason why IPv6 is still vapor. It doesn't address the size of the global routing tables.
--
Joe Hamelin
-- I have a private email server in my basement.
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)
Software which requires IP addresses and doesn't understand DNS is broken.
Maybe. That's certainly *less* broken.
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.
This whole thing is stupid. If the "Waypoint" knows the name of the machine that it is connecting to why not simply build that information into NAT? In other words, we have a protocol such as HTTP/1.1 which sends a hostname in its header (The only way the waypoint can identify the host in question) So build a http filter into NAT. host1.mushmouth.com, and host2.mushmouth.com both point to the same IP, NAT can simply read the HTTP header and know that host1 requests go to host1, and host2 requests go to host2. A filter such as this can be made for protocols that name the machine in their heaaders. This "AVES" solution is typical PhD type overkill shit, gotta make it hard, cause I need to drag it out over years.
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...
Are you Jon Katz logged in under a different name? =)
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).
but that only works if you only have ONE server that wants port 80 behind the NAT.
My plan is to pimp before they realize I'm a jackass. Hit 'em hard and fast.
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.
Maybe AOL could use that many if all their users were given real IPs =P ... otherwise to answer your question, yes it would be a great help to have a good chuck of those IPs back.
-- Just my $0.02 worth...
Actually Lynx was probably one of the first because it's based on the Libwww.
New things are always on the horizon
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.
The fuss is about providing a service with one of your Nat'd boxes. How are you going to assign a domain name to a non-routable IP address ?
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
There's exhaustion right here, right where Eugene is doing his research: CMU. We're running out of addresses, and look at this. Last semester they were handing out tshirts to those who agreed to use a dynamically assigned ip instead of a static, for both DSL and wireless users.
So really, I appreciate Eugene's research, especially if next year I'll be connecting through another ISP, that only gives me one static IP.
Maan
This kind of automatic "Give me the source, give me the BSD style license" makes me sick. Not everything has to be free and open to make it useful.
Also, this is a research project. Not a proposed standard, not a cog on someone else's wheel, but a project to answer a real world problem. To quote the grad's web page "[m]y thesis research is focusing on providing connectivity across Internet networks of heterogeneous address spaces." You know, doing something useful as opposed to just writing some hack and giving it to the world.
What have you contributed to open source?
Why wait for IPv6. Its here today!! Use it!!
Lottery: a tax on those bad at math.
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."
Why? From their abstract, it looks like the AVES system requires support from the DNS servers. The reason for this is that the AVES system works by assigning a waypoint's IP to a customer's hostname when a user looks up the IP. Since the waypoint must know the source IP (in order to know where to expect packets from and forward them to the customer's NAT gateway), the user's system must be querying an AVES-aware DNS server directly. While upgrading DNS servers to support this wouldn't be as huge an undertaking as upgrading all of the Internet's routers to IPv6, it would still take a significant amount of effort and time.
In addition, since AVES depends on a DNS TTL of 0 when sending responses to clients, using AVES could cause a performance hit for clients. While doing a DNS lookup before initiating every connection probably wouldn't be a problem for singe users on a broadband connection, it may be noticeable for users on dialup or for a whole network that's behind a medium-sized pipe. Or, if it doesn't pose any problems for clients, it may mean a significantly increased load on DNS servers. Servers that typically just need to respond to a single query when a client wants to connect to a website would end up answering several queries by the same client because of the 0 TTL requirement. The servers would also have the added load of notifying waypoints.
The original poster implied that the services that were being offered by the servers was similar. In order to use it though, one would have to have a port for every server behind the firewall, not just port 80 for HTTP, but port 80,81,83,etc..
I would hate to type in http://www.somecompany.com:35525, and I am sure consumers would too.
Because the resolved DNS request is not known on an IP level, one would have to grossly hack the application protocol to sniff out the DNS address requested, if the address was even sent with that protocol.
By taking a position of superiority you show how nearsighted you are. Thus Spake ADRA
Bye!
Because it is built into apache, an application layer protocol, NOT the IP firewall tool. The only difference with this system is that it brings DNS to the IP firewall level, but HTTP is the only protocol top benefit from this.
By taking a position of superiority you show how nearsighted you are. Thus Spake ADRA
Bye!
Mind you that I did not read the protocol as fine as you did, I still have points on the feasability to add.
1. The DNS Server must know about the "special" masquerading rules involved with sending an "expect a request to " message to the waypoint box. This is broken. Every DNS server on the internet would have to support this option, and the DNS server must find out if this masqueraded DNS name is authentic, or if it is a virtual site.
Explaination: Since DNS names are cached from one DNS server to the next, one cannot guarantee that a client would request a DNS lookup on a server under their control, so to guarantee a sucessful transaction, all DNS servers must know about this DNStoIPMASQ trickery, hence iterative adoptance of this protocol is impossible.
2. Ignoring the first point, unless every TCP/IP protocol stack also changes, it is impossible to guarantee that the DNS "expect a request to " request will ever arrive before the actual client's request. The only redemtion would have the waypoint server queue the packet for a timeframe until the DNS message arrives. See DOS attacks for why this will never be implemented.
Man, I went to a trade school for computer science so I never got a chance to do real research. Now I will never be featured on slashdot... wah!
By taking a position of superiority you show how nearsighted you are. Thus Spake ADRA
Bye!
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!
DSL Companies can use NAT technology on their subscribers too. I am NATed by my DSL company. My linux machine has no external IP address - only an internal. This really sucks, BTW. I can't host Quake games or serve up pr0n for my buddies.
Y_Y
Execute? [Y/N] _
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.
Another kludge to deal with stupid allocation of existing "real" IPs...
Well, at least somone realizes that there is going to be a need for different sollutions to the problem of migration to ipV6. Hell, we americans still can't figger out that there metric system, let alone how to use AAAA records.
Seriously though, There is a LOT of capital out there in hardware that doesn't support ipV6 yet, and a lot that never will... Lessee - large numbers of switches, routers, cable modems, print servers, gateway devices, etc... Using a tunnel to the 6bone will work for a little while, but there is some serious labor to be invested once ipv6 ONLY hosts start going up... Anyone have a feeling that there are going to be a lot of disgusting hacks to allow old hardware to keep working?
Somone PLEASE put something really cool on there with no IPv4 access so that we can all get a fire lit under our asses.
+++ ATH0 +++
Yep. Port fowarding works just dandy for this. I've got web servers, mail servers (SMTP and IMAP), and other stuff all behind a Linux Router Project box.
Mmm, ok...so we're sending ALL traffic then through the waypoint...
first off, anyone who happens to be behind a NAT box that they can setup to do this, (i.e. probably a home network) will most likely not have a spare 'waypoint' hanging around outside their NATted network.
second, if all traffic goes through the waypoint, what the hell are we involving the NATted system for? Just use the 'waypoint'.
I cannot see how this would be useful to anyone. There are too many potential problems and requirements, and not much benefit.
hehe.. they did.. and then some.. its called IPv6.
JOhn
Campaign for Liberty
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
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.
"Premission to use, copy, modify and distribute this software and its documentation is hereby granted for non-comerical purposes" That is hardly a BSD-style license.
Such a (speculated) license on the AVES code means that for it to get approved as an IEFT standard, someone would have to come up with a more 'commercial friendly' version. A less restrictive license would remove one objection to the project at an IETF level.
Without IETF's blessing, it isn't going to be an internet standard, and will be in interesting research project like SKIP.
I would suggest that you give this project time to develop
And as I stated, it has 2 strikes against it, as far as the IETF process is concerned. The project may get completed, and it may work. But for it to become part of an approved standard, getting past the NAT resistance will be a hard sell. But perhaps all you want is the project to be like the SKIP vpn code.
If it was said on slashdot, it MUST be true!
his kind of automatic "Give me the source, give me the BSD style license" makes me sick.
Then you'd hate the IETF. They like reference code that is un-encumbered. Public domain, BSD style licences help get IETF blessing.
And, this 'solution' doesn't seem to consider the habits of the IETF.
If it was said on slashdot, it MUST be true!
Cyrus-imapd-1.6.22.
If it was said on slashdot, it MUST be true!
Glad you C.
If CMU has decided to dump the 'non-commercial' tag from all their code that's great. Then the code is more useable with other projects.
It doesn't change the fact that the project works to keep NATs in service, and such a position is going to have a hard time getting IETF approval. And without the blessing of the IETF, the project won't be anything more than an acedemic excersise.
If it was said on slashdot, it MUST be true!
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!
Have you tried to get a block of IPs recently? Spent any time justifying why you need 300 address? Or even 50? It's a pain in the ass and only getting harder every year. ARIN allocates based on justified need. Meaning that you provide your reasons why you need a /20 or /19 and they allocate you what they think you need.
Here's the page with the requirements ARIN puts on upstream providers and initial address block requests: ARIN
Check out: 6bone . And here's a way to get on 6bone from your workstation: Freenet6
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
Damn! I let my last moderator status expire yesterday. I'd have modded your post up, you make a very good point.
Edith Keeler Must Die
On the contrary, the early adopters are saying "We got ours, the rest of you can fuck off."
(tongue planted firmly in cheek)
Edith Keeler Must Die
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
In addition, a number of special devices called AVES Waypoints are also deployed in the Internet. AVES Waypoints are network agents that relay data packets between end hosts.
Any idea how slow this will be? It will eating up 2 x the transfer bandwidth (1 stream in, 1 stream out) per relay to the end host from one of these 'way points'. I think they totally forgot to factor in network connectivity costs in their design model. Unless they are somehow disconnecting the data transfer from the 'way point' (it isn't mentioned) this is doomed to gnutella hell.
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.
From a cursory reading, this approach does not seem to fix what it's aiming to fix.
I noted the claim that AVES non-subscribers need not change anything. But DNS A records (which these AVES non-subscibers will be using) only supply the IP address. And so they must be referred to some helper IP (I imagine that what these waypoints are).
Any traffic ment for (H,P), instead goes to (W,P) where H = hidden host, W = waypoint proxy for H, and P = port. If true, this doesn't help much because the waypoint can't be the proxy for 2 different hidden hosts at the same time same port which is the typical case, actually. In the worst case, every hidden host will be contacted at the same time, which will require as many waypoints as there are hidden hosts, requiring as many routable IP addresses as there are non-routable ones, which doesn't avoid the problem at all.
But perhaps, the idea is that the worst case doesn't happen and/or connection requests can be postponed until a waypoint is free. I have 3 problems with this. 1) This will only work for transfers like HTTP where the connection time is very small as compared to very long lived connections like ftp-data (minutes to hours) or even telnet (days and days). 2) It is not at all obvious that the waypoints can be coordinated with the AVES DNS server to avoid a TINY-gram fest/administrative nightmare. 3) Thumbs it's nose at DNS cacheing.
mind you, you could always reverse proxy the hosts based on virtual host address.
Multiple DNS addresses coming in -> Proxy on firewall reads the HTTP header for virual host and passes the request on to the selected box on the internal net -> internal box returns HTTP data to firewall -> firewall passes the data back to the host.
Of course this isn't pretty and will only work for HTTP requests or any other protocol that sends the host name, but it would work if there was no other solution.
IPv6 just needs a "killer app". Then pressure from consumers will force IPv6 on the consumer OS's.
What would be neat is if a non-filtered Napster moved over to IPv6 (leaving the filtered version on IPv4). I assume most people affilated with the RIAA (atleast the big-wigs) use a Microsoft OS, they will not be able to see this Napster, however those of us who have access to the IPv6 network can use it.
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?
Client A (not behind a NAT) wants to communicate with server B (behind a NAT). Client A only allows the input of an IP address.
Now, what IP address do we use? We cannot use server B's IP address, nor can we uniquely identify any of the servers behind the NAT because we can only use an IP address.
--
Oceania has always been at war with Eastasia.
I repeat that I do not think this guy's solution is universal as it relies on using domain names while many programs do not allow their use. In addition, it seems to offer no compelling reason to switch over simply forwarding arbitrary ports past the NAT firewall.
--
Oceania has always been at war with Eastasia.
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
--
--
We have fought the AC's, and they have won.
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.
A far better approach, IMHO, is for the client to establish a tunnel for this purpose with the assiatance of server side tunnelling endpoints. Yes, this requires server side work, as well as client-side work, but eliminates the need for a third party to set up the tunnel. Of course, it does not preclude a third party from doing this, if desired.
Basically, the client runs a DNS proxy that returns LOCAL IP addresses for remote hosts that are otherwise inaccessable through the internet, and routes traffic to such addresses via an appropriate tunnel.
The client DNS proxy knows when a remote host needs to be contacted via such a tunnel by mapping the remote host domain name to an IP address in the public DNS database and then reverse resolving that same IP address. If the names do not match, it is presumed that the IP address provided is that for a server-side "inverse NAT" proxy.
This server-side inverse NAT proxy is contacted (by the client-side DNS proxy) to resolve the same remote host domain name to an INTERNAL IP address routable only in the server-side network (basically, a private non-routable IP address).
Armed with a server-side private IP address, and the means to generate a client-side private IP address, unique in their respective (server, and client) IP address spaces, it then becomes trivial to proxy traffic between the two using a virtual network set up between the two proxies.
I've been planning to come up with a proof of concept implementation for GNU/Linux (to be essentially free for use in GPL code, but not otherwise), but lack the time. Anyone interested in helping is strongly urged to contact me.
You could've hired me.
Just use IPv6 already! Kludges like this are not the answer. This might be a particularly good kludge, but still, a kludge
------
Not a typewriter
This is what IPv6 (as opposed to today's IPv4) does, but to a greater degree then you mention.
Warning: For the rest of this post, I will talk about things I have no clue about.
IPv6 allows for addresses to contain hexidecimal, and you can have 16 "octets" (to use the old, IPv4 term, but they're not really 8-bit words anymore and I don't know what they call them in IPv6) instead of 4.
This means the theoretical address space of IPv6 is greater then the total number of atoms in the universe (depending on which physicist you ask).
------
Not a typewriter
I thought that was what IPv6 was supposed to do. If it's just websites you want, apache has this built into it with virtual hosts, proxy serving and other nifty things.
You can also have only one box with secure shell or something similar with two NICs and the other one is on a network with the other servers you want to get at.
DanH
Cav Pilot's Reference Page
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
Only about 50% of the available address space is currently allocated, so theres still a long way to go. Here is a paste from the daily BGP report sent out by APNIC:
/8s, 205 /16s and 155 /24s
Routing Table Report 17 Apr, 2001
Analysis Summary
Number of addresses announced to Internet: 1238211568
Equivalent to 73
Percentage of available address space announced: 33.4
Percentage of allocated address space announced: 65.5
Percentage of available address space allocated: 51.0
Who has a real story of an IP address shortage? I mean, something like an ISP saying "Sorry, we'd like to give you a DSL line, but we've just run out of IP addresses". Until I hear a real story of a lack of IP space, it all sounds like FUD to me. @Home and other large networks use 10.x.y.z. networks internally, and many compnaies (like mine) go NAT for security/configuration reasons.
I want to delete my account but Slashdot doesn't allow it.
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)
Actually, it's more like suggesting that a 2x4 is better than a wheel and you should use it instead.
Ip4 works, and doesn't inconvenience those using it to switch in order to accomodate those who can't get on.
ip6 will be adopted at great expense. From the existing servers and routers perspective, they gain very little out of it too.
Enabling host functionality behind NAT is far cheaper globally, than moving to ip6.
Ip6 is nice to root for just so we can avoid IP address scarcity, but when you try to see who will benefit from it, its quick success is questionable
Why not just amend the current DNS RR schema with extensions to support Transport Port Numbers (P records?) as well as Network Addresses (A records) so that port-forwarding can work transparently through DNS? Oh, and redo that whole gethostbyname thing, too.
If it's obtrusive innovation you're going for, why not go all the way? (Disclaimer: The preceding question is not intended to represent itself as attaining the full potential extent of obtrusiveness.)
And is this PhD chum of yours aware that this same concept is in use by a Canadian web hosting company? ... and has been for the last 2 years or so?
What hardware are you refering to? Routers and level 3 switches? Btw for all you non Cisco people like me a level 3 switch works like an unmaged switched hub only it directs traffic on the transport layer instead of the arp layer. So basically its a switch with a firewall built in.
Anyway my point is IP is implemented in software. Those ten year old token ring cards in the 386's in the back closet of your office are IPv6 ready pending a FreeBSD install. Null modems are ipv6 ready. Even with propietary routers if you upgrade the software there IPv6 ready. Its a software issue.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Now look at it from the part of the internet as a whole. Make it so that the top level of the internet only speaks ipv6. The ipv4 protocol of the lower network hierchy will need to be NAT'd to ipv6 addressing and packets modified as required. This could work, but it would require amazing machines for converting protocols on the fly, but I think with a creative use of division of labour, it could be acomplished sucessfully.
This would likely cause performance problems for networks outside of the core of the internet, whoever, you could just push the adoption of real ipv6 further down the network heirachy, until even the end users are using ipv6.
This would solve everyone's problems, because internet traffic would always be ipv6, but relatively local network traffic could remain in an ipv4 block of adresses. Each subdivision would be able to use the entier range of ipv4 adresses space, so nobody in the smaller portions of the network would need to change over right away. Softening the economic blow to the majority of the internet.
I could see small ipv4 network segments surviving for at least 10 years, while the core internet traffic is exclusively ipv6.
Now lets see it happen.
Spring is here. Don't believe me, look outside!
I am wondering why head internet people (you know who you are)don't just declare an end of life to IPv4. Let us just say that in 24 months all new access points must be IPv6, and in 36 months all others must provide a two year migration plan to IPv6. This means both ISP's and their new customers must comply with IPv6, period. Without a difinitive eol IPv4 will hang around forever.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Since you seem to be fond of the BSD license, I'll make you a deal. I'll write some BSD-licensed code, if you'll use a spelling checker. We can bid on grammar another time.
"The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life"
So is it just me, or does this whole scheme seem redundant? Pop a DNS server behind the NAT box, and you could map all those ports to names.
--
jX [ Make everything as simple as possible, but no simpler. - Einstein ]
On one hand, the enthusiastic "early adopters" will simply say that there's no way to predict where technological progression will take us and that we should simply "play it by ear", adapting to each problem as it occurs. After all, who would have believed that the Internet could take off in the way it has? On the other hand, the more experienced, but possibly flawed, viewpoint states that we should research the possibilities of each new venture before jumping in.
Who is correct? At this point, it's difficult to tell. Some detractors would argue that flaws in systems such as IPv4 will end up presenting a major problem in the long run. Networking technology is a revolutionary step forward; it alters the capacity for communication in ways that our current economic structure and techonological understanding may not be prepared to predict. Perhaps glitches in this untested process may condemn these systems to a footnote in computing history.
Supporters, on the other hand, say that Internet is an important step forward for computing and society, and that we should jump in as soon as possible. With previous information distribution systems, users could not take advantage of the most important technological benefits gained from modern-day information research. The Internet, they say, just opened the proverbial floodgates by bringing the technology out of the laboratories and into the homes of the every-day user.
There is some probably some merit to both viewpoints. Certainly, commerce as a whole will encounter some friction as it shifts to accomodate the wide use and acceptance of the Internet. However, the end result may be worth the infrastructural shifts; existing network systems may not be as structurally capable as new plans such as IPv6.
Will our network infrastructure sink or swim? The question is still up in the air; with many unique forces and viewpoints at work, we'll likely see many interesting challenges and confrontations for the pioneers in the CS field. Whatever the final result is, it's sure to give the key players on all sides of the issue a trial by fire.
What if the client doesn't make a DNS request (local host file storing hostnames, for example), or caches older DNS requests? What if a non-AVES DNS server resolves the request rather than the authoritative AVES server?
In the words of Dana Carvey as George Bush, "Na gonna work."
Careful port mapping will help you alleviate most of your NAT-related incoming connection issues. Those that can't, as in the case of Napster, and a lot of games that use UDP and/or dynamic ports to shuttle information back and forth would probably be better handled by a more intelligent NAT box and some sort of a standard Dynamic Port Translation protocol, where UDP app 1 and 2 communicate with each other an any intermediate NAT box to determine what port(s) each will accept data on, and to where it should be pointed inside the private network.
Ed R.Zahurak
Ed R.Zahurak
You know, oblivion keeps looking better every day.
2. A NAT gateway's functionality needs to be extended to handle the AVES protocols. This can be achieve by running an additional software program called the AVES NAT Daemon on the NAT gateway device. The AVES NAT Daemon does not alter the pre-existing functionality of the NAT gateway.
A few points. First off, if you're able to mess with your gateway's software, why not just use SOCKS, which has been around for much longer, and, I believe, can be configured to provide the same functionality.
Secondly, the majority of NATs out there (I'm talking about home DSL/cable connection sharing NATs here) don't allow you to install new protocols of your choosing!
Thirdly, there are much better ways of doing this that don't even require you to mess with your NAT router. (1) NAT user (A) connects to 3rd party connection-broker server, and registers. Since NATs happily allow outgoing connections, this is fine. (2) User B wishes to connect to NAT user. Opens a TCP port for listening. Sends a request to A's broker server, including the listening port number. (3) Broker sends message back down established TCP channel to (A) saying "B wants to connect - here's B's open TCP port number". (4) A makes outgoing connection to B. (5) A and B have a TCP connection, and live happily ever after.
This only works when one user is non-NAT'd. There are similar techniques for establishing UDP connections where both users are NAT'd, and I came up with a (ugly!) way of establishing a full TCP connection two NAT'd TCP users, using a 3rd party only during the connection brokering stage. Click here for info. Unfortunately, since MS's TCP stack is buggy, this technique fails when the machines are Windows boxes. GRRRR!
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.
One of the nice things about NAT was that users can't make their computers publiclly accessable. Now for every LAN that has a poorly build firewall configuration, anyone can create a mail relay for spamming, web server for p0rn, quake server...
Press any key to continue, any other key to quit.
Well, there are a few of us who would like to use the capabilities given us by our systems, like say setting up our own mail server [maybe I'm alone in this, but I hate my e-mail's fate being in someone else's hands], or how about a smallish web site that still has full functionality for CGI et al? Maybe not every last person needs every sort of server, but why should only the privaledged few get to control the digital printing presses?
-={(Astynax)}=-
-={(Astynax)}=-
"Darkness beyond Twilight"
--
A feeling of having made the same mistake before: Deja Foobar
--
A feeling of having made the same mistake before: Deja Foobar
And there's also the fact that there are still alot of modem users who don't have to have an IP address all the time.
I don't have any exact numbers, but I'm under the impression that there is no way every computer on the Internet can have its own IP address. I am also under the impression that ISPs are happy about this, because they can make the people who really want/need IP addresses pay more money.
This is nothing new. I know of at least one commercial firewall product that can do NAT and redirect HTTP requests to one server on a private address, SMTP traffic to another private address and so forth. A decent load balancer can also hide many servers (on private IPs) behind one 'real' IP.
However, issues arise when some custom (or not) gumball protocol embeds IPs in the packet data and the firewall can't diddle the data in the packet to fix it.
My vote is still for IPv6 - 'bout flippin' time the industry got on the ball with it.
I probately won't never get read, exept by a couple of real die-hards (yow guys!). But, why does this design contain waypoints trough you service provider. If I get it right, even the entire bandwith has to pass trough the service provider... This is no good. I'd love it more to see the whole thing implemented in some hack of a bind deamon, combined with some creative routing, so I can use my own dynamic ip service, add subdomains to it, so the subdomains are pointed to the private ip's... Nah, I get back to bed
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.
It appears the only difference here between apache virtual hosts with host forwarding (Yes, you CAN have multiple domain names hosted on apache all on port 80...) and AVES is that AVES would run as a daemon that listens to all ports (or at least assigned ones.
:^> ) *coughCROOKScough* ]
Personally, I think it would have been much more efficient and flexible to simply have extended an inetd daemon to provide the same functionality.
Granted I didn't download the technical docs (It's not worth my time right now) but what's this stuff about an AVES Service Provider? This seems rather wasteful and unnecessary. Besides, doesen't that mean the ISP would have to be running AVES?? If that is the case, then I can guarantee that AVES will never be accepted. Just TRY to get verizon or UUNet to run some newfangled, untested, possibly unstable and unsecure daemon that may not even be compatible with their routers.
All things considered, AVES seems to be good for nothing but a doctoral thesis (at least, it's good if this kid's reeeeealy lucky)
that's just my $.02.
[BTW, for an example of multiple apache virtual hosts port 80 with host forwarding, crack into www.cynaptec.com. If they've got the same setup I designed 2.5 years ago, you'll see how it's done. (Not that I expect they would have kept anything I designed after I had to sue them
I'm done with sigs. Sigs are lame.
Worked fine for me, I have 2 servers behind my firewall that are accessed via name virtual hosting on a firewall that uses dhcp. (Of course if my ip ever changes, I'll have to go and update the ip in the httpd.conf file.)
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
This is an intriguing idea, but one with some major flaws.
... port forwarding is useful, but it's not a "silver bullet." Each port may be assigned to exactly ONE machine inside the network. If you're running more then one web server (or more than one machine with Napster), you either have to do without or deal with sending your users to alternate ports. AVES doesn't suffer from this problem.
... my office has forty-some.
... to share a pool of unique IPs among all users. The IP pool just isn't big enough, though--every user has one to contribute, and is almost certain to require more than one.
In response to ALL the port forwarding posts
The problem, as I see it, is a shortage of Waypoints. Let's assume that every AVES NAT machine is also a waypoint (as suggested in the paper). If there are N users in an AVES cluster, then there would be N unique IP addresses to distribute. What we need, though, is an IP address for every machine INSIDE the AVES NAT network. We can safely assume that every user will have at least two machines behind his network (if they had only one, then port forwarding or DMZ would do just fine). At peak usage, then, we'd need at least 2 * N IP addresses. Many networks would have still MORE internal IPs
Some of these problems could be solved by timing out the AVES DNS requests quickly (shuffling IPs around more quickly), but then you'd begin to run into caching problems. If my PC caches an AVES domain name after it's been released and repointed, I could end up pointing at a completely wrong server.
AVES is an ingenious attempt to "communize" IP addresses
We need to devote our energies on getting IPv6 up and running, not finding work arounds on a system whose life expectancy has been cut dramatically by the short sightedness of the users of the system, everybody included. Heck, with IPv6, every computer can get an IP address, and every user as well. You get get a global identification system out of it, no need for passports, just your ident number please.
That was a little hostile, don't you think? Please reference This site if you aren't sure what I mean.
I got the percentages from here, and calculated the number of addresses myself. They don't include reserved addresses, such as the "all hosts" address (224.0.0.1) in multicast.
You have a point. Lack of education is usually the biggest factor in problems from security to, hell even racism.
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?
Haven't you heard? You can run ipfilter on Linux since version 3.2. See http://coombs.anu.edu.au/~avalon/ipfil-new.html
"BSD is about people pissing each other.." (Moid Vallat)
Eli lilly is a pharmaceutical company, prozac etc.
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.
I'll admit I'm no network engineer, but why not just add another byte to IP adresses? That would increase by a factor of 255 the available IP addys.
TODO: Something witty here...
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
Correct me if I'm wrong but doesn't IPv6 run together with IPv4 so if your connected to an IPv6 network you'd still reach the rest of Internet.
--------------------------------
I, for one, would be interested in an informed prediction of when we will actually run out of IP addresses. Anybody out there qualified?
Fear My Cow Shooting Crossbow
N-i-g-h-t-m-a-r-e. Don't get me wrong, the concept is really cool though!
Honestly, why not hit it at the source of the problem? Force IPV6, keep 4 around for backwards compatability and eventually it will be phased out. This is such a ridiculous problem. Problem: We're running out of IP addresses Solution: NAT everything New Problem: NAT has flaws New Solution: Create a hack to work around them Scratch that, I'm all for IPV6 to finally get implemented and give every computer a unique IP! I wonder what the round trip to my microwave would be..
With a combination of dyndns, granitecanyon and ip[commands] under linux you can set up a "NATed" infrastructure and port forward to different servers behind your linux firewall without needing to host any of your own DNS or any static IPs.
This works when your firewall recieves its IP dynamically using DHCP from a cable modem or such.
For instance:
- register a domain: such as mydomain.com
- go get a dynamic domain from dyndns (make a donation cheepo!): mydomain.dyndns.org
- create a C record on granitecanyon.com that points mydomain.com to mydomain.dyndns.org
configure your firewall box to dynamically register its new IP each boot with dyndns...
Done...now setup an http server behind the firewall running on some port 8080, for instance.
Setup ipchains and ipfw to forwad all request to the firewall on port 80 to the machine behind at 8080...you could do this for as many ports as you like.
I don't know about your ISP, but in my experience, most ISPs don't give out ANY IP addresses. Even my broadband cable internet provider doesn't give out static IP addresses (you can't even pay for one).
Is he working out of one of those diploma mills? This could be (and has been done) by any idiot with an ipmasq box and a DNS server, or even with a port forwarder.
This isn't a "revolutionary" way to keep ipv4 decay at bay. It's not even a very good idea. It's just someone's attempt to market a business model as a real solution.
When I first started reading, I figured this might be a good idea, a real solution. Now after having read it, I see it's just an excuse to setup a bunch of relays on the net, and charge idiots for a service which they don't know how to provide themselves.
I'm ashamed to think Slashdot has resorted to advertising, and espectially advertising something this obvious as innovative.
occultae nullus est respectus musicae - originally a Greek proverb