Speak Freely To Be Withdrawn January 15
wrenhunt writes "The Speak Freely site has this: 'On January 15th, 2004, Speak Freely will be discontinued and removed from this Web site. Existing users may continue to use the program as long as they wish, but no further releases will be forthcoming. For details and the reasons why Speak Freely is being discontinued, please see the full end of life announcement.'" The reasons are various and interesting; it's graceful of the author to provide an explanation of why a piece of software is going away. Update: 01/11 19:22 GMT by T : As reader pi_rules points out, this story is a duplicate -- my apologies.
Why isn't it easier for people to open up ports on their cheap routers ? Tell someone to "Just forward your port 4893 to your computer" and they'll look at you like you're an alien, so why not include an application to do it that goes in their start menu (in addition to the web based interface) that would detect software trying to listen, and then asking if you want these to be open ? A bit like ZoneAlarm but controlling the router...
He mentions that with IPv6, NAT will not be required because the address pace will be so much bigger. Does anyone know if the costs in obtaining your own static IP would then drop dramatically? I mean, will it be financially feasible for most of us to get a static IP when IPv6 is in full use? Most of us would need at least several.
How about a Slashdot search engine that accepts boolean operators and phrases? Or searching on a phrase plus other fields in the comment/story's DB record, like author, date, topic/section? A better search engine would use less server resources when searching, and members could search their own post history to link a new comment to an old, but still relevant, point. Slashdot's server seems to use something like the ancient "swish" freeware. This post is practically a quote of a similar email I sent to a customer back in 1995! These features are coded by Slashdot users every day. Who will help me add it to the Slashcode? Who at Slashdot is interested in rolling it out at Slashdot? I'd rather code than complain.
--
make install -not war
The other alternative is IPv6. VoIP might just be the driving force needed to see IPv6 deployed in the real world.
I don't see that as a solution, for one basic reason... Why do most of us NAT/MASQ our connections in the first place?
Yeah, some do it for the sake of firewalling, but most of us do it because our ISPs will only give us a single address, and at best will let us pay more for an extra two or three addresses.
Using IPv6 won't change that. It would technically mean we have an abundance of addresses, but our ISPs would still pull the same BS, expecting us to pay more for the same level of service.
And even then, most broadband ISPs have rules against running "servers", a concept so vague that an out-of-the-box Windows box technically violates it (although ironically enough, while they piss and moan over having an open telnet port, they'll overlook a wide open SMB share). So what use would we have for an abundance of IP addresses? If my ISP limits me to acting as a pure client, I can do that just as well behind a masquerading gateway as I can with each machine directly on the net.
As has been pointed out, what we really need are easier solutions such as port forwarding
I kinda missed his point with that one... Port forwarding works pretty well, assuming your ISP doesn't spank you for having an open port. I tell my masq box to send port X to an internal machine, and it works. No hassle beyond a single firewall rule. So why doesn't port forwarding provide a sufficient means of getting around the NAT-to-NAT connection problem?
> As has been pointed out, what we really need are easier solutions such as port forwarding
What we really need is a generic method of sub-addressing machines. The public/private network paradigm is here to stay for various reasons, so we should shape our protocols to cope with that. We need another protocol between IP and TCP/UDP: IP addresses a point-of-presence on the internet, TCP/UDP a POP on a machine (i.e. an app), we need something that addresses a POP on an internal network. In fact, it could be a nestable protocol that replaces IP and allows for unlimited levels of private subdivision. That way a large company could have multiple internal NAT setups and you could still address a specific machine several levels down the hierarchy. I guess one could modify IP to be nestable, and IP stacks inside routers to be aware of it. Then you would address a private machine as a.b.c.d/e.f.g.h where a.b.c.d is the public IP address, and e.f.g.h the private one. The public NAT router would examine the next nested IP header (in this case e.f.g.h) and pass the packet to the correct internal machine (which could be another NAT box, ad infinitum).
The downside of course is that we're then back to the old UUCP days where you had to explicitly specify the route to the destination machine, making the network more fragile. Still, given that for the vast majority of setups it would be just a two-tiered setup (public internet and internal LAN), it should be workable.
Hey, this is off-topic, but I just wanted to say it's great that you replied, admitted the mistake and apologized. Seems like a little thing, but most of the time it feels like the editors don't listen to us, and direct interaction with us even in a little post like this is nice.
"Sufferin' succotash."
However, that's not correct. A server is only needed to tell each user the other's IP address. Once each side knows the other's IP address, there is a simply workaround for NAT.
Each sends a sacrificial UDP packet to the other. This serves to open up the sender's NAT to receiving UDP packets from the other side.
At that point, they can do peer to peer UDP.
Note that the server is only involved at the start, to tell each side the other's IP address.
Isn't there some clever way to work around these limitations?
There will be.
Wow. I *completely* disagree with what you've just stated here. Allow me to explain why.
First off, the internet was BUILT as an end-to-end network. You cannot just sweep this fact aside by saying it's "outdated". This principle is what MADE the internet successful. Without end-to-end, the internet would have gone nowhere. Really.
We want the application to run end-to-end, because that is what make the application useful -- but folks have confused this with requiring the mechanism to be identical from end to end
But now, in the new system, it requires that the network be AWARE of the application, and configured EXPLICITLY to allow this certain type of data to be transferred. Now you have to ask permission from the people who control the network to run your application. Now you have to make configuration changes in the network itself before you can run any new application. Gone is the open development environment of the internet. Gone are new applications that pop up that anyone can use immediately. (This is how the web started. Your NAT support would have made the web so difficult that it wouldn't have gone anywhere. Imagine the millions who would have had to configure their NAT to work with a new system of doubious worth.)
You say that the network should be SEPERATE from the application, and then go on to promote the application being DEPENDANT on the specific configuration of the network.
"like in the days of the telegraph, the mechanism and the application were synonymous. That is an obsolete model, though. Our needs and demands have gotten more varied and complex from the point of view of the applications -- the mechanism (IPv4) needs to be separated out from the applications."
AND IT IS! That's the POINT, Bookwyrm. Currently, in the 'obsolete' model, the network is TRANSPARENT to the application. No specific configuration of the network is requried. The network is seperate from the application. However, NAT makes the application depend on the network, and thus makes the network and the application once again joined, like the telegraph, phone and cable TV networks of the past. That's a step BACKWARDS.
Even now, because of NAT, we can observe the harmful effects of new development. VoIP doesn't work properly. File sharing applications are suffering massively because people can't share, even when they want to. Running a server of any kind, (a game server for you and your budies to play on) requires additional configuration, making it harder. People in certain situations, like in university, for example, have no ability to influence the functionality of the NAT, and are stuck being internet consumers. And don't forget that it's even MORE arduous to have multiple computers doing the same thing, like being a webserver, behind the NAT. Now you have to specify to the CLIENTS to use different ports for different servers behind the NAT. It begins to get so ugly that people give up.
Your goals are noble, Bookwyrm, but your thoughts on the matter are misguided. This site might help shed some additional light on the situtation.
And finally, the people who invented the internet for real though that end-to-end addressing was the best idea, and from their efforts, we have the most advanced communcation system humans have ever seen. To say that they are utterly wrong requires some guts, and also a LOT of backing up. In other words, the proof is in the pudding. Where is YOUR all NAT internet?
Rebuttal: First off, the initial gun powder weapons were BUILT as muzzle loading, single shot weapons. I can certainly sweep this fact aside as "outdated". This does not say that the black powder weapons were NOT successful in their time, but now, they would not go anywhere. Really.
Well, duh. What else do you call a firewall?
Well, duh. Ever looked at your Terms of Service agreement? Look closely at the your own statement! "Ask permission from people who CONTROL the network" -- they control it, it isn't YOUR network.
So far, you seem to be building a spammers haven -- no filtering, and no one who can tell a spammer not to run their spamming applications.
Great. Tell me how to access an IPv6 server from an IPv4 application. Wow! Looks like we need NAT before we can have all these new applications.
Bull. The application is aware of IPv4 addresses, therefore it is not separate from the network layer.
NAT does NOT make the application dependent on the network. The application was ALREADY dependent on the network. If it wasn't dependent on the network, changing the network would not break the application.
Silly.
IP addresses have no place in the application layer. You can't say that the network is transparent to the application, because if the network was transparent to the application, the application would not break because of NAT! NAT breaks the applications because the applications are dependent on the configuration of the network.
If the applications were not dependent on the network configuration, then I should be able to run the same application across a Bluetooth conneciton, ethernet, GSM, and ATM, without changing one aspect of the application. Instead, all these applications *NEED* IPv4, they are *DEPENDENT* on IPv4 being configured without NAT. They require knowledge of IPv4 address space -- they break with IPv6 addresses.
This is NOT transparency. This is dependency, addiction.
End-to-end addressing the best idea? Great! Let's use MAC addresses instead of IP addresses! Heaven forbid we translate or map IP addresses to MAC address on ethernet! Goodness, those folks who developed ethernet much have been a bunch of idiots then, right, to require another level of translation and mapping? Even if it does allow for people to use IPv4 and IPv6 over top the same med