It also isn't as widely supported as it should be. I never said DDOS was
hopeless, there just aren't a wealth of defenses against it.
there is a fix for it, it's called "putting a fuckton of ram in -most- routers on the internet" and keeping statistics for each destination ip:destination port:outgoing interface so that none of them individually can (entirely/procentually compared to other traffic) flood the outgoing interface on that router... end result, if enough routers are structured
like that, is that ddos attacks will be come completely useless.
keyword here, is terabytes of ram.
statistic tables on very basic ipv4 stuff alone would already take multiple 100's of gigabytes...
(keep in mind, this won't be "cpu work", its just using the table entry size * dest ip as an offset and reading it out 
the good news is, ram doesn't cost a flying fuck anymore...
it just requires a complete re-think of router design, but then again, with the prices that cisco and juniper charge we expect a bit more than a 1960's telephone exchange look and feel device, or we might as well use 1 linux box/blade per 20gbit/s throughput and consider that whole thing a "hotpluggable interface". cisco and juniper, at the moment, sell faster versions of their crap from the 1990s, but not much effort went into completely re-designing the stuff to be suitable for the internet as it is today, they still forward all packets they can get their hands on, and besides rather simple stuff like QoS, not much effort went into inteligently spreading the capacity available on the outgoing interface (at least for that individual router) over all the possible targets.
now, if an outgoing interface is 10ge, and 10mbit traffic should go to 1.2.3.4 and 20ge (ddos) traffic should go to 4.3.2.1, i'd say, a router should give 1.2.3.4 the full 10ge, as it is available, and lower volume should basically just get a higher priority.
we have not quite worked out the formula yet... but it should be something along those lines (simply to say, any destination ip can never fill more than half of the outgoing interface, doesn't quite cover it, it needs some "intelligent adjustment of the percentage")..
basically...
table:
destip
destport
packetcounter
every so and so many packets/timeslices,whatever that packetcounter is decreased by 1
every packet, the packet counter is incremented
after inactivity for that ip for timeperiod x, the packet counter is cleared.
with ipv4, this "destip" entry is such a small (32 bit) integer that its better to just not store the ip itself but rather just throw more ram at it and use the ip address number as the offset in the array
(for faster lookups, preferably in hardware logic).
the same thing could be applied to pretty much every other concept still done with slow lookups nowadays (arp, routes, etc)... throw more ram at it and use the destination as the offset, who cares if 99.9% of the ram is not actually used. for the price of a juniper, you can buy a truck full of ram chips ;).. it's faster that way, and it allows us to do a lot of things, like not passing potential ddos floods in the first place, and intelligently allowing everyone, not an equal share of the traffic capacity, but the part they need.
if you don't mind wasting 50% of the available capacity the formula to determine wether to forward a packet or not is quite simple, if you also want to give a destip 100% of the traffic in situations where there is no other traffic, it becomes a bit more complicated..
as stated before, we haven't quite worked it out in full yet, but in any case... this would require for at least 30% of the routers that currently are on the internet and are 110 kg heavy "1960s telephone exchange models" to be replaced with 2012 style hardware, not "just faster cisco 7200 like things".