Problem is the same size. If I have two or more routes to the same network then multiple routers are responsible for a given ip block. Its not really an attack vector because your create peering agreements with your providers and they are each responsible for holding up their own end of the deal. As disruptive as BGP errors whether malicious or through fat fingering are, it's not really that big of a deal to fix once the problem is identified.

I would think a DNSSec like infrastructure could help remove the possibility of malicious route modifications but in the end, if it's state sponsored then any system can be broken by even the proposed solution.

BGP for IPv6 is essentially the same as BGP for IPv4, so if the protocol has a security hole then it will appear on both. However, because IPv6 is designed from the outset to be a hierarchical addressing scheme, address tables should end up being much smaller (even though each entry is longer) which in turn means that accidents should be less common. If it's easier to see the consequences of your actions, you (in theory) should be less likely to make mistakes.

Back in the days when IPv6 mandated IPSec, the problem of malicious router table poisoning simply wouldn't have existed -- all router protocol traffic would be encrypted and every link would be encrypted distinctly, where the keys used for encryption are securely exchanged in an encrypted form via IKE or IKE2 and where the key exchange encryption key is either a shared secret or a public/private key pair. It would not eliminate accidental corruption, but attacks would be out of the question.

Also back then, automatic address assignment, router and service discovery (via anycasting) and router-level IP mobility (the routers automatically redirected packets if you moved between networks) meant that manual router configuration was almost unnecessary. Virtually everything could be discovered - including MTU - and so nothing really needed to be configured. This would have eliminated manual errors. In fact, that was the whole point of all these automated mechanisms. There would be no manual entry and therefore there would be no manual errors.

Telebit added a nice touch, creating a routing protocol that permitted segments of the network to be transparent (essentially the same as NAT, only far more fine-grained and flexible), although it seems they made the grievous error of not making their protocol public. Certainly I've seen nobody attempt to use it and there has been no reference to it since Telebit went under. Further, the lack of NAT is something that has held back IPv6. Given that Telebit had a working NAT equivalent in 1996, this is incredibly annoying. (Apologies if they did make it public, but it is still true that it's not used and that complaints about a lack of NAT have been a serious issue - made all the more serious precisely because the problem was solved and the solution deployed very very early on.)

So the answer is "if IPv6 is deployed as close to originally intended as possible, the problem simply doesn't exist - in any form; but that if IPv6 is deployed as it is currently used, the hole will hang around although it will be a little smaller".

Their suggest solution "stores the legitimate route information within the DNS". They think a centralized DB is better than BGPSec!? How stupid.

With the current situation there is at least a trust relationship where if a router consistently provides bad origins you can remove them from your list of routers to listen to announcements from. With storing the routing data in DNS you will be giving the core internet routing technology all the problems DNS has (more government control (SOPA, PIPA anyone)) and will be eliminating much of the benefit of a distributed trust network.

No, the right way to do this is to make the ISPs bite the bullet and implement BGPSec. Unfortunately there is little incentive for ISPs to implement this.