IPv6 Application Competition - win $10,000 217
sneekz writes "The IPv6 Promotion Council of Japan has announced a competition for developers of IPv6-enabled applications. Various prizes up to $10,000 for ideas and actual implementations, and you keep the rights to your work. From their site: 'The contest will award developers of applications and software which helps to create new possibilities in the Internet world.'"
but... (Score:5, Interesting)
what this contest proves (Score:3, Interesting)
A consortium of some 300 individuals and corporations interested in the promotion of IPv6 have to offer significant amounts of money just to generate interest in this new protocol. A decent Internet protocol should not be forced on the public cum pecunia; it should be developed openly and freely under the currently-existing RFC standards. If there were any real, useful applications of IPv6 to the whole world, then an open, free-entry consortium would be overseeing the transition from IPv4 to IPv6 now.
However, there is no desperate shortage of IP addresses under the current scheme. While there are less IPs than theoretically possible (256^4 = 4,294,967,296), thanks to overhead and mismanagement (MIT getting its own Class A subnet makes perfect sense...NOT), nevertheless there is no current need for this initiative.
The fact is, this contest is simply a ploy by these companies to get your intellectual capital at a fraction of its potential worth. Do the world a favor and make your ideas and code snippets public and free (or GPL'd). Death to corporate tyranny!
Paging Linksys... (Score:4, Interesting)
Re:money savings (Score:2, Interesting)
It appears you get all the copyrights but they are allowed to disclose and distribute your product whatever that means. It could mean they can sell it or give it to whoever they want. The terms sound a bit iffy to me. Any lawyers out there want to offer up an interpretation?
Re:All packets are created equal (Score:4, Interesting)
The end points (eg your Quake client and the server) usually set the QOS field, and what is theorically suppose to happen is the routers along the way go.. ah, he wants low latency, so I'll send these packets down this link.
However, what usually happens is most routers ignore the QOS bits.
As for the slow downs, etc. That may be your upstream (ISP), who may twiddle the bits, but they can only do that based on a number of factors, to/from port, IP address, bandwidth usuage, etc.
There is nothing (much) you can do to avoid your ISP slowing down certain connections, except by making it hard to identify what is "legitimate" and what is "illegitmate" traffic. Eg giFT uses random port numbers of both sides, so its very difficult for the ISP to say, lets throttle giFT traffic. Freenet does much the same thing.
IPv6 will not answer the bandwidth and traffic shapping problems, all it will answer is the limited number of IP addresses problem. (And if you think about it, probably cause more bandwidth problems because you'll be able to have *LOTS* of different devices all plugged into your upstream bandwidth, all sapping it).
My recommendation is if you live under a draconian ISP is one of the following:
1) Move ISPs. If All ISPs are like this, move country.
2) Go postal, grab yourself a semiautomatic assult rifle, storm into your local ISPs NOC (network operations centre), and demand a 100mbit connection for your laptop, "right this instant!".
3) Find an open proxy, use that to bypass port based traffic shapping. If your ISP is shapping every port but port 80 (web), go find an open proxy that is running on port 80 and use that for other connections. The best bet would be find some willing (or otherwise) machine somewhere outside of draconia, and put a SOCKS proxy on port 80 on the machine.
4) Implement IP over carrier pigeon. Pigeons are not known for looking at each IP packet and flying differently because of its contents, though if the packet size is too large, it could slow the transport mechinisim down. I'm not sure if this RFC supports IPv6, but sinces its a transport mechinisim, I should think it would matter.
Re:IPv6 info (Score:4, Interesting)
Re:Hmm, creative way to win... (Score:1, Interesting)
Other problems:
(1) End-user computers (ie: the vast majority of active internet nodes) do not have a DNS entry. Or if they do, it would be something like: 102_233_dsl.broadband.cali.internetprovider.net - you're not going to guess unless you wrote code specifically to target a given ISP.
(2) Volume of DNS queries. How many DNS queries do you think you'd need to make before someone became suspicious at the overwhelmingly huge number of requests that you were making?
Plus, doing random DNS queries over a long enough time would make it easy to trace back an attack to it's source. Every subdomain you queried would probably show up in a log file somewhere (or they *should*, but it depends on the competency of the admin. Hello shotgun-wielding FBI agents in black Chevy Suburbans and charges of "Homeland Terrorism". Which probably isn't worth it.
There's something missing here (Score:3, Interesting)
So, seriously, anyone have any wonderful ideas?
Re:There's something missing here (Score:2, Interesting)
I enjoy doing low-level network programming, like designing protocols, ponder upon network routing issues, etc. I got bored about doing IPv4 stuff for some years ago, so I moved into the IPv6 area in 98-99, after a while I got bored of doing IPv6 unicast stuff becouse that area are much covered today, not much design and research to be done there. IPv6 multicast is fairly new and un-expoited and are evolving quick, so its a fun area to be involved in, I'm part of a global IPv6 multicast research network called M6bone [m6bone.net], most things revolve about research of new protocols like MLD and SSM and effecient multicast routing.
In a future world I would be able to stream video from my server at home to my Cellphone/PDA anytime via Mobile IPv6 (MIPv6) connectivity. Most new phones today have a IPv4 stack and color-screen but no IPv6 support in the phones yet. With Linux on the Ipaq I can get fully Mobile IPv6 in my pocket thru WiFi networks or wireless GSM/GPRS today if I wish.
I would like to see IPv6 being deployed in broadband networks to the homes, I think that would fuel IPv6 into mainstream usage in conjunction with P2P filesharing and true high-quality video streaming.
Enough ranting from my side.
Diffserve/IntServe (Score:2, Interesting)
It is a while ago now and I have had other things on my mind, but basically what I found out is that on the internet there is no real need for QOS as bandwidth is increasing all the time, satellite links are reolaces by fiber (less latency and delay, and a lot more bandwidth), fiber is being replaced by "thicker" fibers, etc.
Just to give you an idea of the amount of bandwidth available - only 2.9% of all fiber optic cables layed alongside powerlines, rail roads etc are actually lit. And those that are lit, thos in use for the internet only have a maximum use basically of 50%.
Also, in order to give certain datastreams priorities over others, you need to track these, which adds processing delays and with networks where bandwidth is not a problem - why do this?
Also, something often overlooked:
In order to actually give packets priority over others and shape the traffic depending on priotities, you need to queue at least 200 packets it was discovered by some researchers, otherwise the queuing algorithms just do not have enough data to actually put into different queues. Think of it this way, if the queues are empty, then of course the data is sent to the top priority queue and you gain nothing.
Basically, there are two concepts: Diffserve and Intserve.
Intserve goes against the nature of the internet (in my opinion), as it uses RSVP to set up a quasi-static route through the internet, does the reservations, and then the flows have to be monitored. Keeping track of individual flows on the backbone routers? No way! And if the route changes, all the reservations have to be done again. Intserve (IPv6 has a Flow Label to facilitate this) has no place on the internet backbone in my opinion.
Intserve is very useful though in an organisation, where you have control of the network, and to give certain flows priorities getting out of that bottleneck router to the internet and then let best effort scheduling do it's work.
DiffServe on the other hand is viable in my opinion as this is hop per hop based. Diffserve works by marking packets and assigning it a traffic class.
This is very useful when you have flatrate customers, and customers that have are willing to pay for bandwidth. Of course the routers could and may already mark traffic of those customers paying for bandwidth with a higher priority.
Something which I really like about Diffserve is the ability to give packets a drop priority ("Hello you little nice router, If you really need to drop a packet, please drop this one").
This could be very useful in the case of video over the internet where the network itself regulates the quality of the video. What I proposed in my thesis, was to have an algorithm that send the most important coefficients in a packet with a low drop priority, the next batch with a medium priority and the rest with a high one, and in addition to that also have the software on the other end report back some statistics so sending is also reduced.
What this is allows is to have video not stop, but just instantly become of less quality if there are congestions.
Speaking of congestions, they only exist till the packets they reach the backbone.
And of course getting down from them again.
What has my post got to do with IPv6? Well, IPv6 has a Flow Label and Traffic Class in the IP header which are for IntServe/DiffServe.
Ipv6 facilitates IntServe/Diffserve, but does not really add anything new in this respect. It just makes it easier to process, because it is always at the same place whereas this info in an IPv4 packet could be at varying locations due to the variable length of an IPv4 header.